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

[Eli Schwartz]

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 
> <jerome at leclan.ch> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20190228/856f36a5/attachment.sig>