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 s

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.