1. 12
  1.  

  2. 2

    Code should be signed with hardware security modules (HSM)’s. Period. An HSM that is capable of code signing can be had for <100US$. Even if the pipeline builds in the cloud, it is nearly trivial to have an HSM plugged into a rack somewhere, and to leverage that to do online code signing.

    1. 3

      That requires hiring a rack, as most organisations would prefer using a VPS / Cloud infra as it is much more scalable, relocatable. I wonder if a TPM in a VPS will be an easier better solution.

      1. 2

        Hiring a place in a rack can be done for <$50USD/mo. If you are signing code for substantial consumers/deployments, that cost will be vanishingly small. If you do not want to use any physical infrastructure, HSM’s are also available in AWS, although the cost is substantial for an individual. For an organization like HashiCorp, the cost of an AWS HSM is also vanishingly small. TPM would also definitely work, but this does require the key to be managed effectively in the clear on the internet, so some of the same exploit/supply-chain vector concerns apply if you’re using cloud vendors outside of the above offerings.

        1. 1

          I wonder if a TPM in a VPS will be an easier better solution.

          Indeed. TPM is like a cheap, always connected HSM. Additionally with a little bit of effort one could seal the key to system configuration to protect against booting from unsupported configurations (e.g. livecd).

          Additionally OpenPGP supports offline primary keys. In case the signing subkey has been compromised it can be revoked and a new one created without affecting the primary key and the key fingerprint.

      2. 2

        Does anyone know why a GPG signing key was accessible to the CI environment in the first place? That strikes me as a little odd.

        1. 2

          I think it’s not uncommon for CI/CD systems to sign releases. It’s hard to make manual signatures with offline keys scale to really frequent releases. That being said, this is exactly why the practice is dangerous.

          1. 2

            When I set up CI/CD for a package to be published to Maven Central a few years ago, the requirement to sign gave me some anxiety from a security perspective but the benefits outweighed the risks.

            I wonder if there are any package management systems that support a secondary signature/attestation of the package. That is, CI/CD automation signs and releases but maintainers can also sign later as a second, human layer of authenticity.

            1. 1

              I think https://sigstore.dev/ is aiming at that kind of use case

              1. 1

                I wonder if there are any package management systems that support a secondary signature/attestation of the package. That is, CI/CD automation signs and releases but maintainers can also sign later as a second, human layer of authenticity.

                This would be really cool given that for OpenPGP it’s trivial to create multi signature file (just concatenate individual signatures). It’s also possible to notarize existing signature (signing a signature) e.g. when people want to certify that the CI signature is valid.

                For builds that are completely reproducible it would be enough for the developer to sign their build and publish the signature with the artifact from the CI. Since the build is reproducible the signature would be over the same data.