Hacker News Reader

Comment by eboyjr | Hacker News Reader

Git is cryptographically secure, but it's not foolproof.

However signing a single commit verifies the parent commits (similar to the blockchain) so it isn't necessary for every commit.

Signing tags and commits is great, but if you decide to use this in your normal workflow, you’ll have to make sure that everyone on your team understands how to do so. If you don’t, you’ll end up spending a lot of time helping people figure out how to rewrite their commits with signed versions. Make sure you understand GPG and the benefits of signing things before adopting this as part of your standard workflow.

View on HN

Git offers the _option_ to sign commits. Git itself makes no guarantees that a commit's author is who it's listed to be, unless you use signed commits.

Signing a commit does not verify parent commits in the way I think you think it does. It does give the guarantee of 'These are the commits that are the basis of my commit', but that is only worth as much as what your signature actually conveys. Your signature certainly conveys you authored your commit, but it doesn't guarantee that the parent commit was authored by who was listed as the author.

I do this for a year now with my gpg key, haven't had a moment where this was of any use. yet.

Signing a commit does "sign" all previous commits, but it doesn't verify that they are actually yours, you still have to manually do that. If someone slips in a "fake commit" either directly on to your machine, or does it to remote and you pull it down and commit and sign a tag, you won't get any kind of notification there is an issue.

IMO it's better to sign all commits, as then it gets you in the habit of knowing how it's done, you are less likely to make mistakes while doing it, and you can add tooling that will sound alarms at the first unsigned commit.

It does leave you more vulnerable to keyloggers, and gives more instances where your key is decrypted and used, but I personally think that's a better problem to have rather than having to manually verify every single commit isn't forged before you sign and tag.

Is Git cryptographically secure?

Linus certainly doesn't see this as a goal of Git. Against what threats does the cryptography protect? Has anyone published the threat model of Git? Things I worry about:

1. Can I reorder commits without access to secret keys?

2. What if one secret key is compromised, do I have to resign all my old commits with the new secret key? How do I do that?

3. How do I ensure my list of authorized keys is the same as yours?

4. Can I easily detect that my code signing key has been compromised?

5. How do you prevent a Pull Request that contains a unittest that when run exfils your keys, opens a shell, injects source code or backdoors git?

> Is Git cryptographically secure?

Not right now, because it still uses SHA-1. But apart from that, the answers are:

> 1. Can I reorder commits without access to secret keys?

No, because a hash of some commit data is what’s signed and the parent is part of that

> 2. What if one secret key is compromised, do I have to resign all my old commits with the new secret key?

No, just make a new commit on top with the new key explicitly explaining that you trust the old stuff

> 3. How do I ensure my list of authorized keys is the same as yours?

I don’t understand that question. Can you expand on it?

> 4. Can I easily detect that my code signing key has been compromised?

No, and the same goes for pretty much anything else that can be compromised.

> 5. How do you prevent a Pull Request that contains a unittest that when run exfils your keys, opens a shell, injects source code or backdoors git?

You read it before you run it.

Really appreciate your answers. I've wondered about this stuff for a while but never had the time to read through the Git source code.

>No, because a hash of some commit data is what’s signed and the parent is part of that.

How does this work with cherry picks or rebases? Would it just be authorized by the key of the person doing the rebase and lose the authentication of the original commits? How would this complicate say forensics investigation attempting to understand how authored a backdoor?

>I don’t understand that question. Can you expand on it?

Lets say I am a member of an organization and I am syncing a git repo for the first time. How do I ensure that the code I am getting was only authored by members of that organization? Who does the work of adding new keys for new members, revoking old keys when employees leave or keys are compromised? How does everyone agree on this key set?

> No, and the same goes for pretty much anything else that can be compromised.

I agree to determining key compromise is impossible but the detection of use of compromised keys in a suspectious manner is certainly possible. Consider a chain of one-use keys where each key is only used once per commit and then deleted. Using a key twice triggers alarms and emails.

>You read it before you run it.

You should read it before you run it however everyone makes mistakes and detecting underhanded programming techniques is hard. One could imagine a source code system that would warn users that the code they are about to run has not been authored by anyone in their organization.

> How does this work with cherry picks or rebases? Would it just be authorized by the key of the person doing the rebase and lose the authentication of the original commits?

Yes.

> ⋮

Sounds like your organization will need to put a lot of new stuff on top of PGP and Git, then.

Reply on news.ycombinator.com