Feature/dry quadlet rpms

[seantronsen]

Pull Request Template

Thank you for your contribution! Please ensure the following before submitting:

Checklist

• My code follows the style guidelines of this project
• I have added/updated comments where needed
• I have added tests that prove my fix is effective or my feature works
• I have run make test (or equivalent) locally and all tests pass
• I have updated the relevant documentation (CLI examples, man pages, README, other docs, etc.)
• DCO Sign-off: All commits are signed off (git commit -s) with my real name and email
• REUSE Compliance:
  • Each new/modified source file has SPDX copyright and license headers
  • Any non-commentable files include a <filename>.license sidecar
  • All referenced licenses are present in the LICENSES/ directory

Description

I'll update this description as time goes on and this is less of a "draft"... anyways:

This PR is motivated primarily by OpenCHAMI/release#64 which requires decomposing the current release repository RPM. More specifically, we'll be moving towards one podman quadlet RPM build per service repository.

Most of the repositories therefore need a similar setup for CI/CD and it seemed best to abstract out the routines instead of pasting the requisite workflows into N different repositories.

...and that's how we got here...

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Dependency update

---

For more info, see Contributing Guidelines.

[seantronsen]

Post-merge follow-up: .github/workflows/gpg-sign-artifacts.yml pins its 4 composite-action calls to @dev-rpm-quadlets (a dev branch ref) — lines 49, 56, 74, 81. Bump these to the next release tag in the version-bump PR:

sed -i 's/@dev-rpm-quadlets/@<NEW_TAG>/g' .github/workflows/gpg-sign-artifacts.yml

[seantronsen]

@alexlovelltroy this is ready and tested. The linter is complaining because I used the last commit to swap the target tags for some actions to the "would be" next release tag for this repo (trying to save you from reviewing two separate PRs).

[alexlovelltroy]

1. Looks like sign-rpm now handles signing all created rpms instead of just the first one. That's great, but validate-rpm-quadlet still only validates the first one.
2. Have you run actionlint against these?
3. Do you know which other repos will need to be updated to take advantage of the new workflows?

[alexlovelltroy]

I would have thought this should be true. Is there a reason we would want to verify the trust chain without access to the master public key?

[seantronsen]

Hmm, I'll have to check my notes to see why I did that last week... should be able to invert that flag without any issues, but I'll double check with some testing.

[seantronsen]

Verified key archive from one of yesterday's CI jobs manually:

root@9055e9f166f0:/tmp/tmp.xFTcAYjGTq# cat script.sh

export GNUPGHOME=$(mktemp -d)

gpg --import *.asc

for f in *.asc; do
  echo "=== "
  echo "$f"
  gpg --import-options show-only --import --list-options show-sig-subpackets     --with-sig-list "$f" 2>/dev/null
done

root@9055e9f166f0:/tmp/tmp.xFTcAYjGTq# sh script.sh
gpg: keybox '/tmp/tmp.LNa6mKi3T8/pubring.kbx' created
gpg: key 5CAE47494A229A3D: 1 signature not checked due to a missing key
gpg: /tmp/tmp.LNa6mKi3T8/trustdb.gpg: trustdb created
gpg: key 5CAE47494A229A3D: public key "OpenCHAMImetadata-service Release (ephemeral key for 35merge build-30845929148-35a113f5b51a) <release@packages.openchami.org>" imported
gpg: key 0AA4F9403DF8F038: public key "OpenCHAMI Software Signing Key <admin@openchami.org>" imported
gpg: key B4EEEA33E8DA87C7: public key "OpenCHAMI/metadata-service RPM Signing Key <OpenCHAMI-metadata-service@packages.openchami.org>" imported
gpg: Total number processed: 3
gpg:               imported: 3
gpg: no ultimately trusted keys found
===
ephemeral.pub.asc
pub   rsa4096 2026-08-03 [SC] [expires: 2026-08-04]
      7B544FC70ED58E0A8D4E58A65CAE47494A229A3D
uid                      OpenCHAMImetadata-service Release (ephemeral key for 35merge build-30845929148-35a113f5b51a) <release@packages.openchami.org>
sig 3        5CAE47494A229A3D 2026-08-03  [self-signature]
sig          B4EEEA33E8DA87C7 2026-08-03  OpenCHAMI/metadata-service RPM Signing Key <OpenCHAMI-metadata-service@packages.openchami.org>

===
master.pub.asc
pub   ed25519 2026-03-30 [C] [expires: 2031-03-29]
      FE586537D05A111C9C00E88B0AA4F9403DF8F038
uid                      OpenCHAMI Software Signing Key <admin@openchami.org>
sig 3    N   0AA4F9403DF8F038 2026-03-30  [self-signature]
sub   ed25519 2026-03-30 [S] [expires: 2031-03-29]
sig      N   0AA4F9403DF8F038 2026-03-30  [self-signature]
sub   rsa4096 2026-03-30 [S] [expires: 2027-03-30]
sig      N   0AA4F9403DF8F038 2026-03-30  [self-signature]
sub   rsa4096 2026-03-30 [S] [expires: 2027-03-30]
sig      N   0AA4F9403DF8F038 2026-03-30  [self-signature]
sub   rsa4096 2026-03-30 [S] [expires: 2027-03-30]
sig      N   0AA4F9403DF8F038 2026-03-30  [self-signature]
sub   rsa4096 2026-03-31 [S] [expires: 2027-03-31]
sig      N   0AA4F9403DF8F038 2026-03-31  [self-signature]

===
repo-cert.pub.asc
pub   ed25519 2026-07-29 [C] [expires: 2027-07-29]
      2110BF8E84019844E0C0E0CFB4EEEA33E8DA87C7
uid                      OpenCHAMI/metadata-service RPM Signing Key <OpenCHAMI-metadata-service@packages.openchami.org>
sig 3    N   B4EEEA33E8DA87C7 2026-07-29  [self-signature]
sig          0AA4F9403DF8F038 2026-07-29  OpenCHAMI Software Signing Key <admin@openchami.org>

Long winded way of saying "chain is working properly". I'll go verify the toggle now and have it default to true.

[seantronsen]

85b10a5

[alexlovelltroy]

We need the copyright info at the top

[seantronsen]

48f68da

[alexlovelltroy]

I'm confused about this. Could it pass without actually verifying anything?

[seantronsen]

Technically, yes, especially with naive configuration. The original idea was essentially to provide an "opt-out" mechanism to simplify future development efforts in downstream repos (e.g., boot-service) should the need arise. A temporary off switch.

With 85b10a5, I changed this to default to true (defaults to enforcing / require master key).

Let me know if you want me to remove the option entirely (i.e., always enforcing, no off switch).

[seantronsen]

@alexlovelltroy

1. Looks like sign-rpm now handles signing all created rpms instead of just the first one. That's great, but validate-rpm-quadlet still only validates the first one.

Ah, this is the low hanging fruit. To be clear, it's definitely doable, but it will require nested JSON | YAML shenanigans. I'll update and opt for yaml since it's a little be easier to read/write on the user side.

2. Have you run actionlint against these?

Yes, but only through the actionlint workflow already configured for this repo. After reading through the project homepage, I've noticed that it only lints the workflows themselves and not any of the actions in this repository... is that something you want to look into in a different PR?

3. Do you know which other repos will need to be updated to take advantage of the new workflows?

Immediate Updates

Current Stable Services

• https://github.com/OpenCHAMI/cloud-init
• https://github.com/OpenCHAMI/smd
• https://github.com/OpenCHAMI/bss
• https://github.com/OpenCHAMI/opaal
• https://github.com/OpenCHAMI/versitygw-quadlet
• https://github.com/OpenCHAMI/coresmd

Current Stable Meta

• https://github.com/OpenCHAMI/release

Current Stable CLI tools

• https://github.com/OpenCHAMI/ochami
• maybe magellan?

Next Stable Services

• https://github.com/OpenCHAMI/local-ca
• https://github.com/OpenCHAMI/metadata-service
• https://github.com/OpenCHAMI/tokensmith
• https://github.com/OpenCHAMI/boot-service
• https://github.com/OpenCHAMI/inventory-service

Future Updates

Additional Services

• https://github.com/OpenCHAMI/remote-console
• https://github.com/OpenCHAMI/tpm-identity-service
• fru-tracker

Note

Basically, anything we could distribute in RPM format is listed here. The actual RPM sign + validate + publish workflows are entirely agnostic. Build assumes a makefile recipe, though that isn't hard to change. The goreleaser workflow is just an abstraction to simplify work in all the service repositories which are primarily written in go and published also as containers (...which is most of them).

[seantronsen]

@alexlovelltroy

1. Looks like sign-rpm now handles signing all created rpms instead of just the first one. That's great, but validate-rpm-quadlet still only validates the first one.

Ah, this is the low hanging fruit. To be clear, it's definitely doable, but it will require nested JSON | YAML shenanigans. I'll update and opt for yaml since it's a little be easier to read/write on the user side.

43788dc should solve this. About to test using the metadata-service repo.

It currently only supports expected files, but it's rather easy to extend on to include things like expected dependencies + versions, provides, etc.