[Rpm-maint] [rpm-software-management/rpm] RFE: automatically sign packages on build (Issue #2678)

[Stewart Smith]

I'll add some context on how we think about / do package signing in Amazon Linux (and for brevity, I'm going to just focus on AL2023 and beyond, and simplify things along the way) which may help inform decisions here.

Builders do not have access to the private signing keys. Nothing does. It's all in KMS. The keys were created in KMS, and nobody has **ever** seen the private key.

A (one to N instances of) a **separate** system to Koji works out what it should sign and with what key. This helps with things such as having an external audit log, and a simpler system to do an in-depth security review on. It also makes it **impossible** for any Koji deployment to accidentally go and [do something incredibly undesirable to the keys](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html).

We haven't solved the scratch/local build signing problem, nor currently looked to. If I were to posit or review such a design for us doing it, I'd ensure the following constraints were true:
1. Anything not a final build in Koji is signed with a *different* key than what that final build would be signed for if it was queued for release. i.e. there is no way to have a random scratch/mock build to make it into any production system with a valid signature from the production keys.
2. Keys need to be **clearly** marked as for test and throwaway builds, and in such a way that it is possible for systems to alarm on any of these builds or keys making their way onto any production system.

In a previous work life, I worked on firmware that had the ability to do secure boot of the firmware stack. So that test keys were obvious, there was a standard set of test keys where the **private keys were in the public git repository** so that *everyone* knew what the test keys were.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2678#issuecomment-2423238871
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/issues/2678/2423238871 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20241018/d59082b3/attachment.html>