Git 3.0 will make SHA-256 the new default content hashing algorithm and it will be an incomprehensibly expensive and ultimately valueless and avoidable global nightmare.
Let’s explicit this: you can, and should, sign your commits if you want security (no commit tampering). You need to:
generated a gpg key: gpg --full-generate-key
set git to look for the public key to use: git config --global user.signingkey [publickey ID]
set git to sign your commits: git config --global commit.gpgsign true
Note that I used --global here but you can do without to sign on a per-project basis.
Also gpg UX is terrible, to find the [publickey ID] use the command gpg --list-keys, it should looks like:
pub ed25519 2026-01-01 [SC] <- type algorithm date and capability (this key is only to Sign and Certify)
662E3CDD6FE329002D0CA5BB40339DD82B12EF16 <- Public key ID
uid [ultimate] my full name (Master Key) <my_email@domain.com> <- owner information (should be your name and email address)
sub rsa4096 2026-01-01 [E] <- sub key used to encrypt
sub ed25519 2026-01-01 [S] [expires: 2027-01-01] <- subkey used to sign
Last, if you want to save/backup you keys the default location of gpg files is ~/gnupg or you can export keys with gpg --export[key ID] > path/to/file.key for the public part and gpg --export-secret-keys [private key ID] for the private part. Both export can have a -a or --armor argument to output as base64 text instead of raw binary. [privatekey ID] can be found with gpg --list-secret-keys.
Worth to keep in mind though that the gpg signature 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:
% git cat-file commit 6de20f6092
tree 5cb21f9acf8c31ce1a8f6bb0bbc3b9e4e8607ce8
parent c679abf7d2c0f3f4ee623e0882a50964e9b100cc
author Junio C Hamano <gitster@pobox.com> 1791306800 -0700
committer Junio C Hamano <gitster@pobox.com> 1791306812 -0700
The 4th batch
Signed-off-by: Junio C Hamano <gitster@pobox.com>
And the tree in turn refers to the files (or subfolders) by their hashes:
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.
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.
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:
% git cat-file commit 6de20f6092 tree 5cb21f9acf8c31ce1a8f6bb0bbc3b9e4e8607ce8 parent c679abf7d2c0f3f4ee623e0882a50964e9b100cc author Junio C Hamano <gitster@pobox.com> 1791306800 -0700 committer Junio C Hamano <gitster@pobox.com> 1791306812 -0700 The 4th batch Signed-off-by: Junio C Hamano <gitster@pobox.com>And the tree in turn refers to the files (or subfolders) by their hashes:
% git cat-file -p 5cb21f9acf8c31ce1a8f6bb0bbc3b9e4e8607ce8 | head 100644 blob fd4fb56b6d56789369d4824ad10999369127f5c7 .b4-config 100644 blob 8168d8a10b3a9e14f6c019e8ffbe5a71dc307d8b .b4-cover-template 100644 blob fef04a38402fee6465a6a4225374d493b47421c0 .cirrus.yml 100644 blob 86b4fe33e5cd98e2a347944559c345419824c245 .clang-format 100644 blob 82e121a41754b536611c9ce9b2b4aba349e7ed9d .editorconfig 100644 blob 26490ad60a74d0968eaf2f77abffcb21d78b18e3 .gitattributes 040000 tree 5f898fc5ec3429058fd21072db170fff9e49eab4 .github 100644 blob 0209bd16f209c232748734d911099b37be80fc12 .gitignore 100644 blob 3f2483550038f6aabb2f8b858b4ee7b29a66072a .gitlab-ci.yml 100644 blob cbeebdab7a5e2c6afec338c3534930f569c90f63 .gitmodulesIf 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.
If you want to avoid the gpg mess, you can actually also configure gut to sign with your SSH key.