You must log in or register to comment.
- 10 days
I tried to implement my own git from scratch. And when I got to choose a hashing algorithm, I reached the exact same conclusion as the author pretty fast.
The hashing algorithm doesn’t really matter as long as it’s good enough to prevent accidental collisions. And if there is a collision, it is extremely easy to check.
If you are about to create a new object and an object with that hash already exists, you compare the 2 objects. If they are the same, nothing happened. If they are different, you just found a collision. Throw some obscure error that will only be witnessed once in the lifetime of the universe and be done with it. Tell the user to change a single bit of the input and be done with it.
The purpose of object hashes in git was never to provide security. Security is achieved through other means.
- 9 days
Security is achieved through other means.
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 [public key ID] - set git to sign your commits:
git config --global commit.gpgsign true
Note 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: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) <[email protected]> <- 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 signLast, 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)- 8 days
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.- 8 days
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.
- 8 days
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.
- 8 days
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.
- generated a gpg key:
- UnfortunateShort@lemmy.worldEnglish10 days
There are some very good points in there, I would like to hear the counter-arguments.
Which are? I’m not joking, “GitHub broken” and “Google has issues” are not arguments against a better encryption default.
The submodule argument is transitional at best.
As for the pro side (note that this is my opinion, I’m not deeply involved in the discussion - and with not deeply I mean “not at all”):
The case the author aggressively ridiculed ("I don’t use GPG to trust, I trust the GitHub authentication!) is one that anyone would have if they’d want to stay safe from centralized systems.
Another is upstream availability: once an algorithm is identified as broken (no matter how small) usage drops rapidly - there’s a reason why no one uses md5 anymore although it “would be fine” for purely collision mitigation.
And then there the simple fact that the integrity hash is a security feature, not purely anti collision (as the author also describes). Just because they (nor I!) can’t see an attack vector at the moment doesn’t make this less of an issue.
In short: it’s the other way around: you’d need way stronger arguments than “there will be a transition pain” to knowingly compromise your security.
- Wojwo@feddit.onlineEnglish9 days
I still like md5 for collision detection, but every damn security scanner flags it. So then you have to add the exception, then explain to auditors about the exception. It’s not worth the hassle for the increased performance.
- 8 days
There’s no reason to use md5 if you don’t care about security and only want speed. Non-cryptographic hashes are incredibly fast to calculate and there are far faster hashing algorithms if you want to go that route. Using md5 is a “I don’t want to think hard” answer, and if you don’t want to think hard, then you might as well be secure in your default answer.