[Resolved, probably] pacman -S vs -U signature validation behavior

jernst · 2026-05-19 18:30:15

I have a self-signed package in my own repo.

When I attempt to install it with "pacman -S foo", I get

File /var/cache/pacman/pkg/foo-1-1-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).

If I say "no" on whether to delete the file, and then say: "pacman -U /var/cache/pacman/pkg/foo-1-1-any.pkg.tar.zst" it installs just fine.

My pacman.conf has:

SigLevel           = Required TrustedOnly
LocalFileSigLevel  = Required TrustedOnly
RemoteFileSigLevel = Required TrustedOnly

Is the signature verification algorithm somehow different between -S and -U? Why does it work in one case but not the other? Or what am I not understanding here?

Last edited by jernst (Yesterday 20:58:59)

seth · 2026-05-19 19:13:21

Is the sig file there, what's the trust level of the relevant key? Did you import it in the pacman keyring?

WorMzy · 2026-05-19 19:20:24

Mod note: Moving to Pacman issues.

jernst · 2026-05-19 19:47:09

There's a sig file, which is valid according to "gpg --verify".

The trust level of the key shouldn't really matter if all I'm interested in is why the behavior appears to be different between -S and -U?

But the key that goes with the signature has trust level "ultimate" in GNUPGHOME=/etc/pacman.d/gnupg.

One more tidbit: This package file was originally packaged and signed by user1. Then a new signature file was created by user2 without a rebuild, so user1 is still listed as the packager in the .PKGINFO. The downloaded signature files is the new one from user2, which is the one with "ultimate" trust". Turns out when pacman -S fails to install, the error message about the invalid signature refers to user1, not user2. user1 is not in the gpg database. (Yes, I triple checked that I'm not accidentially referring to the old signature file. Wouldn't explain the difference in behavior anyway.)

Why does user1 even play a role here with respect to signature verification?

seth · 2026-05-19 19:52:43

all I'm interested in is why the behavior appears to be different between -S and -U?

https://man.archlinux.org/man/pacman.8
https://wiki.archlinux.org/title/Pacman
pacman --help

-S syncs a repo, -U upgrades a package from any URL and will not use signatures at all, it's commonly used to install locally build packages.

jernst · 2026-05-19 20:11:34

I don't think that's accurate.

man pacman.conf says:

LocalFileSigLevel = ...
Set the signature verification level for installing packages using the "-U" operation on a local file. Uses the value from SigLevel as the default.

see my settings above.

seth · 2026-05-19 20:17:05

pacman-conf
strace pacman -U /var/cache/pacman/pkg/foo-1-1-any.pkg.tar.zst |& grep sig

Edit: reading up your user1 and user2 situation that's probably the key difference here - the url oriented approach will prefer the signature file and not care about the orignator… gonna check pacman code.

Edit #2: shredding the signature in the cache (echo foo > ….sig) kills -U, -S doesn't care at all

Last edited by seth (2026-05-19 21:20:34)

seth · 2026-05-19 21:31:18

https://gitlab.archlinux.org/pacman/pac … heads#L522

 * Check the PGP signature for the given file path.
 * If base64_sig is provided, it will be used as the signature data after
 * decoding. If base64_sig is NULL, expect a signature file next to path
 * (e.g. "%s.sig").

The signature file is irrelevant in the -S case since base64_sig isn't null

Scimmia · 2026-05-19 23:08:45

What is the FULL error? You only posted the last part of it.

seth · 2026-05-20 06:17:12

The OP locally signed the package w/ a detached signtaure and a key that's in trusted by the pacman keyring.
That signature is preferred and used for -U, but for -S and a local repo pacman uses the base64 signature and completely ignores the (existing) detached signature.
The base64 signature is from a different key the OP has confirmed no to be in the keyring.

The behavior can be traced in --debug and is arguably somewhat inconsistent. pacman could prefer the base64 signature and use a detached signature in all cases as fallback also if the base64 signature cannot be verified.

jernst · Yesterday 04:00:50

I think I found it.

The repo file (*.db.tar.*) **may** contain an entry %GPGSIG% for the package. If it contains that, pacman -S will use that signature, and not the detached signature. While pacman -U always uses the detached signature.

However, if I create a new repo file, such an entry does not exist, and pacman -S will use the detached signature.

This would explain why:
* when I take the package and detached signature, create a new repo with it, the package installs just fine with pacman -S (that new repo file does not contain %GPGSIG%)
* when I use the "old" repo file to which the package had been added with the previous signature, and then re-add it with a new signature, pacman -S complains about the old signature (it contains the old %GPGSIG% which is apparently used)

(This may be an alternate description of what seth described in comment #10 -- maybe?)

Does this sound plausible?

Arch Linux

#1 2026-05-19 18:30:15

[Resolved, probably] pacman -S vs -U signature validation behavior

#2 2026-05-19 19:13:21

Re: [Resolved, probably] pacman -S vs -U signature validation behavior

#3 2026-05-19 19:20:24

Re: [Resolved, probably] pacman -S vs -U signature validation behavior

#4 2026-05-19 19:47:09

Re: [Resolved, probably] pacman -S vs -U signature validation behavior

#5 2026-05-19 19:52:43

Re: [Resolved, probably] pacman -S vs -U signature validation behavior

#6 2026-05-19 20:11:34

Re: [Resolved, probably] pacman -S vs -U signature validation behavior

#7 2026-05-19 20:17:05

Re: [Resolved, probably] pacman -S vs -U signature validation behavior

#8 2026-05-19 21:31:18

Re: [Resolved, probably] pacman -S vs -U signature validation behavior

#9 2026-05-19 23:08:45

Re: [Resolved, probably] pacman -S vs -U signature validation behavior

#10 2026-05-20 06:17:12

Re: [Resolved, probably] pacman -S vs -U signature validation behavior

#11 Yesterday 04:00:50

Re: [Resolved, probably] pacman -S vs -U signature validation behavior

Board footer