On 6/29/26 8:42 PM, Sean E. Russell wrote:
Yes; my intention is not to provide a solution for AUR; merely to do what _I_
can, for the projects _I_ maintain, using the mechanisms that pacman already
provides, until such time as a better solution is available. I understand that
if I go down this route, users will not be able to install the packages I've
added `validpgpkeys` to unless they import (and trust?) my key. Having done so,
and assuming I can get my key signed by a more official entity, then diligent
users will be able to import my key and validate the web-of-trust, and then have
a bit more confidence that those packages I maintain are trustworthy.
The validpgpkeys= feature in pacman helps when:
- the server hosting the source code is compromised (github - either the account
or the platform, some forgejo instance, some webserver, ...)
- the public key is more well-known than the project url for some reason
but that's about it. Neither of them were relevant in the AUR attack. It doesn't
make your software or PKGBUILD more trustworthy.
With it, we are not able to distinguish what artifact type (e.g. package files,
installation media, repository metadata) a signature created by an OpenPGP
private key should be used for and in what context (e.g. core repository, extra
repository, custom repository) it is supposed to be valid in.
The presence of `validpgpkeys` (https://wiki.archlinux.org/title/PKGBUILD ß7.3)
and the fact that `makepkg` recognizes `.sig` sources (ß7.1) provides a trust
mechanism which is not widely used but still available. I just tried an
experiment, and it works as documented for AUR packages, using keys in the
user's keyring. For packaging, it requires only `validpgpkeys` and a `.sig`
source.
I think this goes in the direction of pgp being used for "I signature this" with
unclear intent and what this is meant to imply. That I authored it? That I
reviewed it? That I compiled it? That I want to submit it into the Debian Source
code archive?
I issued thousands of signatures at this point, with very different semantics,
yet *cryptographically* my Debian uploads are valid Arch Linux packages and
vice-versa (since the same key is in both keyrings), the only line of defense is
the tar parser rejecting Debian .changes files as invalid archives, and my
signed upstream source code releases lack the metadata files pacman is looking for.
In addition to the additional burden on users (to import and verify the WoT), it
doesn't address the most recent supply chain attacks, where abandoned packages
are hijacked. I think it's better than nothing, until a better solution is
available.
validpgpkeys= would not prevent tampering of build instructions.
---
fwiw, there's a website allowing you to explore this approach, e.g. this is the
"homepage" of the multi-precision integer that is allowed to issue nmap releases
(according to Arch Linux):
https://sig.exchange/issuer/436d66ab9a798425fda0e3f801af9f036b9355d0
There's very limited conclusions you can draw from this however. The most
significant conclusion is problably "Arch Linux seems to trust this key to issue
nmap releases", but if you care what Arch Linux thinks the source code of nmap
is, you might as well just use our sha256sums=.
cheers,
kpcyrd
