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
