4 ms·

It's really neat that ssh keys can be used for signing commits, but I'm not a big fan of this. When auditing a source repository you want to see how commits ar

by er4hn 5y ago

It's really neat that ssh keys can be used for signing commits, but I'm not a big fan of this. When auditing a source repository you want to see how commits are signed over time. In other words you have a key X which is valid at time Y. As Y changes, key X will change as well. To audit a repo, you need to know the history of what key X was valid at time Y. With GPG you can set up a hierarchy of commit signing keys which have defined lifetimes and are all subordinate to a master key which you do not use for signing (and hopefully keep somewhere secure). One irritant is that the major git-as-a-service products, i.e. github + gitlab, do not respect the use of GPG keys as something varying over time or subordinate to a master key. Instead they let you set a current active key and mark on their own if it was verified at the time. If you want to validate the repository's security yourself, you don't have the proper information to do so. The use of ssh keys as signing keys furthers this incorrect usage of a single key as something that does not vary over time. You can use ssh certificates as a way to have a hierarchy, but that still doesn't acknowledge that there is historical data of note. Now, a logical question is: If each git commit is the summation of everything before, why does historical data matter? Why can't I just trust the git{hub,lab} when it says it was "Verified" at the time? A few reasons: - Github allows someone logged in to make edits via their web editor which they helpfully sign with a universal github key that is always verified. So if your AuthN is bad, that is a problem. - You are trusting that your git-as-a-service provider will never have their repositories tampered with and your org will just download the newest version of the repo. - It relies on git-as-a-service providers to track this. If you aren't using a managed service provider you need to roll your own auditing tools.

hannob 5y ago
> When auditing a source repository you want to see how commits are signed over time. I understand your reasoning and the idea behind GPG and everything, but here's my challenge to all of this: Has this ever happened? Like, the scenario we're talking about is that at some point some bad code, maybe a backdoor, got introduced into a code repo, and it later is discovered and someone launches an investigation. And they find out "this was committed by XYZ but XYZ claims he didn't do it". I don't remember any such incident ever. Given that I feel a slightly weaker form with SSH keys may still be justified. (And it is still easily conceivable to have some out-of-band-metadata, e.g. a project that feels this is important could just have a list of developer SSH key fingerprints within the repo and thus have the backlog of who's keys were relevant at what point in time.)
- er4hn 5y ago
  > Has this ever happened? Unfortunately this has: https://www.wired.com/2015/12/researchers-solve-the-juniper-mystery-and-they-say-its-partially-the-nsas-fault/ https://www.wired.com/2015/12/researchers-solve-the-juniper-... While the full results were not released, it was pretty clear that a rogue commit happened to the VCS. This is the highest profile example that has occurred in my corner of the tech world. The broader category of this attack is "insider threat" and it is a real thing. Even googling for "malicious code commit" turns up this other example for me as one of the first results: https://www.theregister.com/2021/03/29/php_repository_infected/ https://www.theregister.com/2021/03/29/php_repository_infect...
  - deleted 5y ago
    [deleted]
  - hannob 5y ago
    Given Juniper released basically nothing about their investigation, I'm not convinced this is a valid example. Notably, I'm not just asking if there ever was a bad commit that was investigated - but that the commit came from someone who later claimed she/he didn't do it.
eropple 5y ago
This is a totally valid criticism IMO, and I think platforms should allow for disallowing signatures based on origin, but there's something that, for the majority of users, really holds true: > With GPG you can set up a hierarchy of commit signing keys which have defined lifetimes and are all subordinate to a master key which you do not use for signing (and hopefully keep somewhere secure). Within epsilon of nobody is going to do this, but they all have an SSH key. Heck, I don't do this, and I even actually know how to make GPG do it. It's a huge hassle for what, at this point, is really only useful to me for...signing Git commits? I don't need to sign anything else with it, and GPG mail is nonexistent. (Also, fwiw, if you aren't using a managed service provider, I hope you have a directory service where you can have those keys. If you aren't using a managed service provider and you don't have a directory service, I'm gonna go out on a limb and say that I'm guessing security isn't that important to you.)
agwa 5y ago
It's possible to set "valid-before" and "valid-after" timestamps on SSH keys in the allowed signers file: https://man.openbsd.org/ssh-keygen#ALLOWED_SIGNERS https://man.openbsd.org/ssh-keygen#ALLOWED_SIGNERS When validating the SSH signature, Git can set the verify-time option to the commit timestamp and the signature will be rejected if the key is not valid at that time. Git doesn't yet do this, but will in a future version. This is considerably simpler than the rigamarole of GPG subkeys.
Androider 5y ago
All of this signing is only useful if someone is actually checking or enforcing those signatures, otherwise it's just LARPing. Being able to sign commits with your SSH keys makes signing actually useful, because it enables a new workflow that developers will use: - You give every dev on your team a Yubikey - They generate an ed25519-sk key that only resides on the Yubikey, no software required as it works out of the box with both openssh and GitHub - They upload the public ID of the key to GitHub, same as before - You enforce commit signature verification for your GitHub org. You're done, no need to install any software, everything Just Works. You now have: - No private keys on developers machines, rendering all types of supply chain attacks like NPM stealing your .ssh files ineffective - Enforced 2FA for everyone without any hassle - Every commit signed by developers, enforced and with no developer overhead. Checks a lot of boxes for those SOCs and ISOs.
- entropie 5y ago
  > They generate an ed25519-sk key that only resides on the Yubikey, no software required as it works out of the box with both openssh and GitHub How does this work? Can you like me a ressource?
  - Androider 5y ago
    You run `ssh-keygen -t ed25519-sk -O resident`, and that's it, no additional software required as of OpenSSH 8.2. If you have an older model Yubikey you can try ecdsa-sk instead. For more details, see: https://github.blog/2021-05-10-security-keys-supported-ssh-git-operations/ https://github.blog/2021-05-10-security-keys-supported-ssh-g... https://www.yubico.com/blog/github-now-supports-ssh-security-keys/ https://www.yubico.com/blog/github-now-supports-ssh-security...
- dec0dedab0de 5y ago
  - No private keys on developers machines, rendering all types of supply chain attacks like NPM stealing your .ssh files ineffective Would it be able to get the key from the usb device? Or does the hashing happen on the device itself with the private key never exposed? If that's how it works, that would be awesome, but would a malicious program be able to sign something as you, instead of stealing the keys? I'm going to look into this more and maybe recommend it at work.

by er4hn 5y ago

hannob 5y ago

> When auditing a source repository you want to see how commits are signed over time. I understand your reasoning and the idea behind GPG and everything, but here's my challenge to all of this: Has this ever happened? Like, the scenario we're talking about is that at some point some bad code, maybe a backdoor, got introduced into a code repo, and it later is discovered and someone launches an investigation. And they find out "this was committed by XYZ but XYZ claims he didn't do it". I don't remember any such incident ever. Given that I feel a slightly weaker form with SSH keys may still be justified. (And it is still easily conceivable to have some out-of-band-metadata, e.g. a project that feels this is important could just have a list of developer SSH key fingerprints within the repo and thus have the backlog of who's keys were relevant at what point in time.)

er4hn 5y ago
> Has this ever happened? Unfortunately this has: https://www.wired.com/2015/12/researchers-solve-the-juniper-mystery-and-they-say-its-partially-the-nsas-fault/ https://www.wired.com/2015/12/researchers-solve-the-juniper-... While the full results were not released, it was pretty clear that a rogue commit happened to the VCS. This is the highest profile example that has occurred in my corner of the tech world. The broader category of this attack is "insider threat" and it is a real thing. Even googling for "malicious code commit" turns up this other example for me as one of the first results: https://www.theregister.com/2021/03/29/php_repository_infected/ https://www.theregister.com/2021/03/29/php_repository_infect...
- deleted 5y ago
  [deleted]
- hannob 5y ago
  Given Juniper released basically nothing about their investigation, I'm not convinced this is a valid example. Notably, I'm not just asking if there ever was a bad commit that was investigated - but that the commit came from someone who later claimed she/he didn't do it.

eropple 5y ago

This is a totally valid criticism IMO, and I think platforms should allow for disallowing signatures based on origin, but there's something that, for the majority of users, really holds true: > With GPG you can set up a hierarchy of commit signing keys which have defined lifetimes and are all subordinate to a master key which you do not use for signing (and hopefully keep somewhere secure). Within epsilon of nobody is going to do this, but they all have an SSH key. Heck, I don't do this, and I even actually know how to make GPG do it. It's a huge hassle for what, at this point, is really only useful to me for...signing Git commits? I don't need to sign anything else with it, and GPG mail is nonexistent. (Also, fwiw, if you aren't using a managed service provider, I hope you have a directory service where you can have those keys. If you aren't using a managed service provider and you don't have a directory service, I'm gonna go out on a limb and say that I'm guessing security isn't that important to you.)

agwa 5y ago

It's possible to set "valid-before" and "valid-after" timestamps on SSH keys in the allowed signers file: https://man.openbsd.org/ssh-keygen#ALLOWED_SIGNERS https://man.openbsd.org/ssh-keygen#ALLOWED_SIGNERS When validating the SSH signature, Git can set the verify-time option to the commit timestamp and the signature will be rejected if the key is not valid at that time. Git doesn't yet do this, but will in a future version. This is considerably simpler than the rigamarole of GPG subkeys.

Androider 5y ago

All of this signing is only useful if someone is actually checking or enforcing those signatures, otherwise it's just LARPing. Being able to sign commits with your SSH keys makes signing actually useful, because it enables a new workflow that developers will use: - You give every dev on your team a Yubikey - They generate an ed25519-sk key that only resides on the Yubikey, no software required as it works out of the box with both openssh and GitHub - They upload the public ID of the key to GitHub, same as before - You enforce commit signature verification for your GitHub org. You're done, no need to install any software, everything Just Works. You now have: - No private keys on developers machines, rendering all types of supply chain attacks like NPM stealing your .ssh files ineffective - Enforced 2FA for everyone without any hassle - Every commit signed by developers, enforced and with no developer overhead. Checks a lot of boxes for those SOCs and ISOs.

entropie 5y ago
> They generate an ed25519-sk key that only resides on the Yubikey, no software required as it works out of the box with both openssh and GitHub How does this work? Can you like me a ressource?
- Androider 5y ago
  You run `ssh-keygen -t ed25519-sk -O resident`, and that's it, no additional software required as of OpenSSH 8.2. If you have an older model Yubikey you can try ecdsa-sk instead. For more details, see: https://github.blog/2021-05-10-security-keys-supported-ssh-git-operations/ https://github.blog/2021-05-10-security-keys-supported-ssh-g... https://www.yubico.com/blog/github-now-supports-ssh-security-keys/ https://www.yubico.com/blog/github-now-supports-ssh-security...
dec0dedab0de 5y ago
- No private keys on developers machines, rendering all types of supply chain attacks like NPM stealing your .ssh files ineffective Would it be able to get the key from the usb device? Or does the hashing happen on the device itself with the private key never exposed? If that's how it works, that would be awesome, but would a malicious program be able to sign something as you, instead of stealing the keys? I'm going to look into this more and maybe recommend it at work.