3 ms·
> Instead gpg signs the SHA-1 commit digest directly A minor correction: when signing a commit, gpg does not sign the SHA-1 digest of that commit. This is impo
by brasic 4y ago
> Instead gpg signs the SHA-1 commit digest directly
A minor correction: when signing a commit, gpg does not sign the SHA-1 digest of that commit. This is impossible since the signature becomes part of the commit header which is one of the inputs to the hash function that produces the oid.
Instead, GPG signs the serialized data (parents,headers,tree,message) which would otherwise be the input to SHA-1. Then the sig is inserted into the buffer at the end of the header and the string is digested to produce an oid.
Source: https://github.com/git/git/blob/39c15e485575089eb77c769f6da02f98a55905e0/commit.c#L1587 https://github.com/git/git/blob/39c15e485575089eb77c769f6da0...
- Zamicol 4y agoThank you for pointing this out, and thank you for the link the the relevant code section. Excellent comment.
- omegalulw 4y agoLmao how were you that confident in your original comment which basically claimed git signatures are only as secure as SHA-1.
- brasic 4y agoPerhaps you misinterpreted my reply. I didn’t intend to dispute parent’s claim, merely to correct a mechanical detail. Git signatures are more or less only as secure as SHA-1, although the properties it relies on are not yet compromised and several factors mitigate the real-world risk. A practical preimage attack on SHA-1 would seriously undermine the security of git signatures since the string being signed includes two or more SHA-1 hashes representing a content snapshot and the commit ancestry. Arbitrary preimage attacks would make it possible to modify a repo’s contents or history without invalidating oids or signatures. In practice only collision attacks have been found, all of which have a detectable signature that git has been modified to detect. Disclosure: I work at GitHub, but am speaking for myself.