1

I've been considering how continuous integration/delivery environments handle code signing.

If I maintain some open source project which uses a CD environment to build binaries to ship to users, I may wish to sign the binaries which are produced, so that users can verify they originate from me.

My question would be, is it reasonable for the signature to be calculated automatically as part of the CD pipeline? I would imagine it would be ideal to manually sign the binary each time, but are there major concerns with the former scenario? And does it go completely against common practice, or are projects using this pattern?

In this hypothetical scenario, a separate signing key would exist just for the build server, I'm not suggesting using my own key for the automated signatures.

I appreciate this is somewhat subjective, but I would greatly appreciate any perspectives.

Improve this question

1 Answer 1

Reset to default
2

Signing binaries automatically as part of a CI/CD pipeline or a similar automated release process is normal. In fact, in many cases, it can even be preferable, since the keys are usually stored securely using the CI system's secret store, minimizing the risk of leakage, and it permits projects which have multiple maintainers to avoid having any single person be a single point of failure.

The Git LFS project does this, as do many other projects that GitHub maintains or sponsors. I believe, but am not certain, that Git for Windows also does this. In any event, it's my impression that this is common.

To look at larger examples, most Linux distros essentially do this as well. For example, Debian maintains automated infrastructure to handle uploads and builds of packages and have the archive manifests automatically signed (Debian does not usually sign packages or binaries themselves). It would certainly not be practical do this by hand on such a large scale, so automating it is the only option.

Improve this answer
1
  • I'm faced with the same question and was just thinking that having builds and signing all done on the same platform allows an attacker to publish malicious binaries by hacking this single platform only, while with manual signing, such cannot happen (without non-matching signatures). But I also came to the conclusion that manual signing is not practicable. What do you think about using dedicated keys? I don't find it practical either have user needing to import two public keys allow verifying manually signed (or signed commits) and those singed by the CI pipeline.
    – MichaIng
    Mar 19 at 16:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .