this post was submitted on 05 Oct 2026
88 points (92.3% liked)
Programming
28764 readers
333 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Let's explicit this: you can, and should, sign your commits if you want security (no commit tampering). You need to:
gpg --full-generate-keygit config --global user.signingkey [public key ID]git config --global commit.gpgsign trueNote that I used
--globalhere but you can do without to sign on a per-project basis.Also
gpgUX is terrible, to find the[public key ID]use the commandgpg --list-keys, it should looks like:Last, if you want to save/backup you keys the default location of
gpgfiles is~/gnupgor you can export keys withgpg --export [key ID] > path/to/file.keyfor the public part andgpg --export-secret-keys [private key ID]for the private part. Both export can have a-aor--armorargument to output as base64 text instead of raw binary.[private key ID]can be found withgpg --list-secret-keys.EDIT: after writing this I checked https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work and TIL you can sign tags too.
EDIT 2: you can also use your ssh key to sign ->
git config --global gpg.format ssh(I am less inclined to do this as you won't have subkeys and expiration date but this would be simplier indeed)Worth to keep in mind though that the
gpgsignature basically only signs the (git) hashes of the contained objects, so the choice of hash function is indeed important for security.~~Indeed it is still relevant~~. I am wondering what does it sign for tags.
EDIT: Are you sure about that? signing the hash felt logical but digging about it this seems a false assumption. git is signing the whole commit object.
Yes, but the "commit object" is just a bunch of metadata that refers to the tree by its hash:
And the tree in turn refers to the files (or subfolders) by their hashes:
If you can produce a hash collision, you can therefore have two repositories with the same signed commit but different file content.
Yes you are right, damned! Why git isn't signing the diff (patch)? This is so wrong on so many level, signing already hash the content, we can sign multiple GiB without any issue.
Hm, I wouldn't call it wrong on many levels, I think it's quite elegant. It's a form of a Merkle Tree, and knowing the hash of a commit does not just allow you to verify its content, but also the whole history up to that point (as the commit contains the hash of its parent, which in turn contains hashes of its content and parents). I guess that's not too unimportant if you consider scenarios where you pull code from distributed repositories (like forks), as you can ensure that the parts of the history you know are actually what they claim to be. And if you accept hash-then-sign as being secure, this is just as secure for signed commits (assuming the hash function is secure).
I think the only unfortunate part here is that git ended up using SHA-1 as a hash function, which 20 years ago might or might not have been a reasonable choice -- I don't know how "broken" it was regarded back then, or how widespread SHA-256 use was.