Hi, Wilhelm I'm also using arch podman containers on an alpine host to build my packages, although using the traditional way by using makepkg and not an aur helper. The building process has been somehow automated by a script, which just runs some makepkg commands inside the arch-container. I did sometime encounter the same problem as that user who requested this change from you. Dropping the PGP-key check is clearly not an option, while having the user set the option --skippgpcheck is also not a good idea. Anyway, when I encountered the problem, I just downloaded the key manually, put it in the same directory where the PKGBUILD lied and imported it via `gpg --import *.asc` and built the package manually using an interactive container. But I see a use-case, if packages should get compiled automatically e.g. via cronjob. Then you don't want to babysit the compilation process and just let it do it's job.
However, if the users relies on the key included with the package, then I could use my own malicious key, so the user should compare the key with upstream sources anyway.
If you would ship your malicious key and the original source provides a .sig file, signed by the original key, then the compilation should fail, since the original key is not imported in the system. (afaik) If that ends up in forking the project, modifying the source and having a different source-url with the malicious content, than it's clearly the users problem, which just blindly accepts the PKGBUILD, even if it does any unwanted stuff. In my years of using Arch, that's one lesson I've learned... the hard way. I do see an advantage however in compiling inside a chroot/container. It's volatile and you don't run the chance to compromise your system with a malicious key. Only the chroot/container, which would be deleted after the package has been built. Container can be useful, if the host-system is not arch, (e.g. me with alpine). Cheers LinuxSquare