Ashar Voultoiz | 1 Nov 02:32 2005

Re: PHP Security Information: PHP File-Upload $GLOBALS Overwrite Vulnerability

Thomas Gries wrote:
> To whom it may concern:
> 
> 
> PHP File-Upload $GLOBALS Overwrite Vulnerability
> http://www.hardened-php.net/advisory_202005.79.html
> 
> 
> $GLOBAL Overwrite and it's Consequences:
> http://www.hardened-php.net/index.76.html

Hello,

Thanks for the notice about the exploit:
"overwriting the GLOBALS array when register_globals is turned on"

We dont use register_globals on WikiMedia website, i think most php
packages now ship with register_globals to off and anyone still using it
should recode their scripts :)

cheers,

--

-- 
Ashar Voultoiz - WP++++
http://en.wikipedia.org/wiki/User:Hashar
http://www.livejournal.com/community/wikitech/
IM: hashar@...  ICQ: 15325080
Christopher E. Granade | 1 Nov 03:08 2005

Re: LiquidThreads [WAS: Re: the discussion page: summary and better display of the treats, mbox format?]


Gregory Maxwell wrote:
> On 10/31/05, Tels <nospam-abuse@...> wrote:
>> OTOH, the currenty wikipages are not really suited to discussions at all -
>> I'd rather not have someone edit my "posts" - whether it be for fixing
>> the speling or whatever.
>>
>> When all you have is a hammer, everything looks like a nail - but I think
>> a new disccusion support would be very good to have, even if it is a lot
>> of work. The longer the old sytle pages are the only possibility, hte
>> longer we will get more and more of them. :)
> 
> I don't know about that, I often get into discussions where we
> alternate between wikimode and thread mode.   I think the fear of
> editing comments comes from a lack of trust in the system and the
> other editors.  Often in a discussion I'll post a list or a fragment
> of text, and multiple people with work on it.  I don't see what the
> harm is in leaving the possibility of editing other peoples words, if
> someone does it in an objectionable way they will be caught and hung
> like the evil creatures they are. ;)
> 
> Really, the only two problems I've had is tracking changes across
> multiple parts of a page, but viewing diffs from my last edit fixes
> that, and getting notified which watchlists mostly fix.
> 
> Too bad there isn't a way to watchlist sections. :)
I think what you allude to in wikimode discussion forums could be solved
by establishing a Scratch: namespace that mirrors the global namespace
(e.g.: Scratch:Template:NPOV) that is not considered to be "finished."
During development of new formats, or extensive editing, provisional
(Continue reading)

Daniel Wunsch | 1 Nov 04:02 2005
Picon
Picon

Re: LiquidThreads [WAS: Re: the discussion page: summary and better display of the treats, mbox format?]

On Tuesday 01 November 2005 00:04, Tels wrote:

> When all you have is a hammer, everything looks like a nail - but I think
> a new disccusion support would be very good to have, even if it is a lot
> of work. The longer the old sytle pages are the only possibility, hte
> longer we will get more and more of them. :)

just do not forget the one thing: in a wiki, you can 
refactor a discussion, in a usual forum this is impossible.
i know this is not a common practice on wikipedia,
but it is on other wikis, and it makes it much easier
to read a diskussion later.

daniel
Kerim Friedman | 1 Nov 05:31 2005
Picon

Re: Re: Bibtex

Your talking about the PM wiki extension? I was asking about something
for MediaWiki. There is nothing insecure about bibtex itself...

kerim

On 10/31/05, Christopher E. Granade <cgranade@...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kerim Friedman wrote:
> > Does anyone know of any efforts to integrate bibtex citation data into
> > MediWiki? Something like this plugin for PMWiki?
> >
> > <http://www.pmwiki.org/wiki/Cookbook/BibtexRef>
> >
> > Thanks!
> >
> > kerim
> Looking at it, I'd be very concerned about security; the bibtexquery
> action accepts PHP code as a parameter. Takes the hard work out of code
> injection/XSS attacks.
>
> - --Chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFDZmZF0dXuuZr00J4RAiBiAJoC9VfHuk7fr3X0rOL4hOCPvqXCxACgm5h6
> pfWow5Plb4ku2Zn7/MxzcBc=
> =1emk
(Continue reading)

Thomas Gries | 1 Nov 07:30 2005
Picon

E-mail notifications for user talk pages

Hello,
I justed wanted to ask what stands against enabling $wgEnotifUserTalk in 
all wikis ?

As you know, the number of changes on user talk pages per days is quite 
low, in the range of about 2.000 per day.
As Enotifs are only sent for the first  "foreign" change (not for 
changes of the user/owner of that page), the number of sent e-mails is 
even lower.

I'd like to have this enabled on the wikis, so that users can opt-in to 
have a notification, when someone changes their talk page.
Tom
Thomas Gries | 1 Nov 07:37 2005
Picon

Re: PHP Security Information: PHP File-Upload $GLOBALS Overwrite Vulnerability

  Ashar Voultoiz <hashar <at> ...

<http://gmane.org/get-address.php?address=hashar%2dwhniv8GeeGkdnm%2byROfE0A%40public.gmane.org>> 
wrote

Thomas Gries wrote:
> To whom it may concern:
> PHP File-Upload $GLOBALS Overwrite Vulnerability
> http://www.hardened-php.net/advisory_202005.79.html
> $GLOBAL Overwrite and it's Consequences:
> http://www.hardened-php.net/index.76.html

We dont use register_globals on WikiMedia website, i think most php
packages now ship with register_globals to off and anyone still using it
should recode their scripts :)

Ashar,
thank you for quick reply.

However, the above references describe a severe problem even for the case, that register_globals _is_ off.
The UPLOAD function has the flaw (pls. carefully study the both resources), which can cause a glitch in the
PHP internal setting for register_globals.

I recommend the MediaWiki developers study the both references for consequences.
Tom
Magnus Manske | 1 Nov 11:11 2005
Picon

Re: Re: [WikiEN-l] Ratings again

Ray Saintonge wrote:
> Magnus Manske wrote:
>
>> Neil Harris wrote:
>>  
>>
>>> Am I being naive here, or would a super-dumb implementation with a
>>> single table with the columns shown below be enough to work in the
>>> short term?
>>>
>>> Page_ID
>>> Revision_ID
>>> User_ID
>>> Rating_ID
>>> Rating value
>>> Timestamp
>>>   
>> This is what I did; no timestamp, but a varchar for comments. Topics to
>> rate and their range (e.g, 1-5) are encoded here as well for user #0.
>> That's about as dumb as it gets ;-)
>>
> I still prefer a 0-10 range of ratings.  I think a decimal 
> normalization would be easier to work with in any subsequent analysis 
> of results.
One can set the range for each topic individually.

BTW, with values 0-10, you'd have eleven values...

Magnus
(Continue reading)

David Gerard | 1 Nov 11:24 2005
Picon

Re: [WikiEN-l] Ratings again

Ray Saintonge wrote:
> Magnus Manske wrote:

>> I still prefer a 0-10 range of ratings.  I think a decimal
>> normalization would be easier to work with in any subsequent analysis
>> of results.

>One can set the range for each topic individually.

Mmm. See discussion at [[m:En validation topics]] and its archive -
too many choices of rating is probably a bad thing, because it's hard
to agree what a given value means. The test plan so far includes
probably far more variables than we'd want in any case ...

- d.
David Gerard | 1 Nov 13:14 2005
Picon

Spam filters on Wikimedia lists?

I still see what looks like breathtaking quantities of obvious spam
coming to the wikien-l queue. Is the spam filtering and greylisting
still on? Do we have numbers on what's not even making it to the
queue?

- d.
Rowan Collins | 1 Nov 13:41 2005
Picon

Re: Re: LiquidThreads [WAS: Re: the discussion page: summary and better display of the treats, mbox format?]

On 01/11/05, Christopher E. Granade <cgranade@...> wrote:
> I think what you allude to in wikimode discussion forums could be solved
> by establishing a Scratch: namespace that mirrors the global namespace
> (e.g.: Scratch:Template:NPOV) that is not considered to be "finished."
> During development of new formats, or extensive editing, provisional
> changes could be placed under Scratch, and such suggestions could be
> referenced from LiquidThreads.

Well, my initial reaction to this was "Yuk!" - the whole wiki is
supposed to be subject to "extensive editting". Even by having a
separate discussion namespace, we've rather removed the incentive to
refactor discussions into content or summaries, to our own detriment.
Splitting it even further into mostly-stable articles, hard-structured
discussions, and unstructured "scratch buffers" would be like having
an open-access CMS-cum-wiki, a forum system, and a traditional wiki
operating in parallel, which all seems rather stifling. I know that's
not what you were suggesting, but it's a kind of worst-case scenario
of going down that path.

OTOH, I guess there is some kind of logic to saying that if we're
going to force discussion pages to act like classical discussions, we
need somewhere else to put their other purposes - and it's true that
people already use them as "scratch". I just think we need to be
careful in making things too structured, lest we lose the immediacy
that is the whole point of being a wiki in the first place.

--
Rowan Collins BSc
[IMSoP]
(Continue reading)


Gmane