On Mon Jun 29, 2026 at 9:33 AM PDT, David Runge wrote: > it is useful and valuable to have OpenPGP signatures for the payloads (e.g. > your > git tags or tarballs) from which you are building a package with a PKGBUILD. ... > However, it is a separate concern to have OpenPGP signatures for the packages > that you provide in a custom/unofficial package repository for users of Arch > Linux (even though you specifically may be using the same OpenPGP private > key).
Could you clarify this? I think I don't understand the implication here. `makepkg` and `PKGBUILD` provide a facility for verifying signatures on upstream sources for `PKGBUILD`s, and although the feature is almost never used in AUR packages, it works as documented. > This is a complex topic, also for us and the upstreams we are dealing with as > a distribution. > A while back, we attempted to summarize our best practices and requirements > in [RFC0046]. 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. > With pacman we are tied to gnupg and a single, system-wide keyring in the > custom > GnuPG format. `makepkg` appears to use the user's keyring in addition to the system-wide keyring, although I don't know if it'll verify WoT _across_ keyrings. > 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. 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. > In the context of the work on [alpm] we have also worked on [voa], which is a > generic approach to bringing more context into the verification of artifacts > using digital signatures. > We have also written a [blogpost] about it, that illustrates the use for e.g. > custom package repositories. Yes: you're looking at the big picture, and working on a more generic solution with the distribution. That's a bigger fish -- I'm merely trying to do what I can as a peripheral contributor, using the available tools. > Now, this is not going to directly help you with your question, however, it Sure! It's great to read how people are approaching the problem, so thanks for the links. --- SER Sean E. Russell (https://ser1.net) OpMsg: https://ser1.net/.well-known/opmsg.txt GPG key: https://ser1.net/.well-known/pgp.asc Minisign: https://ser1.net/.well-known/minisign.pub Age: age195vpft7nzsy83medxagqqsge0lrcuf9txe3z2znlu2wsk69cdu4sx8nfvp
