4 ms·

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 prob

by 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.
  - bburky 8y ago
    Technically `git push --signed` also exists which could fix the issue of rolling back commits. It would verify that the person doing the push also holds the GPG key at least. But as far as I can tell you have to manually do something with it in the post-receive hook and GitHub doesn't support it at all.
josephh 8y ago
Are there any OSS maintainers who use air-gapped computers to sign packages (at least for major versions)? I would expect this level of precautions be taken for projects that may have large-scale repercussions in the event of a security breach.
- TimWolla 8y ago
  While not OSS the Debian packages of Tarsnap are built and signed on an air-gapped machine: http://mail.tarsnap.com/tarsnap-alphatest/msg00033.html http://mail.tarsnap.com/tarsnap-alphatest/msg00033.html
  - geofft 8y ago
    How much review does 'cperciva do of the source code and build-dependencies that are copied to the air-gapped machine, which presumably originate from internet-connected machines? Also, how secure is the kernel on the air-gapped machine against malicious filesystems on the USB stick? (If it's running Linux, the answer is almost certainly "not;" I could imagine FreeBSD is better but I don't know how much people have explored that.) To be clear I'm not opposed to air-gapping if the maintainer is excited about it, I just suspect there are many much weaker links on the way to/from the air-gapped system, and fixing those is a much harder project that almost nobody is excited about.
    - jacobush 8y ago
      Maybe it's not using any filesystems on the USB stick. Maybe it just images a filesystem right down to the USB stick without ever mounting anything.
      - geofft 8y ago
        It has to read the source from somewhere to compile it, right?
        jacobush 8y ago

by geofft 8y ago

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.
- bburky 8y ago
  Technically `git push --signed` also exists which could fix the issue of rolling back commits. It would verify that the person doing the push also holds the GPG key at least. But as far as I can tell you have to manually do something with it in the post-receive hook and GitHub doesn't support it at all.

josephh 8y ago

Are there any OSS maintainers who use air-gapped computers to sign packages (at least for major versions)? I would expect this level of precautions be taken for projects that may have large-scale repercussions in the event of a security breach.

TimWolla 8y ago
While not OSS the Debian packages of Tarsnap are built and signed on an air-gapped machine: http://mail.tarsnap.com/tarsnap-alphatest/msg00033.html http://mail.tarsnap.com/tarsnap-alphatest/msg00033.html
- geofft 8y ago
  How much review does 'cperciva do of the source code and build-dependencies that are copied to the air-gapped machine, which presumably originate from internet-connected machines? Also, how secure is the kernel on the air-gapped machine against malicious filesystems on the USB stick? (If it's running Linux, the answer is almost certainly "not;" I could imagine FreeBSD is better but I don't know how much people have explored that.) To be clear I'm not opposed to air-gapping if the maintainer is excited about it, I just suspect there are many much weaker links on the way to/from the air-gapped system, and fixing those is a much harder project that almost nobody is excited about.
  - jacobush 8y ago
    Maybe it's not using any filesystems on the USB stick. Maybe it just images a filesystem right down to the USB stick without ever mounting anything.
    - geofft 8y ago
      It has to read the source from somewhere to compile it, right?
      - jacobush 8y ago