Fedora Account System
Red Hat Associate
Red Hat Customer
During an openQA test run, the package signature check found one installed RPM package without a GPG signature. The affected package is `bootupd`. The test executed the following command: ```bash rpm -qa --queryformat '%{NAME} %{RSAHEADER:pgpsig}\n' | grep -E -v "gpg-pubkey" | grep "(none)" ``` Actual result: ```text bootupd (none) ``` Reproducible: Always Steps to Reproduce: 1. Install CoreOS (Fedora-CoreOS-44.20260626.20.1) 2. Run the above command. 3. See the results. Actual Results: This causes the package signature validation test to fail and indicates that `bootupd` was installed without a valid RPM header signature. Expected Results: No installed RPM package should be reported without a GPG signature. Additional Information: The failure was seen during the openQA test after the system had booted successfully. Other diagnostic logs were collected, but the unsigned package check reports only `bootupd`. https://openqa.fedoraproject.org/tests/4908288#step/check_packages_signed/5
That looks really weird to me as I don't think we do anything special here. Aren't all packages signed before they reach bodhi? Or maybe that happens only before they reach the testing repos? Is this somehow because we got it in FCOS (https://github.com/coreos/fedora-coreos-config/pull/4212) before the update reached testing? (https://bodhi.fedoraproject.org/updates/FEDORA-2026-629714e3d0)
> Is this somehow because we got it in FCOS before the update reached testing? Drive-by comment: In most cases (except releng-managed side-tags) builds are only scheduled for signing when the bodhi update is created. So even if you submitted the update to bodhi *before* using it in FCOS, there is a short(*) window where a build that was submitted to "pending->testing" is still unsigned (*how short depends on how backed up the signing queue is).
Thanks Fabio, that's my best bet on what happened here. But now I'm wondering why the new builds don't have the signed build. Maybe because we tagged the unsigned in the coreos-pool and so we would have to remove it and re-tag it?
Possibly ... probably best to ask releng to take a look - signing is weird.
https://forge.fedoraproject.org/releng/tickets/issues/13397 & https://github.com/coreos/fedora-coreos-tracker/issues/2173
Added context in https://github.com/coreos/fedora-coreos-tracker/issues/2173#issuecomment-4813034094 TL;DR this behavior can be an artifact of how we do development builds in Fedora CoreOS.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 45 development cycle. Changing version to 45.