4 ms·
The issue at hand here is interesting: GIT _commit_ integrity is not guaranteed over all operations, even if you sign commits. The problem is that GIT often ch
by Argorak 11y ago
The issue at hand here is interesting: GIT _commit_ integrity is not guaranteed over all operations, even if you sign commits.
The problem is that GIT often changes commit details. If you, for example, rebase or cherry-pick a commit, the identity changes - as the commit includes a reference to the parent commit(s). This means that once you do any of those (standard) operations, the signature becomes invalid.
Signing only makes sense on a tag level or in repositories that keep all commits and never change them (e.g. by explicitly merging and adding merge commits).
There are systems that preserve commit integrity during all of those operations, e.g. DARCS.
- pornel 11y agoIMHO git does it right. If signature was only at the commit level you could do a variant of replay attack. For example you could cherry-pick all commits except security fixes and create a malicious version of the software that has all commits still signed by the original author.
- Argorak 11y agoI was not saying that the signature is _just_ at a commit level ("patches" being the DARCS lingo). DARCS, just as git, has tags for that. A tag depends on all previous patches, so a signed tag guarantees just the same as a signed git tag does. In that regard, git is strictly less powerful.