Am 27.02.2019 um 02:17 schrieb Jerome Leclanche:
On Wed, Feb 27, 2019 at 2:10 AM alad via aur-general <aur-general@archlinux.org> wrote:
I haven't read all the documentation for this project, but noticed some oddities. Your build service appears to build AUR packages in full automation using "yay -Syu --noconfirm". [4] While I'm sure you took the necesseary precautions to protect your _servers_ from arbitrary code execution, users are still at risk.
For example, even when the build happens on your server, the .install file contains arbitrary code, which is run by pacman as root, on installation of the built package on the user's host. And it's unlikely a user will extract a .pkg.tar.xz, just to verify that the .install file does nothing strange. Sorry for jumping in here but that feels like a discussion about the merits of idempotent and declarative package management more than a discussion about TU practices. The security and technical concerns for CI/build services are different to end-user desktops…
Drew has made some suggestions about handling of packages/dbscripts in the official repositories before (the reference to which is now unfortunately deleted). As such the way he deals with CI is definitely something I'm interested in. Most importantly, a TU represents the AUR and any good practices accompanying it. A project which encourages users to install AUR packages without inspection is definitely not a good practice. For the record: I don't dismiss the idea of some "build service" for AUR off-hand. It's that the concerns for users should be well-regarded - after all, the "U" in AUR stands for "User".
Not to mention how your service hit the AUR rate limit, due to the choice of the one (from 18!) AUR helpers inefficient enough to cause this. [5] I guess this is "fixed" now, but it leaves a bad taste nonetheless. I'm curious why a user/developer reaching out about an issue leaves a bad taste.
Here I didn't mean the reaching out, but how it makes the whole idea look like an after-thought. In the vein of, "I want AUR for my build service, so let's run this popular command for building AUR packages automatically". I may be more sensitive to this particular point though, since I've dealt more with AUR helpers than most. :)
J. Leclanche