[aur-general] Trusted user application: Drew DeVault

[alad]

Am 27.02.2019 um 02:30 schrieb 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 tend to decide on whether to support an application or not at the end
of the discussion, not before it. (Applicants positively responding to
PKGBUILD reviews typically win my favor, so that's a start.)
>
>> 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.

I think it would be a good idea to make such a trust system explicit.
See for example [6], [7], [8]. But yes, I guess the service can be used
strictly to test some given AUR packages, rather than their installation
or distribution.

[6] https://xyne.archlinux.ca/projects/bauerbill/
[7] https://github.com/alexheretic/aurto
[8] https://github.com/seblu/aurbot

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20190227/7f0e6433/attachment-0001.sig>