4 ms·

Commit signing in 2023 is kinda wack

25 points by codeAligned 1y ago

3np 1y ago
In theory, there is a solution to the PGP revocation issue that I think vibes with OPs desire: Generate a long-lived root keypair (SC/C), the public key of which you add to the forge. You never sign directly with this. Instead you routinely generate new signing pairs. If compromised you hopefully only need to revoke the subkey so the blast radius is a lot smaller. You could even do a three-tier one where you can keep the root key dead cold and literally lock it into a vault. Last time I looked, this was not supported in GitHub, though; it only recognized signatures by explicitly trusted keys, not their signed subkeys.
olalonde 1y ago
> Key compromise happens, key loss happens, and identities change over time. This problem is largely solved in cryptocurrency-land. You have a hardware device that does the signing, which is recoverable from a 24 word seed that is stored offline (plus a passphrase which can be memorized or stored online so that it's not catastrophic if someone gets to your seed). I just found out that Ledger actually supports SSH/PGP: https://support.ledger.com/article/115005200649-zd https://support.ledger.com/article/115005200649-zd
- Jean-Papoulos 1y ago
  This is absolutely not solving the problem, it's at best kicking it down the road and doesn't solve the key getting compromised or identity changing.
  - olalonde 1y ago
    Can you be more specific about how it is absolutely not solving the problem? To compromise a key you need to find a hidden piece of paper or engraved plate that your target has physically hidden somewhere. Plus guess a secret password (before your target has noticed you got to their seed and rang the alarm). Almost impossible to pull off. I'm not sure what you mean about identity changing. If you mean a sex change or getting a new haircut, this is irrelevant to signing commits...
    - captn3m0 1y ago
      Any knowledge held by a person is retrievable with a $5 wrench. Things can get stolen, houses can burn down, bank lockers can be robbed. Identity Changes, such as name changes, are relevant in the Web o Trust/GPG world where you typically require a valid ID proof (such as a passport) and physical presence before you sign someone's keys at a Key Signing Party.
      - olalonde 1y ago
        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. > Identity Changes, such as name changes, are relevant in the Web o Trust/GPG world where you typically require a valid ID proof (such as a passport) and physical presence before you sign someone's keys at a Key Signing Party. It doesn't solve that problem but I don't think "real life" identity is really relevant for the purpose of contributing code. In fact, plenty of open source contributors are pseudonymous.
        alfiedotwtf 1y ago
        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 https://en.m.wikipedia.org/wiki/Deniable_encryption
        olalonde 1y ago
        It's also a feature of crypto wallets like Ledger which allow you to have a decoy PIN that unlocks a throw away wallet.
- DaSHacka 1y ago
  How is this any different from just using a Yubikey? I fail to see how cryptocurrencies are in any way unique in this regard.
  - olalonde 1y ago
    I don't know, I've never used one. Can keys stored on a Yubikey be restored from a 24 word seed + passphrase? Do Yubikeys self-destroy after 3 incorrect PINs?
    - DaSHacka 1y ago
      No, but that's the whole point. One less avenue for exploitation. You would have to physically destroy the device, and find an exploit in the smartcard on the chip itself to obtain the private keys.
      - olalonde 1y ago
        Then it doesn't solve the "key loss happens" problem. You lose/break/damage your device and your keys are gone.
        DaSHacka 1y ago
        You're supposed to register more than one key, and leave the other on standby. A common practice is one Yubikey on your keyring, another left at home (optionally left in your Desktop or a computer that doesn't leave the house)
the_mitsuhiko 1y ago
Not as the creator intended, but Commit signing on GitHub is mostly an automatic thing at this point if you use pull requests and squash merges. The commits on the PR itself are unsigned, but the merge to the branch is attested and marked as signed by GitHub itself. Since you need to have permission at the time of merge, it's a rather trustworthy indication. Here an example from Sentry's master which other than bot triggered reverts are all verified: https://github.com/getsentry/sentry/commits/master/ https://github.com/getsentry/sentry/commits/master/
- leni536 1y ago
  I fail to so what security you gain by trusting Github's key.
  - the_mitsuhiko 1y ago
    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.
    - captn3m0 1y ago
      GitHub uses fairly long-lived sessions. "sudo mode"[0] on GitHub, where it asks for a verification of the 2FA is only for sensitive actions, which PR merges are not. So a cookie-stealing attack can easily merge PRs for quite a while. And 2FA isn't a requirement for a PR merge afaik, Except via org-wide enforcement? So the guarantee is lower - the commit was merged with a valid session token. [0]: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/sudo-mode https://docs.github.com/en/authentication/keeping-your-accou...
      - the_mitsuhiko 1y ago
        If you enforce an organization to have a 2FA sign-in then yes, it's enforced that the session was created with a second factor. In Sentry's case you also need to go through SSO once every 24 hours. There is no way for you to get a valid session token without going through that which can be used to create a signed merge commit.
milesrout 1y ago
Why is this written so poorly?
Joker_vD 1y ago
I simply include a base64-encoded PNG with the facsimile of my signature in the commit message, if I'm being really pushed to "sign my commit", it has about the same power of attestation as the cryptographic means. So far, I only had to do it once.

25 points by codeAligned 1y ago

3np 1y ago

In theory, there is a solution to the PGP revocation issue that I think vibes with OPs desire: Generate a long-lived root keypair (SC/C), the public key of which you add to the forge. You never sign directly with this. Instead you routinely generate new signing pairs. If compromised you hopefully only need to revoke the subkey so the blast radius is a lot smaller. You could even do a three-tier one where you can keep the root key dead cold and literally lock it into a vault. Last time I looked, this was not supported in GitHub, though; it only recognized signatures by explicitly trusted keys, not their signed subkeys.

olalonde 1y ago

> Key compromise happens, key loss happens, and identities change over time. This problem is largely solved in cryptocurrency-land. You have a hardware device that does the signing, which is recoverable from a 24 word seed that is stored offline (plus a passphrase which can be memorized or stored online so that it's not catastrophic if someone gets to your seed). I just found out that Ledger actually supports SSH/PGP: https://support.ledger.com/article/115005200649-zd https://support.ledger.com/article/115005200649-zd

Jean-Papoulos 1y ago
This is absolutely not solving the problem, it's at best kicking it down the road and doesn't solve the key getting compromised or identity changing.
- olalonde 1y ago
  Can you be more specific about how it is absolutely not solving the problem? To compromise a key you need to find a hidden piece of paper or engraved plate that your target has physically hidden somewhere. Plus guess a secret password (before your target has noticed you got to their seed and rang the alarm). Almost impossible to pull off. I'm not sure what you mean about identity changing. If you mean a sex change or getting a new haircut, this is irrelevant to signing commits...
  - captn3m0 1y ago
    Any knowledge held by a person is retrievable with a $5 wrench. Things can get stolen, houses can burn down, bank lockers can be robbed. Identity Changes, such as name changes, are relevant in the Web o Trust/GPG world where you typically require a valid ID proof (such as a passport) and physical presence before you sign someone's keys at a Key Signing Party.
    - olalonde 1y ago
      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. > Identity Changes, such as name changes, are relevant in the Web o Trust/GPG world where you typically require a valid ID proof (such as a passport) and physical presence before you sign someone's keys at a Key Signing Party. It doesn't solve that problem but I don't think "real life" identity is really relevant for the purpose of contributing code. In fact, plenty of open source contributors are pseudonymous.
      - alfiedotwtf 1y ago
        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 https://en.m.wikipedia.org/wiki/Deniable_encryption
        olalonde 1y ago
        It's also a feature of crypto wallets like Ledger which allow you to have a decoy PIN that unlocks a throw away wallet.
DaSHacka 1y ago
How is this any different from just using a Yubikey? I fail to see how cryptocurrencies are in any way unique in this regard.
- olalonde 1y ago
  I don't know, I've never used one. Can keys stored on a Yubikey be restored from a 24 word seed + passphrase? Do Yubikeys self-destroy after 3 incorrect PINs?
  - DaSHacka 1y ago
    No, but that's the whole point. One less avenue for exploitation. You would have to physically destroy the device, and find an exploit in the smartcard on the chip itself to obtain the private keys.
    - olalonde 1y ago
      Then it doesn't solve the "key loss happens" problem. You lose/break/damage your device and your keys are gone.
      - DaSHacka 1y ago
        You're supposed to register more than one key, and leave the other on standby. A common practice is one Yubikey on your keyring, another left at home (optionally left in your Desktop or a computer that doesn't leave the house)

the_mitsuhiko 1y ago

Not as the creator intended, but Commit signing on GitHub is mostly an automatic thing at this point if you use pull requests and squash merges. The commits on the PR itself are unsigned, but the merge to the branch is attested and marked as signed by GitHub itself. Since you need to have permission at the time of merge, it's a rather trustworthy indication. Here an example from Sentry's master which other than bot triggered reverts are all verified: https://github.com/getsentry/sentry/commits/master/ https://github.com/getsentry/sentry/commits/master/

leni536 1y ago
I fail to so what security you gain by trusting Github's key.
- the_mitsuhiko 1y ago
  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.
  - captn3m0 1y ago
    GitHub uses fairly long-lived sessions. "sudo mode"[0] on GitHub, where it asks for a verification of the 2FA is only for sensitive actions, which PR merges are not. So a cookie-stealing attack can easily merge PRs for quite a while. And 2FA isn't a requirement for a PR merge afaik, Except via org-wide enforcement? So the guarantee is lower - the commit was merged with a valid session token. [0]: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/sudo-mode https://docs.github.com/en/authentication/keeping-your-accou...
    - the_mitsuhiko 1y ago
      If you enforce an organization to have a 2FA sign-in then yes, it's enforced that the session was created with a second factor. In Sentry's case you also need to go through SSO once every 24 hours. There is no way for you to get a valid session token without going through that which can be used to create a signed merge commit.

milesrout 1y ago

Why is this written so poorly?

Joker_vD 1y ago

I simply include a base64-encoded PNG with the facsimile of my signature in the commit message, if I'm being really pushed to "sign my commit", it has about the same power of attestation as the cryptographic means. So far, I only had to do it once.