[RFD] Options for RPM Signing Approach

[yogi4]

What needs to change:

Currently, our RPM packages are signed manually using traditional GPG keys, stored locally by individual maintainers. This manual signing process is error-prone, lacks transparency, is difficult to audit, and introduces significant overhead in managing private keys securely. Additionally, this approach hampers our continuous integration and deployment pipelines, making automated builds cumbersome and less secure.

What do you propose?

We propose adopting a more modern and automated approach for RPM signing. Several viable options are under consideration:

Option 1: Sigstore Cosign

• Integrating Cosign into our existing GitHub Actions workflows.
• Utilizing keyless signing via GitHub Actions' OIDC token.
• Automating signing and verification steps within the CI/CD pipeline.
• Benefits include improved security, reduced overhead in key management, enhanced auditability, and streamlined RPM signing within automated builds.

Option 2: in‑toto Witness + Archivista Attestation Storage

• Use Witness (a CLI based on the in‑toto specification) to record build and artifact provenance during the RPM pipeline.
• Store attestations in Archivista, a scalable graph-based storage service for in‑toto statements
• Enforce policies via embedded OPA Rego in Witness; policies may reference attestations retrieved via Archivista for compliance verification.
• Benefit: full software supply chain visibility, attestations tied to policy enforcement and retrievable via GraphQL API.

Option 3: Automated GPG Signing within GitHub Actions

• Automating traditional GPG signing within GitHub Actions.
• Securely managing GPG keys using GitHub secrets.
• Familiar workflow, though less transparent and auditable compared to Cosign.

Option 4: External Key Management (e.g., HashiCorp Vault, AWS KMS)

• Leveraging secure key storage solutions to enhance security.
• Increased complexity but higher security around key management.
• Does not provide built-in transparency logs but offers robust key management practices.

Recommendation:

• Evaluate multiple approaches with a preference toward adopting Cosign for its transparency, ease of automation, and security.
• Consider Witness + Archivista for comprehensive attestation and supply chain enforcement, especially if we aim to support compliance frameworks or layered provenance.

What alternatives exist?

Other alternatives that were considered and can be potentially discarded:

• Continue Manual GPG Signing: Discarded due to scalability and security concerns. Key management overhead and potential for human error remain high.
• Third-party Vendor Solutions (e.g., JFrog Artifactory Signing Service): Discarded due to vendor lock-in, licensing costs, and higher complexity compared to the simplicity and openness provided by other mentioned solutions.

Other Considerations?

• Transparency and Auditability: Cosign’s reliance on transparency logs is beneficial but introduces reliance on external infrastructure. Evaluate backup verification methods if Sigstore's transparency log service becomes unavailable.
• Learning Curve: Any new solution will involve a short learning curve and transition period. Proper documentation and training sessions can mitigate this.
• Fallback Options: Maintain a fallback mechanism using traditional GPG signing capabilities in the short term to mitigate risks during the transition.

Feedback, concerns, and additional insights are highly encouraged to refine this proposal further.

[alexlovelltroy]

My understanding is that GPG signing is mandatory for RPMs. Our process today is that we have an offline key with subkeys for each repo. The offline key is managed by me. I'd like an option that doesn't make me a bottleneck for signing RPMs.

We're already using the github tooling to attest all containers and binaries with a transparency log. I think we attest the RPMs as well, but I'm not sure. yum/dnf/rpm doesn't appear to have a way to verify attestations as part of installation.