signature from bill-auger is unknown trust
I'm trying to install on a x86_64 laptop, but keep bumping on the same issue. Signature is unknown trust for bill-auger.
The usual operations of clearing the cache, initializing, populating, and refreshing the keyring don't work.At this step (pacstrap base libelogind), the concerned packages are:
Since bill-auger's key has recently expired, I suppose it's not an issue with my system.
Right, sorry. I tried installing the affected packages again in the same way, and the signature checks passed. I assumed you fixed something on the server side. Nevertheless, the issue is back again today.
While the issue was present I was still able to install the affected packages by changing the following settings in the live ISO's /etc/pacman.conf:
SigLevel = Never
LocalFileSigLevel = Never
... which disables the signature checks. This is obviously a huge security risk, and it might've been foolish of me, but whatever. I didn't think the mirrors would serve malicious packages, and I was right (like I said above, they later passed the checks). I do not have these settings on my installed system.
To be clear, the issue was temporarily resolved from around the time of my last post to at least a while later. This was not related to me changing my config.
there is a known recurring bug in the keyring builder;
which recurred yesterday
there will be temporary interruption in the normal pacman
This doesn't seem to have solved it. Do we know what the bug is, and if so, how do we fix it? Can I help?
I've noticed the same problems on 2 machines since 10 days ago. The problem still remains. One thing not mentioned yet is that 'pacman --refresh-keys' doesn't work:
sudo pacman-key --refresh-keys gpg: refreshing 152 keys from hkps://hkps.pool.sks-keyservers.net gpg: keyserver refresh failed: General error ==> ERROR: A specified local key could not be updated from a keyserver.
Not sure if the problems are related. Specifying a key server with '--keyserver hkp://pool.sks-keyservers.net' seems to refresh some keys, but after that the 'Signature from bill-auger is unknown trust' problem remains.
Is there a workaround that doesn't involve disabling the package signature checks?
I posted this in IRC on #parabola last night, but I want to repeat it here because it allowed me to successfully update my packages. Skip to the bottom for steps for resolution.
I was trying to do an update, and I received the message,
error: pacman-mirrorlist: signature from "bill-auger <firstname.lastname@example.org" is unknown trust.
==> ERROR: The signature identified by pacman-mirrorlist-20201002-1.parabola1-any.pkg.tar.xz.sig could not be verified.
I also was unable to refresh the keys with
pacman-key --refresh-keys. Thinking it was the keyserver's fault, I tried
pacman-key --refresh-keys --keyserver hkp://keyserver.ubuntu.com and it did not refresh bill-auger's key.
I looked in the Parabola wiki, and found this page which suggested to reset the Parabola keyring (https://wiki.parabola.nu/Parabola_Keyring). I reset the keyring, but did not affect the problem.
In order to figure out what failed exactly, I downloaded the "broken" package (.tar.xz) plus its PGP signature (.sig) from http://repo.parabola.nu/libre/os/armv7h/ (my platform is armv7h). I did a
pacman-key --list-keys email@example.com and the key looked fine, but that it was expiring soon (only five days into the future).
pub rsa2048 2016-11-30 [SCEA] [expires: 2020-11-19] 3954A7AB837D0EA9CFA9798925DB7D9B5A8D4B40 uid [ full ] bill-auger <firstname.lastname@example.org> uid [ full ] bill-auger <email@example.com> uid [ full ] bill-auger <firstname.lastname@example.org> uid [ full ] [jpeg image of size 6017] sub rsa2048 2016-11-30 [SEA] [expires: 2020-11-19]
I then did a
pacman-key --verify pacman-mirrorlist-20201002-1.parabola1-any.pkg.tar.xz.sig to check the sig of my broken package, and it told me the signing key was expired.
==> Checking pacman-mirrorlist-20201002-1.parabola1-any.pkg.tar.xz.sig... (detac hed) gpg: Signature made Fri 02 Oct 2020 10:19:04 AM UTC gpg: using RSA key FBCC5AD7421197B7ABA72853908710913E8C7778 gpg: Good signature from "bill-auger <email@example.com>" [full] gpg: aka "bill-auger <firstname.lastname@example.org>" [full] gpg: aka "bill-auger <email@example.com>" [full] gpg: aka "[jpeg image of size 6017]" [full] gpg: Note: This key has expired! Primary key fingerprint: 3954 A7AB 837D 0EA9 CFA9 7989 25DB 7D9B 5A8D 4B40 Subkey fingerprint: FBCC 5AD7 4211 97B7 ABA7 2853 9087 1091 3E8C 7778 ==> ERROR: The signature identified by pacman-mirrorlist-20201002-1.parabola1-an y.pkg.tar.xz.sig could not be verified.
The package was signed using the subkey 3E8C7778, which expired four days ago (2020-11-10). http://hkps.pool.sks-keyservers.net/pks/lookup?op=vindex&fingerprint=on&search=0xFBCC5AD7421197B7ABA72853908710913E8C7778
So, assuming the verification failed due to this expired key, I disabled network access (but one could just stop timedatectl, too--my communication was via serial port) then reset my date to November 1, 2020 with
date --set="2020-11-01 00:00". This allowed verification to continue.
So, in order to resolve this verification failure, I took the following steps to update my packages:
- Try to upgrade and fail
- Reset the date to 2020-11-01
- Continue upgrade with packages from cache
- Set date back to "now"
bill-auger states that this ticket is just a symptom of a different issue with the keyring. This is explained further in the IRC chatlog, which is attached. Resetting the date works around verification, but him re-signing that key is not a final solution.
its an old known problem with the keyring package
Updated by bill-auger 14 days ago
ignoring the signatures is not the best work-around though; and it can not be recommended
davisr found a clever work-around, which verifies all signatures properly, though - that is to set the system clock to a date before the expiry (2020-11-06) before installing the troublesome packages
one could o/c download each package and verify the signatures manually, without making any changes to the host system
its an old known problem with the keyring package
yes, it could have had i dedicated bug report many months ago - there have been multiple BRs like this one; because of the same root cause - i just opened a new ticket for it #2931