[aur-general] Trusted user application: Drew DeVault
alad at archlinux.org
Wed Feb 27 01:09:46 UTC 2019
Am 25.02.2019 um 00:24 schrieb Drew DeVault via aur-general:
> Hiya! Jerome convinced me to finally apply for TU, and Sven-Hendrik
> agreed to co-sponsor my application (both Cc'd).
> I'm a generalist that works on free software full time. I maintain the
> following AUR packages:
Considering some recent issues regarding team behavior  in Arch, I'm
going to have to ask on some of your previous interactions with the
community, and open-source in general. I had two examples in particular,
the MineTest community , and interaction with other Arch users on
By definition, a TU has to interact with users of community packages
(bug reports, emails, coordination with the rest of the Arch team, ...),
and users of the AUR in general (AUR requests, peace-keeping,
interactions with previous maintainers when promoting packages, ...).
This means that if aggressive behavior such as the above is part of some
general theme, there is a clear problematic.
Note that this is _not_ meant as a witch-hunt of any sort - nor do I
have any kind of personal involvement here. I do however value healthy
communication in the Arch community, and believe any TU candidate should
value it as well.
> I also maintain a third-party Arch repo and oversee some automation for
> helping to build and publish new packages:
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".  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.
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.  I guess this is "fixed" now, but it leaves a bad taste
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: OpenPGP digital signature
More information about the aur-general