Thanks for the reply Abraham! On 2024-02-10 21:10, Abraham S.A.H. wrote:
It's always possible for a package maintainer to act maliciously, in both cases! You can edit the main source code, and upload it anywhere. Calculate its digest. Sign it with your own malicious key and upload your public key to keyservers. Then in your PKGBUILD, you put the address of your own uploaded source code to be fetched, its previously calculated hash to be checked and finally the fingerprint of your own malicious key to be retrieved from keyserver. Or simply include the PGP public key file alongside the PKGBUILD.
Maybe I'm missing something, but with the way makepkg works, it should (in theory) prevent a packager from sneaking in a malicious signature. In the presence of a validpgpkeys() array, makepkg checks the user keyring for the public key and simply errors out. There is no automation for fetching the key. It is on the package builder to manually retrieve the correct key. Proper diligence includes checking with *upstream sources* for published keys. That means not taking the validpgpkeys() value at face value and in that scenario the packager wouldn't be able to use a malicious key. Trusting the validpgpkeys() value in the PKGBUILD and just straight up importing the listed key(s) from the public keyservers seems the same as building with `--skippgpcheck` to me, at least as a downstream consumer of an AUR package. validpgpkeys() is still valid for the packager themselves for verifying that the upstream source hasn't been tempered with (ie. server breach for example). Cheers, Wilhelm
