Envoy: Signed releases

[htuch]

Running https://github.com/ossf/scorecard against https://github.com/envoyproxy/envoy gives generally a high score, but we are missing signed releases/tags. The idea is to attach a GPG ASCII signature to the release/tag artifacts.

Arguably the benefit is marginal if we trust GitHub security (how many Envoy consumers will check this signature?), but this seems a reasonable defense-in-depth best practice to follow.

[grial1]

Hi @htuch, I have some questions regarding the key used to signed the releases. What type would you like it to be? For how long should it stay valid? What its UID should be?

Following the Debian's guide on how to create signed github releases, I manage to put together a demo/POC on my forked repo.

BTW, could I help you with this issue ?😁

[htuch]

Thanks @grial1. TBH I'm not sure how we want to deal with key management. @alyssawilk @mattklein123 since you folks tend to cut the releases, is there a preferred methodology around key management and signing?

[alyssawilk]

No preference from me. If @grial1 is up for helping out, maybe he can doc up his PoC steps in the GOVERNANCE release instructions once we get the questions settled.

[grial1]

Sure 🙂 . Once decided how to handle the key management, I can submit a PR to GOVERNANCE.md with the steps to follow to create a signed release.

[mattklein123]

Once decided how to handle the key management

Can you summarize what kind of key management is required? Is this a flow that someone runs on their dev machine? Or something else? What type of key(s) need to be stored? I think a bit more details would help. Thank you.

[grial1]

For instance, when creating the key, as explained by this guide, an UID is needed to be provided. Which should be that UID? Then, the key needs to be uploaded to a public keyserver, so, which one should I use? For the example I uploaded the key to pool.sks-keyservers.net.

[htuch]

I think we might need some maintainer oriented flow around a shared signing key, maybe backed with Lastpass. But there are probably alternatives, e.g. a signing VM.

[mattklein123]

I think we might need some maintainer oriented flow around a shared signing key, maybe backed with Lastpass. But there are probably alternatives, e.g. a signing VM.

A signing process that is built into a VM or cloud hosted workflow (lambda, whatever) would be optimal, but a lot more work unless there is some service out there we can use for this (cc @caniszczyk who might know of something). In the interim, we could host the key in our shared LastPass per @htuch. I don't have any strong preference on key server for the public key. This is not something that I know a lot about so I'm happy with whatever is standard here.

[dlorenc]

Many cloud providers support asymmetric signing. Here's GCP's version: https://cloud.google.com/kms/docs/asymmetric-encryption

If you're already using a cloud provider's IAM for maintainers somewhere, this is probably a straightforward method.