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
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
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
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
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)
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>:
> 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
> 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