Earlier quoted context omitted.
I fail to so what security you gain by trusting Github's key.
You get an attestation that the person that merged corresponds to a particular github identity. More importantly you know that at the time the person merged the commit they had a 2FA token that was valid. The only way the commit could have been forged is that at the time it took place, the user account itself was compromised.
Commit signing in 2023 is kinda wack
21–29 of 29 posts
Re: Commit signing in 2023 is kinda wack
#22Earlier quoted context omitted.
You get an attestation that the person that merged corresponds to a particular github identity. More importantly you know that at the time the person merged the commit they had a 2FA token that was valid. The only way the commit could have been forged is that at the time it took place, the user account itself was compromised.
Don't you get all those guarantees by just pulling from github? I guess it's nice that you get an attestation that you can verify offline, but it feels like a marginal benefit.
Without that information I do not know that a particular commit came from a particular person. Anyone can impersonate anyone else.
Re: Commit signing in 2023 is kinda wack
#23Earlier quoted context omitted.
Don't you get all those guarantees by just pulling from github? I guess it's nice that you get an attestation that you can verify offline, but it feels like a marginal benefit.
> Don't you get all those guarantees by just pulling from github? Without that information I do not know that a particular commit came from a particular person. Anyone can impersonate anyone else.
Github doesn't put the info of who pushed the merge button into the merge commit message that it signs. I wonder what it actually attests by putting authors and coauthors into the merge commit.
edit:
The Co-authored-by fields can be trivially forged, and then Github signs it. The only question is who it acknowledges as the author. It seems to be the PR opener, from what I could gather.
Re: Commit signing in 2023 is kinda wack
#24Earlier quoted context omitted.
> Don't you get all those guarantees by just pulling from github? Without that information I do not know that a particular commit came from a particular person. Anyone can impersonate anyone else.
So Github attests that the merge was done on Github's side, but what does "commit came from a particular person" mean? Who opened the PR? Who is the author of the commits in the PR (can be impersonated)? Who are the "committers" of said commits? Who pushed the merge button? Github doesn't put the info of who pushed the merge button into the merge commit message that it signs. I wonder what it actually attests by putt…
Re: Commit signing in 2023 is kinda wack
#25Earlier quoted context omitted.
So Github attests that the merge was done on Github's side, but what does "commit came from a particular person" mean? Who opened the PR? Who is the author of the commits in the PR (can be impersonated)? Who are the "committers" of said commits? Who pushed the merge button? Github doesn't put the info of who pushed the merge button into the merge commit message that it signs. I wonder what it actually attests by putt…
It doesn’t have to because you can discover that information from the UI.
Re: Commit signing in 2023 is kinda wack
#26Earlier quoted context omitted.
Fire issue is solved with multiple backups or titanium engraving. Theft is solved with secret passphrase that is either memorized or stored in a separate location. The $5 wrench attack (aka kidnapping and torture) is unsolved but it is extremely rare in comparison to the much more common key leaks/theft scenario. And I don't believe any defense is really possible against that one, cryptographically or otherwise. > Id…
It’s kind of a solved problem too, Julian Assange even worked on a file system called Rubberhose - https://en.m.wikipedia.org/wiki/Deniable_encryption
Re: Commit signing in 2023 is kinda wack
#27Earlier quoted context omitted.
It doesn’t have to because you can discover that information from the UI.
Signing with the github key doesn't add anything if you can verify based on UI/API anyway.
Re: Commit signing in 2023 is kinda wack
#28Earlier quoted context omitted.
Signing with the github key doesn't add anything if you can verify based on UI/API anyway.
I'm not really sure I follow. Can you explain the attack vector with squash signed commits today?
If you are looking at and trusting github UI/API anyway as part of your verification, then you might as well just look at the green "verified" badge without actually verifying the signature locally. At which point actually signing by the github key is just useless ceremony.
Re: Commit signing in 2023 is kinda wack
#29Earlier quoted context omitted.
I'm not really sure I follow. Can you explain the attack vector with squash signed commits today?
I'm not trying to find an attack vector, I'm trying to find a threat model where relying on non-signed commits on master is insecure, but relying on commits signed by the github key is secure. If you are looking at and trusting github UI/API anyway as part of your verification, then you might as well just look at the green "verified" badge without actually verifying the signature locally. At which point actually sign…