-
Notifications
You must be signed in to change notification settings - Fork 160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce released package signatures #282
Comments
Not sure I can provide much help, but here are some comments. GPG signature is relatively easy and straightforward to accomplish: create a key, publish it to public servers, and give the keys to a few maintainers. The release script would then generate the sums, and will sign the artifacts (including the sums) with the gpg key. The gpg key itself can be stored in the same repository, with the passphrase to decrypt it being a secret in the repository. Code signing is more complex though: I'm not aware of a $0 code signing cert, and we certainly do not want to use a self-signed cert if we really need a code signing cert. Validity and rotation would also depend on the issuer's policies. Before continuing with this, it would be good to see what other CNCF projects are doing in this area.
The gpg signatures are published alongside the artifacts. |
Yes, as far as I know self-signed certificates are pointless in Windows. The code signing certificate must be obtained from a Certificate Authority that is a built-in trusted root in Windows system. It costs money to obtain a certificate like this, the process is often a hassle and certificates have expiration dates so you have to do this periodically (I think it was always annual when I did it in the past). Technically GPG signatures provide the safety necessary. However all modern Windows systems show big red flags when trying to run an executable or install an MSI that is not code-signed (and being GPG-signed does not help in anyway). I don't know how much of a problem this is in reality. Since we haven't heard about the problems so far from our users, I agree with you there is no rush with Windows-specific code signing. For my specific use cases (OpAMP's downloaded package authenticity verification) GPG signing should work equally well both for Linux and for Windows. |
Update: it seems like there is also a way to sign Docker images such that Kubernetes can verify them: https://medium.com/sse-blog/container-image-signatures-in-kubernetes-19264ac5d8ce |
There have been some requests by users in the past, but given that we have no maintainers with easy access to Windows or code signing facilities for Windows, this never moved beyond the "it would be nice to have this". |
We produce Linux, Windows and Mac OS X executables/packages. These packages are not signed which makes it difficult to verify the authenticity of the packages. Code signing is also an essential part of secure operation of OpAMP.
Ideally we need to sign the code that we release (both in this repo and in contrib).
On Unix systems we should possibly use GPG signing with detached signatures. On Windows (perhaps in addition to GPG signatures) we may need a code signing certificate to sign the EXE and MSI.
The signing certificate's private key needs to be stored privately and used for signing process in the CI. The private key needs to be guarded. The public key needs to be publicly advertised in this repository and/or at https://opentelemetry.io/
For GPG signing the resulting detached signatures must be published for each release alongside the assets that we include in the release (one signature per executable asset).
Questions:
The text was updated successfully, but these errors were encountered: