Re: [aur-general] Enforcing AUR package quality (was Re: Trusted user application: Drew DeVault)

On 2/28/19 11:22 AM, Daniel M. Capella via aur-general wrote:

On February 28, 2019 8:58:06 AM EST, Jerome Leclanche wrote:

<snip>

...

OT: We should maybe have the AUR lint PKGBUILDs on git push (and reject really bad ones) if we want to improve that situation.

J. Leclanche

I've been thinking enforcing the use of makechrootpkg and namcap on package submission should be introduced, and maybe even on major (and minor?) version bumps for packages following semver.

LMAO no. What part of

I would eagerly welcome any way to reliably do exactly that in an automated fashion, with the caveat that doing so more or less inevitably involves arbitrary code execution -- this is the reason why we in fact do not read the PKGBUILD at all, but created the .SRCINFO instead.

was not clear? We are not introducing arbitrary remote code execution by building all AUR packages before accepting them for upload? Furthermore if we were going to do this, we might as well host the binary results and not bother with this whole "AUR" thing at all.

Inb4 yes I'm aware of the number of false-positives in namcap.

If you explicitly state you're aware of the exact, in-depth reason why this is completely a no-go from the start, then... why did you say anything? In case it wasn't obvious... namcap is an interactive review tool and completely unsuitable for automated judgment of *anything*. I also severely dislike the idea of enforcing ridiculous and inescapable restrictions *for any reason* on users who are doing nothing wrong, which most "namcap is God" victims will be. In summary, I am putting on my aurweb maintainer hat and saying "no, we shall not enforce any such thing". Further emails in this irrelevant tangent subthread derail of the TU application process are not necessary and I shall not bother responding to them, or reading further. -- Eli Schwartz Bug Wrangler and Trusted User