Re: Assuring Security by testing

On Wed, Apr 30, 2008 at 11:10:13AM -0700, Brion Vibber wrote:

[ snip ]

> 
> Generally, we try to maintain safe programming practices to ensure the
> borders are patrolled, as it were:

[ snip ]

Brion -- I just wanted to let you know that I took your name in vain:

  http://blogs.techrepublic.com.com/security/

--

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
They always say that when life gives you lemons you should make lemonade. 
I always wonder -- isn't the lemonade going to suck if life doesn't give
you any sugar?

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: Assuring Security by testing

Brion Vibber wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Simetrical wrote:
>> Well, first of all, I think our security team consists of Brion,
>> although maybe some other people receive the security@...
>> mailings as well.  Since he's also the lead developer, it's not so
>> much a question of recommendations as mandates, which he usually
>> implements personally (either fixing it himself, or reverting whatever
>> broke it).
>>
>> Nick Jenkins has done some fuzz-testing on MediaWiki in the past.  As
>> far as I'm aware, that's about the end of specific security testing
>> that's done on MediaWiki, at least by the developers.  The rest is
>> covered by general code review: checking new code to make sure
>> everything is escaped properly, and looking over old code as it's
>> being maintained.

Hi Brion,

thanks for your input!

> Indeed, there's not a lot of organized testing, though the fuzz testing
> tools get pulled out from time to time to look for HTML injection bugs
> and other such surprises.

Sounds good that you found some suitable tools to fuzz with. Are you 
able to name those tools?

Re: Assuring Security by testing

Simetrical wrote:
> On Wed, Apr 30, 2008 at 7:48 AM, Michael Osipov
> <ossipov@...> wrote:
>>  Spite the recommondations and the security team. Does this team
>>  or any other group/person take any measures to assure security with
>>  testing tools, with a special test plan or functional requirements?
> 

Hi,

> Nick Jenkins has done some fuzz-testing on MediaWiki in the past.  As
> far as I'm aware, that's about the end of specific security testing
> that's done on MediaWiki, at least by the developers.  The rest is
> covered by general code review: checking new code to make sure
> everything is escaped properly, and looking over old code as it's
> being maintained.

Do you think it's worth trying to contact Nick? I know that he fuzzes 
JAMWiki too.
Seems like he's into it.

Mike
--

-- 
<NO> OOXML - Say NO To Microsoft Office broken standard
http://www.noooxml.org

Re: Assuring Security by testing

Michael Osipov schreef:
> Is there any multi-tier patch revision? The folks at Apache Tomcat do a
> three-person-review of patches before they get committed.
>
>   
Well patches submitted from the outside (i.e. by folks who don't have 
commit access) are reviewed by the one who commits it and by Brion, who 
reviews everything (and no, they're never the same person, because Brion 
is generally too busy to review and apply submitted patches). Also, some 
people are experts on a certain part of the code, and will review all 
changes to that part. For instance, Tim Starling reviews all changes to 
the parser and I review all changes to the API.

Roan Kattouw (Catrope)

Re: Assuring Security by testing

On Thu, May 1, 2008 at 5:56 AM, Michael Osipov <ossipov@...> wrote:
>  Is there any multi-tier patch revision? The folks at Apache Tomcat do a
>  three-person-review of patches before they get committed.

We have no formal process at the moment, except that Brion reviews
everything after it's committed but before it's synced to the servers.
 People with commit access basically commit whatever they want, and if
someone spots that it's broken or otherwise objectionable, they either
revert it immediately or post a note to some development forum (this
list, #mediawiki on FreeNode, etc.) asking for people's opinions on
whether to revert it.  In the event of a dispute, Brion resolves it as
lead developer.  People other than Brion can review whatever they feel
like.  I at least glance at all commits to core code or extensions
used by Wikimedia, and sometimes look them over more closely.  It's
likely that most interesting commits get at least two other people
looking them over.

Bad changes do occasionally go live on Wikipedia (I broke it within
hours of getting commit access, woo), but rarely for long.  They tend
to be spotted quickly by editors, and since changes go live every
couple of days on average, it's easy to quickly figure out what must
have caused the breakage and fix it.

Re: So... status of category intersections?

Ok, TimStarling's sollution is to use an environment variable and check 
for it using getenv.

So for example, this is what you would do to a extension script to make 
it work right:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/CheckUser/install.php?r1=34107&r2=34106&pathrev=34107

I recommend that the form without the environment variable is the one 
currently in the maintenance script you modify when you make this kind 
of update. It'll be best for backwards compatibility.

~Daniel Friesen(Dantman) of:
-The Gaiapedia (http://gaia.wikia.com)
-Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)
-and Wiki-Tools.com (http://wiki-tools.com)

DanTMan wrote:
> What would you think, if I created a runMaintenance.php script into the 
> /maintenance folder which could be used to call maintenance scripts:
> I'll write this from my perspective, I run maintenance scripts inside 
> the path that a wiki is installed into because that directory is the 
> real location of the wiki, the actual maintenance and such directories 
> are all symlinks to a central location:
> php ./maintenance/runMaintenance.php --root=$PWD 
> ./maintenance/scriptname.php args...
> And similarly for extensions:
> php ./maintenance/runMaintenance.php --root=$PWD 
> ./extension/ExtName/maintenance/scriptname.php args...
> The point is:
> * The script checks for the cli sapi type, aborting if it fails.

Re: [MediaWiki-CVS] SVN: [34130] trunk/phase3/maintenance

ialex@... wrote:
> Moved constant definition to populateParentId.inc, throws an E_NOTICE when used by update.php, thanks
to MinuteElectron for reporting it.
> 
> +define( 'BATCH_SIZE', 200 );

A more general problem is that this is a pretty generic name; a
BATCH_SIZE is defined with a different value in updateRestrictions.php
and could easily appear elsewhere.

-- brion vibber (brion @ wikimedia.org)

Re: [MediaWiki-CVS] SVN: [34137] trunk/phase3/includes/filerepo/File.php

On Sat, May 3, 2008 at 11:17 AM, Bryan Tong Minh
<dev.btongminh@...> wrote:
> Revision: 34137
>  Author:   aaron
>  Date:     2008-05-02 21:29:05 +0000 (Fri, 02 May 2008)
>
>  Log Message:
>  -----------
>  Don't keep puring squids for images where no thumb is needed (bug 13776)
>
>  Modified Paths:
>  --------------
>    trunk/phase3/includes/filerepo/File.php
[...]
>
>  +                       if ( $wgUseSquid && !$thumb->isError() && $thumb->url != $this->getURL() ) {
>                                SquidUpdate::purge( array( $thumbUrl ) );

Now that I think about it, shouldn't a purge also be triggered on
error during thumb generation?

Bryan

Re: [MediaWiki-CVS] SVN: [34137] trunk/phase3/includes/filerepo/File.php

On Sat, May 3, 2008 at 11:18 AM, Bryan Tong Minh
<bryan.tongminh@...> wrote:
> On Sat, May 3, 2008 at 11:17 AM, Bryan Tong Minh
> <dev.btongminh@...> wrote:
>> Revision: 34137
>>  Author:   aaron
>>  Date:     2008-05-02 21:29:05 +0000 (Fri, 02 May 2008)
>>
>>  Log Message:
>>  -----------
>>  Don't keep puring squids for images where no thumb is needed (bug 13776)
>>
>>  Modified Paths:
>>  --------------
>>    trunk/phase3/includes/filerepo/File.php
> [...]
>>
>>  +                       if ( $wgUseSquid && !$thumb->isError() && $thumb->url != $this->getURL() ) {
>>                                SquidUpdate::purge( array( $thumbUrl ) );
>
> Now that I think about it, shouldn't a purge also be triggered on
> error during thumb generation?
>
> Bryan
>

Never mind, was already fixed by aaron in r34140.

Bryan

Re: [MediaWiki-CVS] SVN: [34169] trunk/phase3

> From: vasilievvv@... <vasilievvv@...>
> Date: May 3, 2008 3:09 PM
> Subject: [MediaWiki-CVS] SVN:  [34169] trunk/phase3
> To: mediawiki-cvs@...
>
>
> Revision: 34169
>  Author:   vasilievvv
>  Date:     2008-05-03 13:09:34 +0000 (Sat, 03 May 2008)
>
>  Log Message:
>  -----------
>  * (bug 709) Cannot rename/move images and other media files.
>  Currently in experimental mode, use $wgAllowImageMoving to enable it.
>  Known issues:
>  * Doesn't work with rev_deleted
>  * May also have some security and caching issues.
>
[...]
>  +                               if( preg_match( '/^(\d+)px-/', $file,
> $matches ) ) {
>  +                                       list( $unused, $width ) = $matches;
>  +                                       $this->thumbs[] = array(
>  +                                               $thumbDirRel . '/' . $file,
>  +                                               $newThumbDirRel . '/'
> . $width . 'px-' . $this->newName
>  +                                       );
>  +                               } else {
>  +                                       wfDebug( 'Strange file in
> thumbnail directory: ' . $thumbDirRel . '/' . $file );