Is it a good idea to GPG sign old git commits?
Rise to the top 3% as a developer or hire one of them at Toptal: https://topt.al/25cXVn
--------------------------------------------------
Music by Eric Matyas
https://www.soundimage.org
Track title: Puzzle Game 3
--
Chapters
00:00 Is It A Good Idea To Gpg Sign Old Git Commits?
00:39 Accepted Answer Score 13
01:33 Thank you
--
Full question
https://superuser.com/questions/1144817/...
--
Content licensed under CC BY-SA
https://meta.stackexchange.com/help/lice...
--
Tags
#git #gnupg
#avk47
ACCEPTED ANSWER
Score 13
If the commits have already been published, you should not rewrite them for any purpose (except removing accidental data leaks), as this would change their commit IDs. (Remember that each commit's ID is based on SHA-1 hashes of its content and its parent commit.)
That means it'd require rewriting (and resigning) all subsequent commits, and would cause troubles for anyone who had already fetched any of those commits.
But for the same reason, you don't need to sign those old commits explicitly, at least not for data integrity purposes. Since each commit contains SHA-1-based IDs of its parents, verifying any single commit will also implicitly verify its entire history via the hash chain. It doesn't matter that the chain is a little longer or shorter.
On the other hand, if you don't trust SHA-1 for security, then you should consider commit signing entirely useless, since commits' file contents are also referred to by SHA-1 hashes. The only thing you sign directly (and not a hash thereof) is the commit message.