It took only one day for the SHA1 collision attack revealed by Google on Thursday to make its first victims after developers of the WebKit browser engine broke their Subversion (SVN) source code repository on Friday.
While the issue was first spotted on the WebKit SVN, it affects all Subversion installations worldwide and is not something specific to the WebKit setup.
WebKit staff came across the issue when one of its engineers was trying to add a test case to the WebKit source code and see how WebKit, Safari's browser layout engine, would handle SHA1 collisions itself.
To test the SHA1 collision, the engineer uploaded the two PDF files that Google created for its SHA1 collision attack demo, which are two files with different content, but with an identical SHA1 hash signature.
As soon as the WebKit SVN repo processed the upload, the two identical SHA1 hashes caused the entire SVN installation to fail and stop accepting any new source code.
Reverting the upload and removing the two PDF files didn't help, as the SVN repo remained down. Syncing to mirror repositories also stopped and wouldn't start again. In other terms, everything got borked and for a few hours no one knew what was going on.
"Is it fixable, or are we just totally hosed?," asked one developer. Things did eventually recover, but the WebKit team had to abandon any plans to integrate a system for detecting SHA1 collisions in their own software.
Google engineers also independently tested and confirmed that SVN repositories will fail if users upload files with the same SHA1 hashes.
"Please exercise care, as SHA-1 colliding files are currently breaking SVN repositories," wrote the Google team on the SHA1 collision attack website.
"Subversion servers use SHA-1 for deduplication and repositories become corrupted when two colliding files are committed to the repository. [...] We noticed that in some cases, due to the corruption, further commits are blocked," Google added.
The Apache Foundation, the maintainers of Subversion, a source code syncing and management system, also confirmed the problem.
"It turns out that adding these two PDF files to a svn repository makes it impossible to checkout the repository properly if both files exist in the repo," they said.
On a very short notice, the SVN team has put together and released a script that executes before SVN commit operations and verifies if someone is tying to include known files that cause SHA1 collisions. The script is available for download here.
Apache also promised a better solution in the long term, one that doesn't rely on the impractical solution of scanning for previously-known files with the same SHA1.
Git, another source code management system, is not affected. Following SVN's problems, Linus Torvalds, Git's creator, said on Google+ they plan to migrate away from SHA1 hashes to a more stronger hashing function in the future.
Article updated to correct the script's mode of operation. An earlier version of this article said the script operated pre-checkout, not pre-commit.