pacman -- error: linux: missing required signature

kevdog · 2020-12-19 17:56:54

I'm not sure why I'm missing a required signature on the linux kernel:

pacman.conf

[options]
HoldPkg     = pacman glibc
Architecture = auto

CheckSpace

SigLevel    = Required DatabaseOptional
LocalFileSigLevel = Optional

[archzfs]
Server = http://archzfs.com/$repo/x86_64

[zfs-linux]
Server = http://kernels.archzfs.com/$repo/

[zfs-linux-lts]
Server = http://kernels.archzfs.com/$repo/

[core]
Include = /etc/pacman.d/mirrorlist

[extra]
Include = /etc/pacman.d/mirrorlist

[community]
Include = /etc/pacman.d/mirrorlist

# pacman -Syu
...
...
(42/42) checking keys in keyring                              [##################################] 100%
(42/42) checking package integrity                            [##################################] 100%
error: linux: missing required signature
error: failed to commit transaction (invalid or corrupted package)
Errors occurred, no packages were upgraded.

I tried updating the keyring
gpg --refresh-key
pacman-key --init && pacman-key --populate archlinux
pacman-key --refresh-keys

I even delete the /etc/pacman.d/gnupg and started over.
Perhaps its not a keyring issue.

but that didn't seem to do anything.

I'm sure I'm missing something obvious

Last edited by kevdog (2020-12-19 18:43:05)

zpg443 · 2020-12-19 18:40:09

ZFS is not an officially supported kernel, so there is that...

https://wiki.archlinux.org/index.php/Kernel

Last edited by zpg443 (2020-12-19 18:51:02)

Scimmia · 2020-12-19 18:44:39

Missing *signature*, not missing key.

You're installing a package from a 3rd party repo that doesn't have signatures, but you have signatures set to required.

kevdog · 2020-12-19 18:46:44

Here is the statement from the arch wiki in relation to the zfs repo:

archzfs-kernels
Maintainer: Endre Szabo
Description: Official kernel packages matching the most recent ZFS packages kernel version dependencies. Use this to be able to upgrade your kernel package every time whilst using ZFS packages from the above repo This is actually not one but a bunch of separate repos, one for each ArchZFS package that has any kernel dependency. See the upstream page for details on how to use.
Upstream page: https://end.re/archzfs-kernels/
Key-ID: Not needed as packages are from core repos and signed officially.

Last edited by kevdog (2020-12-19 18:49:40)

Scimmia · 2020-12-19 18:52:21

And they apparently screwed it up

kevdog · 2020-12-19 18:56:01

As a temp workaround I added this:

[zfs-linux]
SigLevel = Optional
Server = http://kernels.archzfs.com/$repo/

[zfs-linux-lts]
SigLevel = Optional
Server = http://kernels.archzfs.com/$repo/

I have no explanation why I have to do this on only one of 3 arch VM's I'm running, particularly when they all were derived from the same master clone.

@Scimmia
I have no idea if they screwed up their implementation. It's totally possible. I posted a comment on the homepage but haven't heard anything back:
https://end.re/blog/ebp036_archzfs-repo-for-kernels/

Last edited by kevdog (2020-12-19 18:57:53)

Scimmia · 2020-12-19 18:58:44

I just checked the repo database to be sure, and there are no signatures in it. There's no way SigLevel = Required will work with those repos on any machine running a standard, released version of pacman.

Edit: I take that back, they have the sig for the headers package, but not for the kernel package. Someone just made a mistake.

Last edited by Scimmia (2020-12-19 19:14:07)

zpg443 · 2020-12-19 19:04:47

Just pointing out you may need to rely on in-house support for everything that could go wrong. This is the “hidden” cost of using an unofficial kernel.

loqs · 2020-12-19 19:05:47

If you need to use an old kernel for ZFS you can obtain it from the ALA and maintain signature verification.

kevdog · 2020-12-19 21:13:55

@zpg443

I'm aware it's "unofficial". I suppose I could use a dkms kernel for zfs support if needed. Kind of sucky a zfs enabled kernel is "unofficial".

Scimmia · 2020-12-19 21:24:15

except it's not a zfs enabled kernel. It's just a copy of the exact same kernel that's in the core repo.

Trilby · 2020-12-19 22:40:27

Which of course begs the question of why on earth anyone would use that repo.

From what I can tell, their intended purpose is essentially to allow you to retain a slightly outdated kernel when needed to match the zfs packages. A much better solution would simply to put linux as an ignored package and update it explicitly when appropriate.

Last edited by Trilby (2020-12-19 22:40:54)

Scimmia · 2020-12-19 23:47:05

Yep. And even if they did decide a separate repo was approperiate, why separate repos for each kernel? Why not one repo for all kernels, or just put them in the normal archzfs repo? Makes no sense at all.

WorMzy · 2020-12-20 00:32:14

Mod note: moving to AUR Issues

kevdog · 2020-12-20 02:09:55

AUR? This is not really an AUR issue

Last edited by kevdog (2020-12-20 02:10:21)

endre · 2020-12-21 09:30:35

I might be late to the party, but.. these repos were made by yours truly. I got here from the archwiki delete commit message and just registered to comment here. Let me just elegantly ignore all your hatred and focus on the real problems.

The kernel signature file was totally empty, yet repo-add was happy with it and put the entry into the DB without any error or warning. This section in function db_write_entry():

# compute base64'd PGP signature
if [[ -f "$pkgfile.sig" ]]; then

checks for the signature not being larger than 16k, but will silenty ignore the whole existence of the signature if the key is 0 bytes in length. I fixed my signature file and the repo db files. On a nice day I might create a PR for the repo-add fix.

Last edited by endre (2020-12-21 09:32:27)

Trilby · 2020-12-21 13:58:49

endre wrote:

Let me just elegantly ignore all your hatred and focus on the real problems.

I'm not sure what you saw as "hatred" - but there were a few problems highlighted. What you tried to address, however, was really just a symptom. The real problem is that there is no reason for (several) third party repos to host official kernels.

Last edited by Trilby (2020-12-21 13:59:10)

endre · 2020-12-21 14:12:33

Trilby wrote:

The real problem is that there is no reason for (several) third party repos to host official kernels.

You aren't a ZFS user, are you? How would you install a kernel that's not in the official repos anymore, yet that's the most recent one that ArchZFS is compilest against? Go to ALA and download the appropriate one every time?

Why do you want to tell us how live our lives? Have you seen my blogpost on what problem these repos solve? It's a recent development that I had to split up the original repo as ArchZFS now has packages depending on more than one version of the same Linux branch. And pacman/repo-add can't handle having different versions of the same package in one repo. And I'm not hosting any kernels, but we will hardly go into any more details.

Well, the toxicity here turned out to be true after all.

Trilby · 2020-12-21 14:20:58

endre wrote:

Well, the toxicity here turned out to be true after all.

If you see civil disagreement as "toxicity" then you should not enter into technical discussions. You're the only one in this thread being inflammatory and insulting. As for your questions, they've been answered already in this thread.

Last edited by Trilby (2020-12-21 14:22:32)

seth · 2020-12-21 16:03:26

https://end.re/blog/ebp036_archzfs-repo-for-kernels/ wrote:

Based on the good ol' Gentoo memories, you might think that the package manager of this ultramodern distribution surely can handle different kernel versions installed at the same time? Unfortunately, the implementation reality of pacman, the package manager of ArchLinux follows a different stereotype.

I will elegantly kindly ignore that even if this wasn't snarky nonsense, it would still not be true and move to the real problem:
Why do you need "different kernel versions installed at the same time" when the described problem is that

https://end.re/blog/ebp036_archzfs-repo-for-kernels/ wrote:

the OpenZFS project gets behind on stable support for the latest Linux Kernel release. This means that if Linux 4.15 is released to core, but the latest stable release of OpenZFS does not support Linux 4.15, it is not possible to perform a system update

You don't need different versions at the same time, but a/the version that has OpenZFS support (at this point in time) so you don't *want* the repo-kernel itfp. and rather have the zfs-linux-whatever packages provide the linux-whatever kernels and headers and indeed eg. use the pre_install function to check for the installed kernel and in need download and install it from - yes - the ALA.

Relying on yet another repo that also has to be maintained just introduces more complexity to the problem at hand.

I frankly don't know what you mean by

Due to new packages with conflicting kernel versions appearing in upstream repo

It would probably be very nice if pacman could dynamcally ignore updates if another package required a specific version, but that would constitute a partial update which is more or less in the only case of the kernel an ok-ish thing to do.

GSMiller · 2020-12-21 19:42:34

endre wrote:

Well, the toxicity here turned out to be true after all.

As Trilby said, this is not the point of the Archlinux forums. We like to engage in sharp witted technical discussions.
There is no place for sentiment. We do not like or dislike your package. It is only too complicated to solve a problem that can be solved much better if you have the technical know how. This is what has been said.

eschwartz · 2020-12-27 03:23:49

endre wrote:

I might be late to the party, but.. these repos were made by yours truly. I got here from the archwiki delete commit message and just registered to comment here. Let me just elegantly ignore all your hatred and focus on the real problems.
The kernel signature file was totally empty, yet repo-add was happy with it and put the entry into the DB without any error or warning. This section in function db_write_entry():
# compute base64'd PGP signature
if [[ -f "$pkgfile.sig" ]]; then
checks for the signature not being larger than 16k, but will silenty ignore the whole existence of the signature if the key is 0 bytes in length. I fixed my signature file and the repo db files. On a nice day I might create a PR for the repo-add fix.

So everything is repo-add's fault for doing what you told it to do, but not your fault for having mysterious empty files which your release process told repo-add should contain signatures? Fix your... thing... which completely failed to download or *whatever* the files it processed.
We do NOT currently try to enforce validating "the file might have been incorrectly downloaded", but we do check that you didn't accidentally use gpg --sign instead of --detach-sign: https://bugs.archlinux.org/task/27453
This then breaks the entire database record at parse time, rather than merely causing it to be missing a signature that depends on you not configuring "SigLevel = Never".

Even if repo-add refused to update the package, you would still need to fix your thing and re-run repo-add. So your thing is conclusively broken, even if repo-add could have done a better job of notifying you that is the case.

Note that pacman 6.0.0alpha1 tries to download and use the .sig files and we're going to deprecate/remove that entire section from the database, at which point you'll once again be completely one hundred percent responsible on your end for validating your own sync code even if temporary checks are added to repo-add.

Anyway, I'm opposed to adding code that checks if it is 0 bytes, but doesn't check if it is, say, 40 bytes and cuts off in the middle... size checks are good for preventing overflow of parser limits, not so good for checking that something is actually a valid PGP signature. Official tooling for the official repos actually runs pacman-key --verify on the proposed package update before letting it be added, thus checking not only that it is 1) not a zero-byte file, but also that it is 2) a successfully validating PGP signature, that is 3) released by someone in the trusted set.

(repo-add will NOT be changed to reject packages signed by untrusted keys, since people might be using it to generate databases on diverse systems not necessarily configured to consume the same packages. repo-add does not even need to be run on an archlinux OS.)

Arch Linux

#1 2020-12-19 17:56:54

pacman -- error: linux: missing required signature

#2 2020-12-19 18:40:09

Re: pacman -- error: linux: missing required signature

#3 2020-12-19 18:44:39

Re: pacman -- error: linux: missing required signature

#4 2020-12-19 18:46:44

Re: pacman -- error: linux: missing required signature

#5 2020-12-19 18:52:21

Re: pacman -- error: linux: missing required signature

#6 2020-12-19 18:56:01

Re: pacman -- error: linux: missing required signature

#7 2020-12-19 18:58:44

Re: pacman -- error: linux: missing required signature

#8 2020-12-19 19:04:47

Re: pacman -- error: linux: missing required signature

#9 2020-12-19 19:05:47

Re: pacman -- error: linux: missing required signature

#10 2020-12-19 21:13:55

Re: pacman -- error: linux: missing required signature

#11 2020-12-19 21:24:15

Re: pacman -- error: linux: missing required signature

#12 2020-12-19 22:40:27

Re: pacman -- error: linux: missing required signature

#13 2020-12-19 23:47:05

Re: pacman -- error: linux: missing required signature

#14 2020-12-20 00:32:14

Re: pacman -- error: linux: missing required signature

#15 2020-12-20 02:09:55

Re: pacman -- error: linux: missing required signature

#16 2020-12-21 09:30:35

Re: pacman -- error: linux: missing required signature

#17 2020-12-21 13:58:49

Re: pacman -- error: linux: missing required signature

#18 2020-12-21 14:12:33

Re: pacman -- error: linux: missing required signature

#19 2020-12-21 14:20:58

Re: pacman -- error: linux: missing required signature

#20 2020-12-21 16:03:26

Re: pacman -- error: linux: missing required signature

#21 2020-12-21 19:42:34

Re: pacman -- error: linux: missing required signature

#22 2020-12-27 03:23:49

Re: pacman -- error: linux: missing required signature

Board footer