Slashdot Mirror
Apache Subversion Fails SHA-1 Collision Test, Exploit Moves Into The Wild (arstechnica.com)
WebKit's bug-tracker now includes a comment from Friday noting "the bots all are red" on their git-svn mirror site, reporting an error message about a checksum mismatch for shattered-2.pdf. "In some cases, due to the corruption, further commits are blocked," reports the official "Shattered" web site. Slashdot reader Artem Tashkinov explains its significance:
A WebKit developer who tried to upload "bad" PDF files generated from the first successful SHA-1 attack broke WebKit's SVN repository because Subversion uses SHA-1 hash to differentiate commits. The reason to upload the files was to create a test for checking cache poisoning in WebKit.
Another news story is that based on the theoretical incomplete description of the SHA-1 collision attack published by Google just two days ago, people have managed to recreate the attack in practice and now you can download a Python script which can create a new PDF file with the same SHA-1 hashsum using your input PDF. The attack is also implemented as a website which can prepare two PDF files with different JPEG images which will result in the same hash sum.
Another news story is that based on the theoretical incomplete description of the SHA-1 collision attack published by Google just two days ago, people have managed to recreate the attack in practice and now you can download a Python script which can create a new PDF file with the same SHA-1 hashsum using your input PDF. The attack is also implemented as a website which can prepare two PDF files with different JPEG images which will result in the same hash sum.
Here's what it means: One major aspect of modern cryptography are "hash functions"- a hash function is a function which essentially has the property that in general two inputs with very small differences will give radically different outputs. Also, ideally a hash function will also make it hard to detect "collisions" which are two inputs which have the same output. In general, hash schemes are used for a variety of different purposes, including determining if a file is what it claims to be (by checking that the file has the correct hash value).
Every few years, an existing hash system gets broken and needs to be replaced. MD5 is an example of this; it was very popular and then got replaced.
One of the major currently used hash schemes is SHA-1. However, a few days ago, a group from Google described an attack that allowed them easily find collisions in SHA-1 (easy here is comparative- the amount of computational resources needed was still pretty high). The group released evidence that they could do so but didn't describe how they did so in detail. They gave an example of two files with a SHA-1 collisions and they also described some of the theory behind their attack. What TFS is talking about is how based on this, others have since managed to duplicate the attack and some make some even more efficient variants of it; so effectively this attack is now in the wild.
The problem with git, and I don't see it as a major problem, is not that it's hard to get up and running, but rather that you can quite easily get into the kind of trouble that needs expert knowledge to get out of. If you don't happen to have a git expert handy; well, you are going to have a very bad day. In this git shares the same problem as most very powerful tools, for example C. So I agree with the original poster, if you need the facilities of git, then you'd be an idiot to not use it, but if you don't, then other tools are better for simpler uses cases. Much like using something like python makes a huge amount of sense for certain applications, and zero sense for writing kernels.
I love arguing about git.
SVN has several huge advantages over git. It's far simpler. It doesn't have a thing called 'rebase', which rewrites your commits and occasionally messes them up. Its revision numbers are actually in order, which means you always know which revision came first, given two of them, something that's impossible with git's hashes (YES - I know why the hashes are used... but the reality of 99% of software development is that the repository is centralised, so git's solving an almost non-existent problem here). SVN supports real cherry-picking, and actually records in the repo that you took code from somewhere, as opposed to git's cut-n-paste approach.
SVN has branches, git has pointers into a tree. Thus in git, it is impossible after the fact to determine to which branch a change was committed, just in which branches it now currently resides. Branches don't really exist in git at all, they aren't versioned (who created a branch, and when?), and if you accidentally delete them you tend to lose the commits against them. Tags in git are even worse. Added to which is the fact that both are implemented in the filesystem as regular files, which means you're at the mercy of your filesystem's ideas regarding case and permitted characters, and good luck if someone tries to check it out into a filesystem with different ideas. Nice design decision there Linus, guess you were having an off day? And the line-endings stuff?... Oh. My. God.
It is a bitwise rotation. The direction and number specify if it is a right or left rotation and then how many bits to rotate.
A hash function takes an arbitrary string of bits and outputs a string of bits of a fixed length.
A CRC is an example of a hash function and a long CRC would probably be good enough for GIT or most repositories.
First Pre-image resistance - this is a test of the one wayness of the function. Given a hash value it is difficult to find a pre-image that hashes to that value. Given y a string of bits of length hash output length finding X such that h(X) = y is hard.MD-5 and SHA-1 are still resilient against first pre-image attacks
Second Pre-image resistance - given a message X finding a Y such that h(X)=h(Y) is difficult. MD-5 and SHA-1 are still resilient against second pre-image attacks
Collision resistant - It is hard to find two messages X and Y such that h(X) = h(Y). Note the attacker here is free to choose both X and Y. Both MD-5 and SHA-1 are no-longer collision resistant.
So far however the two messages X and Y have to be nearly identical. They have to start and end the same way and the blocks that are changed actually have to be changed and tested together to make sure the hash function internal state changes only in a specific way. I can't create a document that says the rent will be $3000 per month and another that says it will be $30000. (I might create one that says it is $3149.21 and the other $53210.63 per month, like in the PDF example they played with a colour field). Also because of the way the internal state of the hash function changes we now have a way of detecting if someone is feeding a "funny" stream of bits into our hash function and detect this attack with a very low probability of a false positive.
> I'd give alot to go back to revision numbers...
Why? All that matters is the logical ordering of commits, not the chronological ordering. I DGAF about when someone wrote a bit of code. All that I want is for each commit to more or less work, and for the history to be easily bisectable to aid in bug hunting.
> Git gives a conflict in the first case - naturally - and may give a conflict in the second if its magic content-tracking algorithm fails...
As an SVN -> Git convert, I've had git just Do The Right Thing(TM) when committing changes to a moved file more times than I can count. I lost _weeks_ of my life to doing that shit manually with SVN. I get that content tracking doesn't work 100% of the time, but it works infinity% of the time more often than it does in SVN.
> Branches don't really exist in git at all...
what?
> they aren't versioned (who created a branch, and when?),
wot?!
If you look at this https://github.com/inaka/shotgun/compare/dave.151.update.deps.to.2.0.0.pre It's obvious that euenlopez@gmail.com created that branch on June 02, 2016. This one-liner makes it doubly clear that this isn't github trickery:
git log `git log master..dave.151.update.deps.to.2.0.0.pre --oneline | tail -n 1 | awk '{ print $1 }'` | head -n 3
(The git log invocation inside the backticks gives you the commits that dave.151... has that master doesn't, putting the "oldest" at the bottom. The tail/awk pipe scrapes out the commit ID of the "oldest' commit. That commit ID is fed to the outer git log, and the first three lines of that log are scraped off by head.)
> ...and if you accidentally delete them you tend to lose the commits against them.
a) If you delete a branch, you don't want the commits in it.
b) But if you _did_ want those commits, git reflog saves you from your mistakes
c) man git-reflog , for $DEITY's sake
Don't get lost in the terminology of the man page. Just make a git repo, perform some changes to it (some small, some large) and play with git reflog.
Every change you make to a local repo is stored locally, for 90 days -by default-. git reflog lets you sort through that and restore the pointers that you carelessly blew away.