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 <email@example.com" 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 firstname.lastname@example.org 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 <email@example.com> uid [ full ] bill-auger <firstname.lastname@example.org> uid [ full ] bill-auger <email@example.com> 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 <firstname.lastname@example.org>" [full] gpg: aka "bill-auger <email@example.com>" [full] gpg: aka "bill-auger <firstname.lastname@example.org>" [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 8 months 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
Updated by bill-auger 7 months ago
yes, the ISO should be re-made; but the existing ones are still
usable - just upgrade the keyrings before running pacstrap
# pacman -Sy archlinux-keyring archlinux32-keyring parabola-keyring
if you follow the install guide, it suggests that you should do so
Hey. I tried that and also what the installation guide said, but ran into a similar issue as Mampir above when trying to refresh the keys. Only difference is that I get a "Server indicated a failure" instead of "General error".
I get the same with that other keyserver as well, but no change. I'm connected to the Internet. Not sure what's causing.
Updated by bill-auger 4 months ago
its not "still" present - this BR is marked as 'fixed' - it is
present "again"; and i am aware of it - the keyring package needs
to be re-built - i will re-open this ticket though, so that others
may find it easily
the solution is always the same: one of the options described on
the wiki - in this case, it is section #1
None of the sections helps, pacman can't refresh the keys. When approximately can this problem be solved? As I understand it, it has been present for a relatively long time, so in fact no one can install the distribution, unless they change the pacman configuration, which is a risk
Updated by bill-auger 4 months ago
- Status changed from in progress to fixed
this was never a critical problem, and it is not "still" present - this BR represents a recurring symptom of a problem, which took several iterations and experiments to uncover - the root cause of the problem was discovered 5 months ago, the keyring was rebuilt, and this ticket was marked as 'fixed' - that particular problem should never happen again, and it has not since - it was necessary to delay this latest keyring rebuild slightly, to verify that the fix was correct
that was all to say that this ticket represents not a "problem" exactly, but an inconvenience - all that anyone needed to do, was to refresh the keyring - no one was prevented from installing the distro - it would only be a critical problem (eg: justifying to disable signature checking), if some key was actually expired - even then, it would be better to simply wait until the key gets renewed
are you still having a problem with keys?
this was never a critical problem, and it is not "still" present
I don't want to start an argument, but I feel you are being overly dismissive when it comes to that issue.
This problem has been present ever since I've first started using Parabola, which has been at least several years now. Yeah, at the end and I was always able to fix, even if sometimes takes several weeks of just not being able to update any packages, when the --refresh-keys method just refuses to work. It seems to me that anybody that has ever used Parabola had to deal with this issue, probably multiple times, and it's never obvious how to deal with it, especially when you first encounter it. And if you are that much into dealing system administration stuff, it's even harder to deal with. I understand when you are installing and maintaining a Parabola system, you should know what you are generally doing, so it's not for people who have no idea about GNU/Linux system administration, but there are levels of understanding even when it comes to that.
And it's always the same exact key that's the problem.
I feel like you are being way too dismissive about the issue. Honestly, in my years of using Parabola personally, and also helping other people use Parabola, this issue has been the most persistent and most annoying problem of them all. The error message is just too cryptic and doesn't explain what the problem is in a useful way. And I would argue, that in a normal situation, you just should get this error, and yet I get it very frequently.
Please, reconsider the severity of this issue.