I’ve had this happen before too where only one of those keys worked. There’s been other issues on this forum about this. OP has a point. The ubuntu key works, but the github one doesn’t, or something like that. And that’s strange.
I am saying this from memory but I remember those keys not matching.
The keys do not “match” for a simple reason. If you upload an updated key
to a keyserver, the keyserver does not replace the copy it holds, but
merges the new key with the old. (The same for signed keys.) The copy
you get from the keyserver will show the history of the key. The copy
from GitHub will simply show the new expiry date.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Followed all the steps: downloaded the public key from multiple servers, checked the subkeys, copied the key to dom0 in “unman.asc”, then:
user@dom0:~$ sudo rpmkeys --import unman.asc
error: Certificate 8B3F30F9C8C0C2EF:
Policy rejects 8B3F30F9C8C0C2EF: No binding signature at time 2026-09-02T12:18:05Z
error: unman.asc: key 1 import failed.
Forgot to mention that I used “rpmkeys --list” and then deleted the old unman key with “rpmkeys --delete xxxxxxxxx-yyyyyyyyy”
On my end, I did yet find time nor a good way to film the entire procedure to prove the point that the procedure does not work and we should investigate further on why and how.
Thanks. I’ve just run through this on 3 machines - a 4.3 updated, 4.3.1
rc2 updated, 4.3.1 updated. I used the key from GitHub and from the
Ubuntu keyserver. In no case could I replicate this. Weird.
I would guess that this error arises because rpm rejects old keys signed
with SHA-1. You could test this by:
update-crypto-policies --set LEGACY
rpmkeys --import KEY
update-crypto-policies --set DEFAULT
and see if that works. That would confirm that this is the issue.
Alternatively run `gpg --list-packets KEYFILE | grep -E ‘signature
packet> digest algo’ and review output.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Quick summary: setting the policy to LEGACY did not work.
Details:
user@dom0:~$ update-crypto-policies --show
DEFAULT
user@dom0:~$ update-crypto-policies --set LEGACY
You must be root to run update-crypto-policies.
user@dom0:~$ sudo update-crypto-policies --set LEGACY
Setting system policy to LEGACY
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
user@dom0:~$ sudo rpmkeys --import unman.asc
error: Certificate 8B3F30F9C8C0C2EF:
Policy rejects 8B3F30F9C8C0C2EF: No binding signature at time 2026-09-02T13:30:18Z
error: unman.asc: key 1 import failed.
user@dom0:~$
So I rebooted, as suggested. After reboot:
user@dom0:~$ sudo rpmkeys --import unman.asc
error: Certificate 8B3F30F9C8C0C2EF:
Policy rejects 8B3F30F9C8C0C2EF: No binding signature at time 2026-09-02T13:34:44Z
error: unman.asc: key 1 import failed.
user@dom0:~$ update-crypto-policies --show
LEGACY
user@dom0:~$
No luck.
This garbage is not what I wrote. Why discourse rewrites the content of
code blocks is a mystery.
It should read “packet | digest” - a pipe not a right angle bracket.
user@dom0:~$ gpg --list-packets unman.asc | grep -E 'signature packet|digest algo'
:signature packet: algo 1, keyid 8B3F30F9C8C0C2EF
digest algo 8, begin of digest df 31
subpkt 32 len 540 (signature: v4, class 0x19, algo 1, digest algo 8)
:signature packet: algo 1, keyid 8B3F30F9C8C0C2EF
digest algo 8, begin of digest 1c ee
subpkt 32 len 540 (signature: v4, class 0x19, algo 1, digest algo 8)
:signature packet: algo 1, keyid 8B3F30F9C8C0C2EF
digest algo 8, begin of digest 05 3b
user@dom0:~$
Yeah, I fixed the command. Probably the mail → forum conversion bug.
algo 1 - signature uses RSA
digest algo 8 - signature uses SHA-256
signature: v4, class 0x19, algo 1, digest algo 8 - signature uses
OpenPGP Version 4, it’s bound back to primary key, hashed with SHA-256,
signed using RSA.
Nothing odd there. In fact it’s the same output that I have with keys
that work.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Dont forget to reset the policies to DEFAULT
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
The issue is why it works for some people and not others. Can we
standardise on using:
- The key from the Ubuntu keyserver
- The key from GitHub.
Both are linked from https://qubes.3isec.org/pgp.html
Both of these keys import straightforwardly on multiple machines. On
this current machine I have RPM version 4.20.1 on a vanilla 4.3.1 Qubes.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
This one works! With the policies reset to DEFAULT, even.
user@dom0:~$ sudo update-crypto-policies --show
DEFAULT
user@dom0:~$
user@dom0:~$ sudo rpmkeys --import unman-git.asc
user@dom0:~$
The key that didn’t work was downloaded from the openpgp keyserver (which had all the correct fingerprints)
OK
Stranger and stranger - that key has exactly the same signing
structure as the one from GitHub, and other users have reported that
that key works when the GitHub one does not. In fact the keyserver one
is created by uploading the GitHub key - the keyserver appends new data
to its existing copy.
Thanks for your efforts here.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.