Hacker News Reader

Comment by kzrdude | Hacker News Reader

That's just some mantra to shape the discussion in the way they like.

Git allows signing tags and commits, and those features are now broken because all object names use SHA1.

So wait, when is SHA-1 ever used for signing tags and commits in git? that's new to me..

My understanding was you're using a public key type of encryption such as PGP at that point. I feel I may be missing the point here. (apologies if so)

My original statement is slightly incorrect; you can. The commit hash is probably used as part of the signature. It would have been better to sign the commit blob directly, as Git stores the length alongside the hash from that point down in the DAG (making prefix attacks impossible).

I sign all my commits. Github even make it easy to see: https://github.com/blog/2144-gpg-signature-verification And I also use it in a few places e.g. for http://hashbang.sh/, we only allow signed commits into master

However, as far as I know, when you sign a git commit you are actually sign the hash of the commit. With SHA-1 broken in the current way it essentially means someone with 110K to burn could forge a commit and reuse my PGP signature.

Well holy smokes. I don't know which repository you contribute to, but if you're getting undermined by such James Bond-esque deception by super villains, in addition to someone spending 6 figures into breaking your stuff, I'd hope you'd at least review the commits you sign with your key after glancing at it.

In addition, you'd have to have everyone else not notice it, all the insanely cheaper exploits not been tried on your current setup, and all the other stars aligning...

I'll also mention literally the first setup step to Git for most people: https://help.github.com/articles/set-up-git/ or similar.

That might be a hint that Git isn't something which you should allow it to handle the security. Literally the first step to the entire thing: pick any email or name...

Please provide reasonable security policies in your repos--and if someone is exploited, you've probably got far bigger problems than someone duplicating a sha-1. Not necessarily, but highly likely your system is owned.

Yes, if you sign off on commits you haven't reviewed to confirm the diffs at all, and they're carefully crafted files to make the collision, you may commit a duplicate sha-1, which still doesn't even break Git.

This is an important distinction. Without a preimage attack on sha-1, the only vulnerability is if some part (yet any part) of the git objects reachable from the signed tag or commit is one half of a prepared collision pair.

What you need to understand, is that Git's data structures are essentially annotated Merkle trees [1]. So whatever you sign, be it a tag or a commit, it will be nested sha1 hashes like [someData].sha1([someData].sha1([someData].[aFile]).[someData]).[someData] . And at every level you can conceivable construct a hash collision. So if e.g. you create your own commit on top of a commit of an attacker and sign your commit, you are only signing a (sha1 of a sha1 of a) sha1 of the commit of the attacker. If the attacker's commit was crafted to enable a sha1 collision somewhere, then your signed commit doesn't cover the files and commits you see, but only the sha1 hashes of those objects.

This kind of hairy distinction of what a signature was supposed to mean and what it actually covers is what you get with (semi-)broken cryptographic primitives. It's awful and, frankly, unnecessary.

[1] https://en.wikipedia.org/wiki/Merkle_tree

I appreciate that info, +1. My main point was just if you're dealing with a repository where actors that have those 6 figures to spare to attack you (and that's a minority):

1) you've got to rely on a lot better security than the minimal if at all security provided by git (it assumes a web of trust). If people are signing off with PGP sigs but not watching diffs, you've got big problems.

2) You're probably far more likely to be exploited by far cheaper methods at this point. If they have access to a trusted contributor's keys, it's far more cost effective to slip in other tricks than sha-1 collisions right now. I'd say this is the main point so far, but admittedly maybe not in the future.

3) It sounds like Linus and the git devs have admitted they need to migrate from sha-1, but also I haven't seen any cheap, exploitable PoC for git yet based on this due to how they actually mix in other info instead of raw sha-1 hashes of the files.

4) As far as I know, and I'm sure I'm subject to correction, but there hasn't been a WebKit svn repo-esque calamity yet like what they've experienced dropping 2 sha-1 collision PDFs into the repo in a Git context yet.

Again, I'm totally open to new info, but the sky-is-falling attitude right now is what I'm mainly arguing against.

If you drop two identical files into a linux repo then they will be rejected by the maintainers. You don't even need to get into a technical solution to prevent it.

Reply on news.ycombinator.com