[aur-general] Trusted user application: Drew DeVault

[Drew DeVault]

On 2019-02-27  2:09 AM, alad via aur-general wrote:
> [2] https://news.ycombinator.com/item?id=18156980

I said my piece in the thread and I encourage anyone concerned to read
through the comments here. For what it's worth, the concerns are over
incidents which occured 4-5 years ago.

> [3] https://wiki.archlinux.org/index.php?title=XDG_Base_Directory&diff=prev&oldid=391411

To add some context which is missing here, the editor here followed me
from GitHub to IRC to the Arch wiki to make a stink over XDG support in
a project which was, at the time, 13 days old. This edit was made at the
height of the argument and I regret the rude message I left there.

I have often been a jerk in the past, but I recognize the problem and
sought support from friends and family. I believe that I have improved
significantly in the past few years. I understand if your concerns
prevent you from supporting my TU application, though. No hard feelings.

> 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.

I trust my users to understand the risks of the AUR and make educated
decisions when using this tool. I personally utilize the AUR in some of
my builds on this service, but only with packages maintained by myself
or people I trust - or with no sensitive information at risk. Builds
with sensitive information (which are recorded in a way that gives me
data-driven insights) are actually in the minority on builds.sr.ht, and
builds with both secrets and AUR packages are exceptionally rare. In
most cases, the worst a bad AUR package could do is give you a false
negative/positive on your test suite.

> 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.

It is fixed, no quotes needed :) the AUR rate limit is pretty agressive
and there was no service disruption caused by my mistake.