Before anyone panics, this is not something that people who run mediawiki wikis have to worry about. -- Brian On Friday, February 24, 2017, Pine W <wiki.pine(a)gmail.com> wrote: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

Yes, keep an eye out for announcements about other software that might be more seriously affected. For instance Subversion source control has some problems which can cause checksum errors when operating on a source tree that has had the malicious pairs of files committed into to it: https://arstechnica.com/security/2017/02/watershed-sha1-collision-just-brok… My initial look at potential attacks on MediaWiki is that our case is less severe; if conflicting files are uploaded they may trigger false equivalency warnings (with each other only), and can overwrite each other (but not other files) when deleted/undeleted. No errors would be thrown or general data corruption would occur. -- brion On Fri, Feb 24, 2017 at 1:27 PM, Pine W <wiki.pine(a)gmail.com> wrote:

Yes, I agree with what Florian just said. So basically the current state of things: Its possible to make 2 pdf files that mediawiki thinks are identical despite not being. If you uploaded both of them mediawiki will say they are duplicates on the image description page and on special:listduplicatefiles (or whatever that special page is named). More concerningly is if you delete both files you probably will only be able to undelete one of them. This sounds bad but its not actually that bad. The reason its not that bad is you can only do this for pairs of specially prepared files where *both* are specially prepared. You cant upload an evil file that matches some other file someone else uploaded. As it stands, its easy to do this attack with 2 pdf files that have different content (with some restrictions on the content of the pdf files) https://alf.nu/SHA1 . If you want to do it with some other file format or use a more specificly crafted file, it will cost you about $100,000 in computing resources. -- Brian On Friday, February 24, 2017, Florian Schmidt < florian.schmidt.welzow(a)t-online.de&gt; wrote: considered. Is that correct, Brian it, right? Speaking about MediaWIki _users_: If there's really a problem with SHA-1 in their setup, they usually (unfortunately) can't do anything about it, as it's clearly implementation and not configuration. I think (without speaking for him), that’s what Brian wanted to say :) MediaWiki users and even site admins can't change anything here, this has to be handled by developers (if site admins want to join as developers: You're welcome! :)) and they should usually subscribe to wikitech-l, too :P Auftrag von Pine W mediawiki-l(a)lists.wikimedia.org&gt; least one more, it's something that I want to know about. :) More info at https://phabricator.wikimedia.org/T158986, although if I understand the conversation on the Phabricator task correctly, the consensus is that migration off of SHA-1 for MediaWiki software is important but doesn't need to happen overnight because the attack is difficult to execute; however, possible attacks on other software that still runs SHA-1 should be considered. Is that correct, Brian?