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/2423238...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
