7 ms·

From the Homebrew post about the incident: “The security researcher also recommended we consider using GPG signing for Homebrew/homebrew-core. The Homebrew proj

From the Homebrew post about the incident: “The security researcher also recommended we consider using GPG signing for Homebrew/homebrew-core. The Homebrew project leadership committee took a vote on this and it was rejected non-unanimously due to workflow concerns.” How is PGP signing not a no-brainer. What kind of workflow concerns would prevent them from signing commits?!

ssutch3 8y ago
Especially when GPG signing is so easy: https://help.github.com/articles/signing-commits-using-gpg/ https://help.github.com/articles/signing-commits-using-gpg/
mnarayan01 8y ago
Linus (from 2009) on problems with signing every commit: http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-tp2582986p2583316.html http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...
- shittyadmin 8y ago
  He seems to be discouraging signing every commit's individual data but encouraging signing the actual commit ID (SHA1) which should be perfectly feasible for something like homebrew.
  - mnarayan01 8y ago
    > Signing each commit is totally stupid. It just means that you automate it, and you make the signature worth less.
    - shittyadmin 8y ago
      You're still getting a signature directly from the developer's machine, not from the repository server and as such you're still vastly shrinking the attack surface.
    - mratzloff 8y ago
      It's really not that hard to type a password into the terminal every time you commit.
      - majewsky 8y ago
        You have no idea how creative people get when faced with minor nuisances. I've seen devs/admins go to great lengths to avoid doing more than one 2FA per day.
        bigiain 8y ago
        Like this? https://www.youtube.com/watch?v=AsNwon4fjqY https://www.youtube.com/watch?v=AsNwon4fjqY A publicly available webcam pointed at an RSA SecurID hardware token... (The optimist ion me hopes this was performance art. But I've worked with people who'd do that if it made their day ever so slightly easier...)
- ejholmes 8y ago
  General rule of thumb for secure package distribution: 1. Is the identifier mutable? Make sure it points to a content addressable identifier (SHA2), and sign that link. 2. Is it a content addressable identifier? Nothing to do. When it comes to signing in git, signing tags is usually where you see the most value (mutable identifier that points to a git tree, which is content addressable). You’re just trying to improve the trust in saying “Hey, v1.2 is this SHA digest”.
mikemcquaid 8y ago
I'll happily state publicly that I voted for this proposal but in this case the issue is that Homebrew/homebrew-core does not follow a GitHub Flow process but pulls binary packages in with a custom tool (`brew pull`) and generally relies on a rebase workflow which GitHub does not sign (understandably as it's modifying the original commit and would have GitHub signing non-merge-commits). I'm still optimistic we can figure out a way to do this in future.
- w8vY7ER 8y ago
  appreciate the detailed info!
geofft 8y ago
If you make PGP signing easy enough, at some point you end up with a Jenkins with a trusted PGP signing key, and you haven't actually solved anything. The problem isn't making it easy to sign things, the problem is making it sufficiently hard for unauthorized parties to sign things without affecting any workflows you'd like to preserve - that is, the real problem is a workflow problem. The real problem is figuring out how to secure automation so it has the privileges to do what it needs but isn't leaking access. The Jenkins instance was designed to do authenticated pushes - it needs automated write access to the Homebrew repos. Also, signing commits doesn't help you if the risk is unauthorized pushes to master. You can pick up someone's test commit and push that to master, or push a rollback of OpenSSL to a vulnerable version, or something, and still ruin many people's days.
- vbernat 8y ago
  The GPG signature covers the hash which depends of the previous commits. Therefore, a signature covers the whole history.
  - geofft 8y ago
    That is true for git's definition of "history," but it is not helpful here. If I force-push a commit that was signed a year ago, then the signature does not cover the fact that master was just rolled back by a year (the signature does not cover the reflog, in git parlance). You have a valid signature of the previous version of history, and clients cannot tell that history was rolled back without authorization. If I push a pull-request to master that wasn't approved to be on master (e.g., a maintainer did a build of "disable signature validation to narrow down why tests are failing", and signed that commit and pushed it to a PR with the intention of rejecting the PR), then I also have a valid and completely signed "history", and it probably isn't even a force-push to get it onto master. Git commit signatures authenticate exactly one thing: that at some point, the holder of this PGP key committed this commit. They say nothing about the suitability or future suitability of that commit to be used for any purpose. They don't solve the problem Homebrew had here, and they cause other problems (like breaking rebases). Git tag signatures are significantly more useful, since they include the name of the tag. So you're not vulnerable to the second attack, and you're mostly not vulnerable to the first since a client wouldn't intentionally request tag 1.0 after getting tag 1.5. But you still have the problem of the client knowing which tag is current, and frequent tagging isn't a great replacement for a workflow where you want people to follow master.
peterwwillis 8y ago
Code signing is important, but artifact signing is even more important, because that's what you end up trusting at the end of the chain. So not only do you have to sign your code and secure all your code signing keys, your build agent has to have a build signing key to sign builds. If any of this is compromised, there goes your build integrity.

ssutch3 8y ago

Especially when GPG signing is so easy: https://help.github.com/articles/signing-commits-using-gpg/ https://help.github.com/articles/signing-commits-using-gpg/

mnarayan01 8y ago

Linus (from 2009) on problems with signing every commit: http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-tp2582986p2583316.html http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...

shittyadmin 8y ago
He seems to be discouraging signing every commit's individual data but encouraging signing the actual commit ID (SHA1) which should be perfectly feasible for something like homebrew.
- mnarayan01 8y ago
  > Signing each commit is totally stupid. It just means that you automate it, and you make the signature worth less.
  - shittyadmin 8y ago
    You're still getting a signature directly from the developer's machine, not from the repository server and as such you're still vastly shrinking the attack surface.
  - mratzloff 8y ago
    It's really not that hard to type a password into the terminal every time you commit.
    - majewsky 8y ago
      You have no idea how creative people get when faced with minor nuisances. I've seen devs/admins go to great lengths to avoid doing more than one 2FA per day.
      - bigiain 8y ago
        Like this? https://www.youtube.com/watch?v=AsNwon4fjqY https://www.youtube.com/watch?v=AsNwon4fjqY A publicly available webcam pointed at an RSA SecurID hardware token... (The optimist ion me hopes this was performance art. But I've worked with people who'd do that if it made their day ever so slightly easier...)
ejholmes 8y ago
General rule of thumb for secure package distribution: 1. Is the identifier mutable? Make sure it points to a content addressable identifier (SHA2), and sign that link. 2. Is it a content addressable identifier? Nothing to do. When it comes to signing in git, signing tags is usually where you see the most value (mutable identifier that points to a git tree, which is content addressable). You’re just trying to improve the trust in saying “Hey, v1.2 is this SHA digest”.

mikemcquaid 8y ago

I'll happily state publicly that I voted for this proposal but in this case the issue is that Homebrew/homebrew-core does not follow a GitHub Flow process but pulls binary packages in with a custom tool (`brew pull`) and generally relies on a rebase workflow which GitHub does not sign (understandably as it's modifying the original commit and would have GitHub signing non-merge-commits). I'm still optimistic we can figure out a way to do this in future.

w8vY7ER 8y ago
appreciate the detailed info!

geofft 8y ago

If you make PGP signing easy enough, at some point you end up with a Jenkins with a trusted PGP signing key, and you haven't actually solved anything. The problem isn't making it easy to sign things, the problem is making it sufficiently hard for unauthorized parties to sign things without affecting any workflows you'd like to preserve - that is, the real problem is a workflow problem. The real problem is figuring out how to secure automation so it has the privileges to do what it needs but isn't leaking access. The Jenkins instance was designed to do authenticated pushes - it needs automated write access to the Homebrew repos. Also, signing commits doesn't help you if the risk is unauthorized pushes to master. You can pick up someone's test commit and push that to master, or push a rollback of OpenSSL to a vulnerable version, or something, and still ruin many people's days.

vbernat 8y ago
The GPG signature covers the hash which depends of the previous commits. Therefore, a signature covers the whole history.
- geofft 8y ago
  That is true for git's definition of "history," but it is not helpful here. If I force-push a commit that was signed a year ago, then the signature does not cover the fact that master was just rolled back by a year (the signature does not cover the reflog, in git parlance). You have a valid signature of the previous version of history, and clients cannot tell that history was rolled back without authorization. If I push a pull-request to master that wasn't approved to be on master (e.g., a maintainer did a build of "disable signature validation to narrow down why tests are failing", and signed that commit and pushed it to a PR with the intention of rejecting the PR), then I also have a valid and completely signed "history", and it probably isn't even a force-push to get it onto master. Git commit signatures authenticate exactly one thing: that at some point, the holder of this PGP key committed this commit. They say nothing about the suitability or future suitability of that commit to be used for any purpose. They don't solve the problem Homebrew had here, and they cause other problems (like breaking rebases). Git tag signatures are significantly more useful, since they include the name of the tag. So you're not vulnerable to the second attack, and you're mostly not vulnerable to the first since a client wouldn't intentionally request tag 1.0 after getting tag 1.5. But you still have the problem of the client knowing which tag is current, and frequent tagging isn't a great replacement for a workflow where you want people to follow master.

peterwwillis 8y ago

Code signing is important, but artifact signing is even more important, because that's what you end up trusting at the end of the chain. So not only do you have to sign your code and secure all your code signing keys, your build agent has to have a build signing key to sign builds. If any of this is compromised, there goes your build integrity.