4 ms·

> 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

> 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.

EthanHeilman 8y ago
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.
- minitech 8y ago
  > 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.

EthanHeilman 8y ago

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.

minitech 8y ago
> 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.