Wikitech-l September 2011

wikitech-l@lists.wikimedia.org

111 participants
128 discussions

Re: [Wikitech-l] Adding MD5 / SHA1 column to revision table (discussing r94289)
by bawolff 18 Sep '11

18 Sep '11

Anthony wrote: > It does not involve generating hash collisions, but it involves > finding various bugs in mediawiki and using them to vandalise, often > by injecting javascript. The best description I could find was at > Encyclopedia Dramatica, which seems to be taken down (there's a cache > if you do a google search for "grawp wikipedia"). There's also a > description at http://en.wikipedia.org/wiki/User:Grawp , which does > not do justice to the "mad hacker skillz" of this individual and his > intent on finding bugs in mediawiki and exploiting them. > Say what? Being able to inject js is a very serious vulnerability. If he's doing this, why haven't I seen any security releases triggered by a vandal finding an XSS? has no one reported it? The pages you link to seem to indicate he's nothing more than a willy-on-wheels type vandal, who at worst tricked an admin into doing a delete of a page with a very high number of revisions making the server kittens cry for a moment. There's no indication he has "mad hacker skillz" in any way or form (and given the tone of that Encyclopedia Dramatica page, I assume they'd be bragging about it if he did). -bawolff

2 2

Re: [Wikitech-l] Adding MD5 / SHA1 column to revision table (discussing r94289)
by Russell N. Nelson - rnnelson 18 Sep '11

18 Sep '11

It is meaningless to talk about cryptography without a threat model, just as Robert says. Is anybody actually attacking us? Or are we worried about accidental collisions? Sent from my Verizon Wireless Phone -----Original message----- From: Robert Rohde <rarohde(a)gmail.com> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> Sent: Sun, Sep 18, 2011 05:56:15 GMT+00:00 Subject: Re: [Wikitech-l] Adding MD5 / SHA1 column to revision table (discussing r94289) On Sat, Sep 17, 2011 at 4:56 PM, Anthony <wikimail(a)inbox.org> wrote: > On Sat, Sep 17, 2011 at 6:46 PM, Robert Rohde <rarohde(a)gmail.com> wrote: >> Is there a good reason to prefer SHA-1? >> >> Both have weaknesses allowing one to construct a collision (with >> considerable effort) > > Considerable effort? I can create an MD5 collision in a few minutes > on my home computer. Is there anything even remotely like this for > SHA-1? If I've been keeping up to date, the collision complexity for MD5 is about 2^21 operations, and runs in a few seconds (not minutes); and for SHA-1 down to about 2^52 with current results. The latter represents about 100 cpu-years, which is within the realm of supercomputers. That time will probably continue to come down if people find ways to improve the attacks on SHA-1. (The existing attacks usually require the ability to feed arbitrary binary strings into the hash function. Given that both browsers and Mediawiki will tend to reject binary data placed in an edit window, I'm not sure if any of the existing attacks could be reliably applied to Mediawiki editing.) If collision attacks really matter we should use SHA-1. However, do any of the proposed use cases care about whether someone might intentionally inject a collision? In the proposed uses I've looked at it, it seems irrelevant. The intentional collision will get flagged as a revert and the text leading to that collision would be discarded. How is that a bad thing? It's a not a big deal, but if I understand prior comments correctly, most of the existing offline infrastructure uses MD5, so I'm wondering if there is a distinct use case for favoring SHA-1. >> MD5 is shorter and in my experience about 25% faster to compute. >> >> Personally I've tended to view MD5 as more than good enough in offline analyses. > > For offline analyses, there's no need to change the online database tables. Need? That's debatable, but one of the major motivators is the desire to have hash values in database dumps (both for revert checks and for checksums on correct data import / export). Both of those are "offline" uses, but it is beneficial to have that information precomputed and stored rather than frequently regenerated. -Robert Rohde _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

4 7

Re: [Wikitech-l] Adding MD5 / SHA1 column to revision table (discussing r94289)
by Russell N. Nelson - rnnelson 18 Sep '11

18 Sep '11

What is the threat? Sent from my Verizon Wireless Phone -----Original message----- From: Ilmari Karonen <nospam(a)vyznev.net> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> Sent: Sun, Sep 18, 2011 20:20:34 GMT+00:00 Subject: Re: [Wikitech-l] Adding MD5 / SHA1 column to revision table (discussing r94289) On 09/18/2011 08:55 AM, Robert Rohde wrote: > people find ways to improve the attacks on SHA-1. (The existing > attacks usually require the ability to feed arbitrary binary strings > into the hash function. Given that both browsers and Mediawiki will > tend to reject binary data placed in an edit window, I'm not sure if > any of the existing attacks could be reliably applied to Mediawiki > editing.) I'm pretty sure MediaWiki will accept any data that's valid UTF-8, modulo canonicalization perhaps. I'm not very familiar with the MD5 and SHA-1 collision attacks, but I wouldn't be surprised if at least some of them could be modified to use, say, only 7-bit ASCII. > If collision attacks really matter we should use SHA-1. However, do > any of the proposed use cases care about whether someone might > intentionally inject a collision? In the proposed uses I've looked at > it, it seems irrelevant. The intentional collision will get flagged > as a revert and the text leading to that collision would be discarded. > How is that a bad thing? Well, if you could predict the content of a version that someone (say, a bot) was likely to save sometime in the future, and created a different revision with the same hash (say, in the sandbox or in your userspace, so that people wouldn't notice it) in advance... Depending on just what page was targeted, the consequences could range from a minor annoyance to site-wide JS injection. Anyway, I wouldn't suggest using either MD5 or SHA-1: both have known attacks, and it's a fundamental rule of cryptography that attacks always get better over time, never worse. Let's _at least_ use SHA-2. (Actually, I'd suggest designing the format so that we can change hash functions in the future without having to rehash every old revision immediately. For example, we might store a hash computed using SHA-256 as "sha256:d9014c4624844aa..." or something like that.) -- Ilmari Karonen _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

1 0

Why is the "transwiki-importer" bit so tightly bound at WMF?
by Billinghurst 18 Sep '11

18 Sep '11

I am wondering why at WMF the ability to award the bit for "transwiki-importer" is restricted so that local bureaucrats are unable to award it. At this stage one has to get a steward to award that bit, or to get a bugzilla request to be implemented on a per wiki basis so that 'crats can do it. The "transwiki-importer" gives one permission right, and it is one that is automatically assigned to an administrator, so it seems weird that a 'crat can give an administrator right, yet cannot give a transwiki-importer. I was thinking that it is probably an archaic restriction that has neither been noticed nor updated, and I was wondering whether it was a time for a review and update. For numbers of the smaller WMF wikis, it would seem a useful bit, especially cross-project wikis, or for importing from the xxWPs where it is determined that it is not a WP matter. Or am I missing something historical/hysterical? Regards, Andrew

1 0

Re: [Wikitech-l] page view stats redux
by Harry Burt 18 Sep '11

18 Sep '11

Ariel T. Glenn wrote: > I think we finally have a complete copy from December 2007 through > August 2011 of the pageview stats scrounged from various sources, now > available on our dumps server. Great news! I do think there should be a note about the systemic under-reporting that made statistics from the last quarter of 2009 and first half of 2010 unreliable, however. -- Harry (User:Jarry1250)

2 1

Spammer
by Strainu 17 Sep '11

17 Sep '11

Would someone please ban this email address from wiki mailing lists? This is the third email from him.... Thanks, Strainu 2011/9/17 William Nelson <eyelikepills(a)yahoo.com>:

2 1

Picture of the Year torrents
by emijrp 16 Sep '11

16 Sep '11

Hi all; I have created two torrent files for the PIcture of the Year dumps[1]. They use Wikimedia server as webseed.[2][3] Can you add them to the page? Thanks, emijrp [1] http://dumps.wikimedia.org/other/poty/ [2] http://burnbit.com/torrent/177023/poty2006_zip [3] http://burnbit.com/torrent/177024/poty2007_zip

4 4

(no subject)
by William Nelson 16 Sep '11

16 Sep '11

<a tabindex="1" title="" name="rrqvyuwibb" href="http://zoefrench.com/wp-content/themes/victorian/img/clreefg.htm">http://zoefrench.com/wp-content/themes/victorian/img/clreefg.htm</a>

1 0

Re: [Wikitech-l] Upcoming MediaWiki 1.18 deployment
by bawolff 16 Sep '11

16 Sep '11

> Do they work correctly? > Some metadata tests have been failing to me for a long time, though I > didn't bother to find out the root cause. > > If that code is yours, you may want to take a look. > > More specifically: > FormatMetadataTest::testInvalidDate > BitmapMetadataHandlerTest::testMultilingualCascade > JpegTest::testJpegMetadataExtraction > ExifRotationTest::testMetadata (dataset #1) > ExifRotationTest::testWidthFlipping > > Results in REL1.18 are a bit different, although they look to be older > tests? That's concerning. They work for me perfectly fine and seem to work on cruise control. What's the error they're failing with? Thanks, Bawolff

2 1

Upcoming MediaWiki 1.18 deployment
by bawolff 16 Sep '11

16 Sep '11

> Message: 4 > Date: Thu, 15 Sep 2011 16:30:44 -0700 > From: Rob Lanphier <robla(a)wikimedia.org> > Subject: [Wikitech-l] Upcoming MediaWiki 1.18 deployment > To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > Message-ID: > <CAPzpXh6LUJPB0Rn6K9NGKQmA2aipWf_X7cShU5s5D-f8+7Bftg(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi folks, > > I just wanted to quickly highlight the plan that we have for deploying > MediaWiki 1.18 to the Wikimedia sites: > > * Monday, September 19 (-20), 23:00-01:00 UTC (4pm-6pm PDT): > MediaWiki 1.18 deployment to test2 > * Wednesday, September 21 (-22), 23:00-03:00 UTC (4pm-8pm PDT): > MediaWiki 1.18 stage 1 deployment (simplewiki, simplewiktionary, > usabilitywiki, strategywiki, mediawikiwiki, hewikisource) > * Monday, September 26 (-27), 23:00-03:00 UTC (4pm-8pm PDT): > MediaWiki 1.18 stage 2 deployment (metawiki, enwikiquote, enwikibooks, > betawikiversity, eowiki, nlwiki) > * Tuesday, October 4 (-5), 23:00-03:00 UTC (4pm-8pm PDT): MediaWiki > 1.18 stage 3 deployment (remaining wikis) > > More about MediaWiki 1.18 can be found here: > http://www.mediawiki.org/wiki/MediaWiki_1.18 > > The main blocker right now? Code review: > http://www.mediawiki.org/wiki/MediaWiki_roadmap/1.18/Revision_report > > See Mark's email earlier today for more detail on this. Please chip > in where you can. > > Thanks! > Rob btw, could refreshImageMetadata.php be run on wmf wikis some time after the deployment? 1.18 contains lots of new code related to Exif support (and related image metadata stuff). The maintenance script just regenerates img_metadata based on the source image. -bawolff

3 2

← Newer
1
...
4
5
6
7
8
9
10
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l September 2011