Forgive me if I'm mistaken, but I think the linked RFC applies to the official Arch Linux repositories, not to the AUR. The official repositories, unlike the AUR, are curated by trusted package maintainers who would presumably vet any PGP keys before importing them into VCS. If you trust the official package maintainers, you can by extension trust the PGP keys they pull into VCS.

By contrast, AUR packages are explicitly unsupported and left to the user to review before building and installing. The mere presence of a PGP key alongside the PKGBUILD does not necessarily mean you should trust that PGP key to sign the sources - as others have pointed out, you should always check upstream for which key(s) is supposed to be signing the sources. If upstream doesn't state anywhere what keys are used, then it doesn't help if keys are shipped with the PKGBUILD, because there's no way to know if it's the right ones.

However I do agree that shipping keys alongside the PKGBUILD can make it easier to import the key once you know which key you need. All you really need from upstream is the expected key fingerprint; once you have that you can import the key from anywhere as long as you verify that the key has the expected fingerprint. Similarly, you could choose to simply review the downloaded sources and, once you're confident that they're not malicious, accept the key as trusted for future package updates. For example, yay [1] makes it easy to review only the diff of new PKGBUILD versions, so as long as the validpgpkeys and signature sources don't change you can be confident that the sources are still from the same developer that you chose to trust.

[1]: https://aur.archlinux.org/packages/yay

/Emil

However this is all listed within the RFC. 

Thanks @Polarian. That RFC didn't occur to me.

--
Best Regards,
Abraham
Sent with Tutanota; https://tuta.com