On 2019-02-24 7:01 PM, Eli Schwartz via aur-general wrote:

Your application sounds interesting and I generally admire your open-source work.

Thank you!

What is samurai, exactly? It claims to be "a ninja-compatible build tool" but I'm not sure what the comparative advantages are supposed to be. (Aside: If I wanted another build tool rewrite, it would probably be meson because it would actually be super interesting to have a meson generator that could be used for bootstrapping an OS without requiring python as a prerequisite.)

Aye, I have the same opinion about Meson. Ninja is written in C++, which is easier to port, but I similarly don't like and isn't invited to my dream OS bootstrapping party. Samurai is the simpler of the two components to replace in C, so I see it as the first step towards correcting Meson's Python problem.

Personally I don't think that even Meson is the end-all be-all of build systems, but it's definitely the best to come so far, so if I ever get around to replacing it with something written in C I will probably take a lot of its ideas but not attempt to be compatible.

What are your thoughts on things like https://todo.sr.ht/%7Esircmpwn/scdoc/17 As you've mentioned scdoc, I recollect that it builds statically against libc, and ("by design") does not respect the makepkg.conf LDFLAGS -- we currently override this: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packa...

Sometimes I'm an opinionated upstream, but it's (usually) my right to be. I'm not an opinionated downstream, because it isn't my right to be. I won't push my personal opinions about software into the packages or make packages which rock the boat. Opinions as big as LDFLAGS aside, if I have any novel ideas I'll put them to the community and seek consensus first.

But you can still expect me to be an annoying upstream from time to time :)

P.S. You pointed out on IRC that my first email wasn't signed, so I signed this one to be sure.

On Sun, Feb 24, 2019 at 06:40:13PM -0700, Brett Cornwall via aur-general wrote:

Here's a PKGBUILD review:

Some additional points!

## madonctl

* This package needs to drop `go get` as we have vendored deps.

## python-activipy-git

* "v" should be removed from the pkgver as we are dealing with versioned tags.

## vgo-git

* This package has support for go modules. So it can drop all of the voodoo it is currently doing.

## python-asyncio_redis * I'm a bit unsure what 2 clause BSD is traditionally called. But it's not `2 clause BSD`. After some searching from the repos it seems like `BSD` should be enough(?)

Also want to stress the lack of MIT license being places in `/usr/share/licenses/`, along with source not currently enforcing shared SRCDEST as Brett pointerd out.

Else the review from Brett seems decent :) Great work.

Thanks for all the feedback! I went through and cleaned up all of my AUR packages - something a wiser man would have done before submitting the TU application.

Note that in some cases I disowned packages I was no longer interested in maintaining, and in the case of vgo both disowned and filed a deletion request; rather than normalize the PKGBUILDs.

On 2019-02-24 6:40 PM, Brett Cornwall wrote:

I must jokingly admit that my first instinct is to vote against your application so that you'd spend more time on wlroots and Sway. You're not allowed to work on anything else, slave!

Hehe, don't worry, this wouldn't be much more work than I already take on for Arch Linux - it'd just be formalizing that relationship.

• Prefer sha256sums over sha1sums and md5sums
• "$srcdir" can often be omitted as the PKGBUILD functions all begin in "$srcdir" already - this will make PKGBUILDs much more readable
• MIT-licensed packages are not installing their licenses.
• i386/i686 architectures should be removed.
• update python-distribute makedeps to python-setuptools
• source= lines should save sources to a "$pkgname-$pkgver.tar.gz" file
• Python distutil packages should be built and packaged separately [3]:
• python-spam-blocklists - fill that depends() list, I'm sure it needs something.

Fixed on all counts.

## python-flask-markdown, python-haxor

• source has https, so use it!

Fixed - I normalized all of my Python package's source URLs to the pypi source, using variable substitution to rejigger the names.

On 2019-02-25 9:46 AM, Morten Linderud via aur-general wrote:

## python-asyncio_redis

• I'm a bit unsure what 2 clause BSD is traditionally called. But it's not `2 clause BSD`. After some searching from the repos it seems like `BSD` should be enough(?)

Updated to use the SPDX identifier.

Also want to stress the lack of MIT license being places in `/usr/share/licenses/`, along with source not currently enforcing shared SRCDEST as Brett pointerd out.

Fixed this everywhere I found it.

On 2019-02-25 9:58 AM, Levente Polyak via aur-general wrote:

Your build script on the CI does not produce reproducible packages as it uses a own simple wrapper to call makepkg. F.e. If there is no SOURCE_DATE_EPOCH defined to now or the value already passed it does not create uniform mtimes.

Filed a ticket to address this at a later date:

https://todo.sr.ht/~sircmpwn/sr.ht/165

This shouldn't be an issue for community, though.

Out of curiosity, what kind of upstream watch are you using to be made aware of new releases?

For the AUR I don't keep up with upstream releases, I just wait for someone to mark the package as outdated. For Alpine Linux I use a combination of subscribing to the upstream -announce mailing list and subscribing to GitHub releases as appropriate; would do something similar for Arch Linux community.

Vgo-git should use go-pie as makedepends like all packages that work

I dropped vgo, but fixed this for my other Go-based packages.

None of your python packages, neither in aur nor in your repo build CI are running any unit tests while most of them provide tests upstream.

Fixed in many places in my AUR packages. Will do this for sr.ht-pkgbuilds later:

https://todo.sr.ht/~sircmpwn/sr.ht/167

On 2019-02-28 2:22 AM, Levente Polyak via aur-general wrote:

...

For the AUR I don't keep up with upstream releases, I just wait for someone to mark the package as outdated. For Alpine Linux I use a combination of subscribing to the upstream -announce mailing list and subscribing to GitHub releases as appropriate; would do something similar for Arch Linux community.

Well, to be honest its the maintainers responsibility to keep track of upstream and not outsource out of date flagging to someone else. There is no difference between [community] and AUR for something that is a maintainer responsibility.

I respectfully disagree. The barrier to entry for the AUR is almost nonexistent and there's no expectation of support or quality - from Arch Linux or from the maintainers. I take some degree of personal pride in having nice AUR packages, but I also have a limited amount of time. Of course, I take my responsibility as maintainer much more seriously when working with packages in official repos.

Really no offense, but I really had high expectations and got very surprised: At some point I started wondering if you read error and log output while trying to package or run tests? Some of this findings indicates you don't (when you change some stuff) or at least stop any investigation if f.e. a test suite doesn't run straight. I would like to see more investigative behavior of a maintainer in getting things sorted out the correct way instead of just abandon if it requires a bit of patience and thinking plus time.

Also i encountered some examples of non working pkg build of very recent changes that make me think changes are pushed straight to the AUR before any build/test ever happened.

If there is stuff to rule out and you need ideas and another pair of eyes, just ask for it... that's what a team and a community should be for, nobody knows everything. Also some of the packages don't work as they are not python 3.7 compatible at all so i wonder if anyone uses them a all?

Hmm, sorry to disappoint. I definitely built and did at least a basic sanity test on every package. I did update a whole bunch of packages at once, so it's possible I missed a few things... many of which I presume are the problems you pointed out.

Also, note that I haven't yet taken the time to clean up my sr.ht-pkgbuilds packages, if you were reviewing those. Many of those are also adoptions from the AUR where I imported someone else's package so I could build a binary package - and left their PKGBUILD intact to make pulling down updates easier. Might rethink that policy.

Also i noticed you may maybe not know 'namcap' because of so many missing licenses plus stuff like Non-FHS man page violations.

Aye, this is first I've heard of namcap. Is there a reason that this isn't included with makepkg by default?

I updated several of the packages you mentioned to address your feedback, and ran namcap on them. Can you take another look when you have time?

Regarding your Python feedback in particular, I appreciate the tips - I have a lot of Python packages I need to make but have found resources for making Arch Linux packages for Python software to be somewhat lacking. I put a note on my todo list to take the feedback on these AUR packages and summarize them for the Arch Wiki.

https://wiki.archlinux.org/index.php/Python_package_guidelines

patchrom mktiupgrade mkrom kpack genkfs

• Non-FHS man page in /usr/man/man1

I could fix this in the package, but this is an upstream bug, so I filed a ticket... on my own project.

https://github.com/KnightOS/KnightOS/issues/381

sass:

• did you test building this package before pushing an added LICENSE dist line 2 days ago? Because this indicates something went wrong: install: cannot stat 'LICENSE': No such file or directory ==> ERROR: A failure occurred in package().

Ah, I had thought I did, but it seems I only tested scas. sass is legacy software, and scas is its replacement. I think I just got mixed up.

• do you use proper clean environments for building? asking because: ==> ERROR: A failure occurred in build(). ModuleNotFoundError: No module named 'setuptools'et This packages requires setuptools makedepends doesn't your CI or AUR testing use clean/isolated and non polluted environments for building?

My CI uses fresh build environments, but my AUR packages aren't built with it. Just finished setting up makechrootpkg so I can do this locally.

Btw: please use github sources, the pypi re-distribution doesn't contain any tests in the first place

Damn, I was really happy to have a consistent sources URL I could reuse for Python packages.

python-spam-blocklists: nice indicator: Latest commit on Jun 15, 2012, this stuff is just dead, nuke

Agreed, and I don't even remember what I needed this for. Filed a deletion request.

python-pystache:

• there is a test runner using python ./test_pystache.py which pretty much shows this is dead non working stuff as well: File "/build/python-pystache/src/pystache-0.5.4/pystache/parser.py", line 15 NON_BLANK_RE = re.compile(ur'^(.)', re.M) SyntaxError: invalid syntax Latest commit 17a5dfd on Sep 30, 2014

It may be abandoned but I actually do remember why I need this package - and I still do. The test suite runs on Python 3 but you have to jump through some hoops - setup.py runs the whole codebase through 2to3 before installing. Jumped through said hoops and updated the package.

python-lark:

• "# upstream tests fail due to path resolution errors" what exactly do you mean by that? If you investiate the files trying to be processed you would notice that they are not distributed in the pypi processed files. Taking a look at the sources you would notice they use a submodule to get the grammer from, if we get them and invoke the tests as upstream does in travis (python -m tests) you get: OK Ran 352 tests in 28.259s

I'm impressed with your build hardware. I thought I was on a nice machine here, but I'm 10 minutes in and on 79/416. My PKGBUILD is attached if you're curious.

I have an early flight to catch and I'd better pack & sleep, so I'll have to fix up the rest later. These are the ones I have left:

- python-haxor: - python-asyncio_redis: - python-asif: - samurai: - synapse-bt-git: - mako-git: - scas: - z80e: - koio: - madonctl:

Thanks!

On 2019-02-27 10:42 PM, Eli Schwartz via aur-general wrote:

I guess the difference between PyPI and Github sources could be clarified, but really I'd much rather upstreams would get in the habit of using a MANIFEST.in which ensured the license and testsuite was correctly included in the source dist.

This is the main bit that I feel can be clarified. The wiki page today is written like there's One True Way to specify sources=() for a Python package, and that way has some serious defects (lack of tests, license file, etc) - to the point where if you can get the package another way, you probably should.

From: Drew DeVault via aur-general aur-general@archlinux.org Sent: Thu Feb 28 04:25:10 CET 2019 To: Discussion about the Arch User Repository (AUR) aur-general@archlinux.org Cc: Drew DeVault sir@cmpwn.com Subject: Re: [aur-general] Trusted user application: Drew DeVault

On 2019-02-28 2:22 AM, Levente Polyak via aur-general wrote:

...

...

For the AUR I don't keep up with upstream releases, I just wait for someone to mark the package as outdated. For Alpine Linux I use a combination of subscribing to the upstream -announce mailing list and subscribing to GitHub releases as appropriate; would do something similar for Arch Linux community.

Well, to be honest its the maintainers responsibility to keep track of upstream and not outsource out of date flagging to someone else. There is no difference between [community] and AUR for something that is a maintainer responsibility.

I respectfully disagree. The barrier to entry for the AUR is almost nonexistent and there's no expectation of support or quality - from Arch Linux or from the maintainers. I take some degree of personal pride in having nice AUR packages, but I also have a limited amount of time. Of course, I take my responsibility as maintainer much more seriously when working with packages in official repos.

From TU candidates there is very high expectation of support and quality and AUR

is the place where they can prove it. If the lack of time is a problem then it will still be a problem after promotion. Saying that you will treat your maintainer work seriously only after you get promoted doesn't earn you much trust.

Yours sincerely

G. K.

On Thu, Feb 28, 2019 at 12:51 PM Josef Miegl josef@miegl.cz wrote:

Although I don't have high expectations when dealing with AUR packages, it is absolutely the maintainers job to keep track of upstream updates. This mindset is probably the reason why there is so much out of date stuff on the AUR. It strikes me that a maintainer who doesn't keep track of his own packages wants to become a TU.

No, it is not, and please don't expect this of volunteers. The responsibility goes as far as security (being made aware ASAP of security issues in packages), but knowing in general when a release happens is not (and/or shouldn't be) the TU's responsibility. Most TUs do know when a release happens in at least a portion of their packages, by nature of often maintaining packages they have some working relationship with. But the flagging system is very useful in crowdsourcing the non-security-sensitive portion of package maintenance.

As for being frustrated with the OOD packages on the AUR, I encourage you to make use of the flagging system yourself. It's present there as well. And if you think you can do better than the package's maintainer, ask to co-maintain it, or adopt it if it's abandoned. And in the mean time, you get to be able to download the PKGBUILD and modify it to your liking, that's the whole point of that system. If this sounds pointed, that's because I'm not amused by this idea that anyone who puts a package on the AUR should be at the service of those who download it. Arch philosophy goes above and beyond to drive in people's heads that the AUR is unsupported, to the point of rejecting any AUR helper in official packages. Expectations should be set accordingly.

On Thu, Feb 28, 2019 at 2:16 PM alad via aur-general aur-general@archlinux.org wrote:

Generally, while expectations are naturally not as high as with community packages, lacking quality of PKGBUILDs in AUR remains problematic when trying to promote AUR packages to community. Due to this, a complete rewrite of the PKGBUILD is usually required, rather than making some minor adjustments.

https://lists.archlinux.org/pipermail/aur-general/2016-October/032845.html

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

On Thu, Feb 28, 2019 at 3:26 PM Levente Polyak via aur-general aur-general@archlinux.org wrote:

On 2/28/19 2:58 PM, Jerome Leclanche wrote:

...

On Thu, Feb 28, 2019 at 12:51 PM Josef Miegl josef@miegl.cz wrote:

...

Although I don't have high expectations when dealing with AUR packages, it is absolutely the maintainers job to keep track of upstream updates. This mindset is probably the reason why there is so much out of date stuff on the AUR. It strikes me that a maintainer who doesn't keep track of his own packages wants to become a TU.

No, it is not, and please don't expect this of volunteers. The responsibility goes as far as security (being made aware ASAP of security issues in packages), but knowing in general when a release happens is not (and/or shouldn't be) the TU's responsibility. Most TUs do know when a release happens in at least a portion of their packages, by nature of often maintaining packages they have some working relationship with. But the flagging system is very useful in crowdsourcing the non-security-sensitive portion of package maintenance.

I very strongly disagree on this, nobody forces a volunteer to _maintain_ a certain package, but If it is chosen by choice then keeping it up to date is a responsibility as well. As long as we do not have an automatic system in place it is one of the responsibilities to track it as good as possible! This doesn't make the out-of-date flag system non-useful, even when we would have our automatic flagging system in place, as it could slip through the radar or tracking like upstream may change the location for future releases. I frankly don't like the habit of "i don't give a darn to track, someone will flag it", this is bad practice, and the best we could agree on is that we strongly disagree.

sincerely, Levente

We have TUs with hundreds of packages. Beyond automatic checks, do you really expect they keep up with every single release? I've myself updated several packages that were out of date (and unflagged) in [community]. I'm not saying the attitude *should* be "I don't give a damn", but in practice, I don't believe this expectation you mention is in place (and moreover, I reiterate that I do not think there should be such an expectation when it can very efficiently be offloaded to scripts and users).

J. Leclanche

On Thu, Feb 28, 2019 at 3:36 PM Levente Polyak via aur-general aur-general@archlinux.org wrote:

On 2/28/19 3:33 PM, Jerome Leclanche wrote:

...

We have TUs with hundreds of packages. Beyond automatic checks, do you really expect they keep up with every single release? I've myself updated several packages that were out of date (and unflagged) in [community]. I'm not saying the attitude *should* be "I don't give a damn", but in practice, I don't believe this expectation you mention is in place (and moreover, I reiterate that I do not think there should be such an expectation when it can very efficiently be offloaded to scripts and users).

J. Leclanche

Indeed I am, there are tools like urlwatch, nvchecker and other to easily get diffs of what changed and those are in the responsibility of the maintainer to be aware of until our automatic system spec is not finished and finalized.

TL;DR: yes, i do.

sincerely, Levente

Those are "automatic checks". I'm not sure what you're getting at. If they fail for whatever reason, your packages will still be out of date; I highly doubt you also manually keep up with all of them.

J. Leclanche

On 2/28/19 9:26 AM, Levente Polyak via aur-general wrote:

On 2/28/19 2:58 PM, Jerome Leclanche wrote:

...

On Thu, Feb 28, 2019 at 12:51 PM Josef Miegl josef@miegl.cz wrote:

...

Although I don't have high expectations when dealing with AUR packages, it is absolutely the maintainers job to keep track of upstream updates. This mindset is probably the reason why there is so much out of date stuff on the AUR. It strikes me that a maintainer who doesn't keep track of his own packages wants to become a TU.

No, it is not, and please don't expect this of volunteers. The responsibility goes as far as security (being made aware ASAP of security issues in packages), but knowing in general when a release happens is not (and/or shouldn't be) the TU's responsibility. Most TUs do know when a release happens in at least a portion of their packages, by nature of often maintaining packages they have some working relationship with. But the flagging system is very useful in crowdsourcing the non-security-sensitive portion of package maintenance.

I very strongly disagree on this, nobody forces a volunteer to _maintain_ a certain package, but If it is chosen by choice then keeping it up to date is a responsibility as well. As long as we do not have an automatic system in place it is one of the responsibilities to track it as good as possible! This doesn't make the out-of-date flag system non-useful, even when we would have our automatic flagging system in place, as it could slip through the radar or tracking like upstream may change the location for future releases. I frankly don't like the habit of "i don't give a darn to track, someone will flag it", this is bad practice, and the best we could agree on is that we strongly disagree.

This is indeed the ideal.

Of course even with the flagging system, 412 / 10691 packages are marked out of date.

It is true that over half of these were flagged within the past month.

On Thu, Feb 28, 2019 at 02:58:06PM +0100, Jerome Leclanche wrote:

No, it is not, and please don't expect this of volunteers.

Right, I don't expect that from AUR volunteers, but that doesn't mean the AUR shouldn't be taken seriously. If the maitainer has not interest in updating and seeking out the latest versions of his packages, then the maintainer should just abandon them.

The responsibility goes as far as security (being made aware ASAP of security issues in packages), but knowing in general when a release happens is not (and/or shouldn't be) the TU's responsibility.

Knowing when a release happens shouldn't be the TU's responsibility but making sure that the packages that the TU maintains are relatively up to date should.

If this sounds pointed, that's because I'm not amused by this idea that anyone who puts a package on the AUR should be at the service of those who download it.

That's not what I was trying to say, please forgive my wording skills. Not taking package maintainership seriously when becomming a TU is probably not the best sign of interest. TU's are expected to produce high quality PKGBUILDs and keep them updated. (They are trusted after all)

J. Miegl

On 2/28/19 4:49 PM, Drew DeVault via aur-general wrote:

The AUR is not community. The expectations are higher for trusted users

• hence the trust. Naturally responding to emails, keeping up with new

releases, etc, is part of the role. That's why it's a *role* - it serves to define the responsibilities. There is no role for AUR package maintainer outside of a column in the database. There's no formal process for becoming an AUR package maintainer, and Arch Linux explicitly disavows AUR packages as having any standard of quality. You can't have it both ways - either they're unsupported and maintaining them as such isn't a problem, or they are supported and we have to address that can of worms.

And in my opinion, this represents the AUR working as intended. The low barrier to entry encourages users who may be novices at packaging or have limited time to invest in their package to give it a shot, then other users to download these packages and improve the PKGBUILDs, hopefully sending their improvements back to the maintainer. We already stress that users need to read and evaluate AUR PKGBUILDs for themselves. We should be proud that we have a community which encourages every user to make packages and devote any amount of time they can to supporting them. In short, part of the AUR's value proposition is its fast-and-loose criteria for inclusion and maintenance.

The purpose of community and the trusted user system, as far as I understand, is to provide binary packages from the community that meet a baseline of quality - wholey different from the AUR. Any packages I bring on from the AUR will first be improved to meet these standards, and I commit to a higher degree of responsibility in their maintenance. I also naturally recognize the value in improving my AUR packages and intend to do so over time, but I feel that an approach which is non-committal and less urgent is appropriate here.

I understand the utility in having a history of good AUR packages in evaluating someone's potential as a trusted user. To this end I'm happily incorporating your feedback into improving my AUR packages. I also encourage you to review my history of contributions to Alpine Linux, where I am the maintainer of a number of binary packages and have established a history of quality packages, fast updates, and engagement with the community.

I feel that this thread has devolved considerably into this rabbit hole, even to the point of ad hominem in some replies. I hope that this has explained my opinion more clearly and responded to the criticism. If you still disagree, I think at this point it should just influence your vote rather than continue the argument.

With all the following I'm speaking in general and don't explicitly try to discredit your examples and facts of maintainership but to show why it matters.

The problem here is that the initial trust for someone to be classified as a trusted user does not magically come from the amount of non backed claims of doing everything differently and properly once its about official packages, trust comes from facts and examples. In general its also lot more meaningful or obvious to make a judgement about things in the domain of Arch instead of other distros where the insights are less obvious, which doesn't mean its not a bonus.

An ideal trusted user, who is also responsible for the AUR as a platform, should lead the community by example in terms of behavior and packaging quality. If even our official members don't care because its "just wild west" then how and why should it ever improve?

Or let's make it more dramatic: If the AUR itself should be considered void then a bunch of garbage packages in the AUR plus the claim "but if I'm elected I will only do super high quality shizzle" shall be enough to make a judgement to _trust_ someone doing the right thing?

I'm not saying there is no difference in the official repositories and the AUR, there is! But TUs are responsible to operate the AUR platform and its really a non nice example for others if even the official's of that platform just do it for nothing but "personal pride".

We are not talking about random AUR maintainers, but about someone who wants to be considered a trusted entity of the community and hence it matters to lead by example.

cheers, Levente

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@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. Inb4 yes I'm aware of the number of false-positives in namcap.

-- Best, polyzen

you could get around the namcap false-positives by maybe assigning a "quality score" instead of a pass/fail, with a certain required threshold set.

there aren't really enough data points for a really useful scoring in namcap alone, though, so you'd want to implement other scoring points too. e.g.: - 50 for a successful makechrootpkg - 10 for each namcap test pass - 10 for proper comment per spec[0] (i.e. '#\s*(M|m)aintainer:', etc.)

and anything higher than, i dunno, 70 or 80 is considered pass and below is fail.

or just attach a warning for each namcap failure to the package's info in the AUR.

[0] https://wiki.archlinux.org/index.php/Arch_package_guidelines#PKGBUILD_protot...

On Thu, Feb 28, 2019 at 5:22 PM Daniel M. Capella via aur-general aur-general@archlinux.org wrote:

On February 28, 2019 8:58:06 AM EST, Jerome Leclanche jerome@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. Inb4 yes I'm aware of the number of false-positives in namcap.

-- Best, polyzen

Can we give namcap's outputs error codes and blacklist some of the false positives?

I was mostly thinking about things that can be done just by static analysis of the PKGBUILD, rather than anything requiring packages to be built, so that they can be rejected immediately during git push. Things such as running mksrcinfo, verifying local sources (and their hashes), etc.

J. Leclanche

On 2/28/19 5:41 PM, alad via aur-general wrote:

That's the issue though, how do you do static analysis of a PKGBUILD - a random bash script which should include certain named functions and variables - without executing it? For example, mksrcinfo simply sources the PKGBUILD, i.e. evaluates it in bash.

You can't.

The aura AUR helper has a side-project which tries to check PKGBUILDs for "security issues" in Haskell. I'm not sure how well this approach scales though.

https://github.com/aurapm/aura/blob/master/aura/lib/Aura/Pkgbuild/Security.h...

Please don't even consider "scaling" this approach, as it's based on broken assumptions about bash.

I recall tearing that one apart in #archlinux-aur when the developer was around. Here's a short recap for people seriously thinking this is a solid idea whatsoever:

https://github.com/aurapm/aura/blob/master/aura/lib/Aura/Pkgbuild/Security.h...

All it does is effectively blacklist a couple programs in PKGBUILD contexts.

The ScriptRunning test doesn't actually matter at all, as `eval` and `bash` calls are redundant. `eval $mycode` is the same as `$mycode`

This effectively undermines any of the security checks at all, as you can wrap whatever you're doing in quotes and then deref the variable to defeat any tests.

Here's a thing that will probably not be caught by anything right now, with the payload stored in source=() - which is, due to the nature of url fragments, irrelevant to the rest of the build process: ``` source=('https://coderobe.net/myprogram.tar.gz#ZWNobyBoYXg=') <<< ${source[0]} cut -d'#' -f2 | $(base64 -d) ```

Now that we have established that, to my knowledge, there is no program that is able to statically parse bash in such a way that it can reliably figure out what code is actually executed - or even present at all, i think it becomes clear that any sort of automatic analysis of security - or even just correctness of a given PKGBUILD is futile.

This, plus what has already been said before about the reliability of namcap, should be enough of an indicator that doing this without evaluation is currently effectively impossible. Discussing it here - especially in a (derailed) TU application just leads to bikeshedding and threads long enough to repel anyone that isn't already involved in it.

Aside from that: You can't even automatically figure out the dependencies of a given program. Even ELFs can dlopen() arbitrary libraries at runtime which may or may not be required. A mandatory scoring system of the kind that has been proposed in this thread is anything but a good idea.

On February 28, 2019 11:34:08 AM EST, Jerome Leclanche jerome@leclan.ch wrote:

On Thu, Feb 28, 2019 at 5:22 PM Daniel M. Capella via aur-general aur-general@archlinux.org wrote:

...

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

jerome@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. Inb4 yes I'm aware of the number of false-positives in namcap.

...

-- Best, polyzen

Can we give namcap's outputs error codes and blacklist some of the false positives?

That seems in line with well-established linters. It would also be nice if a linting plugin for an editor (eg. ALE for Vim) could utilize namcap someday.

I was mostly thinking about things that can be done just by static analysis of the PKGBUILD, rather than anything requiring packages to be built, so that they can be rejected immediately during git push. Things such as running mksrcinfo, verifying local sources (and their hashes), etc.

The tool mentioned in alad's reply seems interesting. Will have to check it out.

J. Leclanche

-- Best, polyzen

On February 28, 2019 12:43:02 PM EST, Eli Schwartz via aur-general aur-general@archlinux.org wrote:

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@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?

You misread.

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.

Every single reply you've given my emails since ignoring me on IRC has been as rude and oppressive as this one. As such, again I won't bother with a proper response. Please just treat the mailing lists like IRC and ignore me here as well. Also, grow up.

-- Best, polyzen

Thanks Alad.

Cristiano / nbits

Em sex, 1 de mar de 2019 às 11:12, alad via aur-general < aur-general@archlinux.org> escreveu:

Am 28.02.2019 um 22:40 schrieb Daniel M. Capella via aur-general:

...

On February 28, 2019 12:43:02 PM EST, Eli Schwartz via aur-general <

aur-general@archlinux.org> wrote:

...

...

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

...

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

It's bitter irony how a thread which started out to address questionable behavior ended up in questionable behavior, and not even by the candidate to whom it was addressed to.

...

...

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.

Every single reply you've given my emails since ignoring me on IRC has

been as rude and oppressive as this one. As such, again I won't bother with a proper response. Please just treat the mailing lists like IRC and ignore me here as well. Also, grow up.

How about you two take it off-list. We're interested at the topic at hand, not personal gripes between team (!!!) members.

Alad

...

-- Best, polyzen

Note: your email reminded me to commit to what I had been preparing to do for a while, but was not the reason I withdrew my TU application.

On 2019-03-04 , Levente Polyak via aur-general wrote:

I wanted to poke you how things are going? Would love to see my review being incorporated, it took quite a while to look everything up. This applies to the first batch as well, not just the list you wanted to look up later. For example python-sshpubkeys build issue, the FHS changes and the unit tests from the first batch are not yet in AUR.

I've been travelling since your email came in, and I'm away from my Arch workstation at the moment. I intend to finish working on your feedback when I get home next week.

Hey Christian!

On 2019-02-25 6:21 PM, Christian Rebischke via aur-general wrote:

1. Can you describe in a few sentences how you build your packages for

the AUR and for your own repository?

For the AUR: I just run makepkg -i and makepkg --printsrcinfo > .SRCINFO. I keep it pretty casual for the AUR.

For my own repository: I have a script called pkgkit[0] which automates some of the work. It automatically takes care of things like bumping pkgrel & checksums, common sources of human error. Then I submit it to my CI with this[1] build manifest, which boots up a fresh Arch Linux VM to build the package on, and uploads it to my repo.

[0] https://git.sr.ht/~sircmpwn/sr.ht-pkgbuilds/tree/master/pkgkit [1] https://git.sr.ht/~sircmpwn/sr.ht-pkgbuilds/tree/master/build.yml

2. How do you keep track of updates of upstream software? Do you use a

specific software for it? Which one?

For the AUR I don't keep up with upstream releases, I just wait for someone to mark the package as outdated. For Alpine Linux I use a combination of subscribing to the upstream -announce mailing list and subscribing to GitHub releases as appropriate; would do something similar for Arch Linux community.

3. Do you plan to socialize with the community? If yes: on which

plattforms? If no: why?

Sure, and I already do some. Just on IRC.

4. What do you like about Arch Linux at most? What do you hate about it?

(You can be open here, I will not judge ^___^)

I like that everything is up to date and for the most part Just Werks. I dislike glibc and systemd, but we needn't take that particular flamewar any further than that.

5. Are you willing to attend real-life meetups on conferences like

FrosCon, CCC, etc?

Yep. I met many Arch Linux developers at FOSDEM a few weeks ago.

6. Do you have any experience with security?

This is a pretty broad and open ended question. I suppose my answer is "yes"?

7. A user opens a bug report, where the user reports a security

vulnerability in one of your packages. The security vulnerability is unknown and seems to be a 0-day. How do you react?

I let upstream know about the issue and then hand them the reins. I consider security vulnerability an upstream problem and delegate authority on how to proceed to them. When a fix is available I'll ship it in my Arch package. I'm not really into the whole responsible disclosure aka pressuring upstream into fixing it yesterday kind of approach.

Thats all from me. Thanks for your hard work with sway btw :)

:)

Am 27.02.2019 um 02:17 schrieb Jerome Leclanche:

On Wed, Feb 27, 2019 at 2:10 AM alad via aur-general aur-general@archlinux.org wrote:

...

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.

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.

Sorry for jumping in here but that feels like a discussion about the merits of idempotent and declarative package management more than a discussion about TU practices. The security and technical concerns for CI/build services are different to end-user desktops…

Drew has made some suggestions about handling of packages/dbscripts in the official repositories before (the reference to which is now unfortunately deleted). As such the way he deals with CI is definitely something I'm interested in.

Most importantly, a TU represents the AUR and any good practices accompanying it. A project which encourages users to install AUR packages without inspection is definitely not a good practice.

For the record: I don't dismiss the idea of some "build service" for AUR off-hand. It's that the concerns for users should be well-regarded - after all, the "U" in AUR stands for "User".

...

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.

I'm curious why a user/developer reaching out about an issue leaves a bad taste.

Here I didn't mean the reaching out, but how it makes the whole idea look like an after-thought. In the vein of, "I want AUR for my build service, so let's run this popular command for building AUR packages automatically".

I may be more sensitive to this particular point though, since I've dealt more with AUR helpers than most. :)

J. Leclanche

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

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.

On 2/27/19 1:37 AM, Brett Cornwall via aur-general wrote:

On 2019-02-27 02:09, alad via aur-general wrote:

...

Considering some recent issues regarding team behavior [1] 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 [2], and interaction with other Arch users on ArchWiki [3].

[1] https://lists.archlinux.org/pipermail/aur-general/2018-October/034461.html

[2] https://news.ycombinator.com/item?id=18156980 [3] https://wiki.archlinux.org/index.php?title=XDG_Base_Directory&diff=prev&...

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 would also chip in with the following from early 2017:

https://github.com/swaywm/sway/issues/1227

(I am also not in any sort of witch hunt, just thought this would be relevant.)

If the only thing we can find to complain about is his attitude towards Manjaro, then we obviously cannot find anything to complain about. :)

Em fevereiro 27, 2019 3:56 Eli Schwartz via aur-general escreveu:

If the only thing we can find to complain about is his attitude towards Manjaro, then we obviously cannot find anything to complain about. :)

I was surprised by this attitude since all my interactions with Drew in the past were quite friendly. Most (all?) were on IRC. I don't recall him being this aggressive on IRC.

Having said that, I don't think we should ever treat anyone like this, regardless of distro. I have very little to say on the AUR packages that has not been said, but those interactions with users are something we need to also take in consideration.

Regards, Giancarlo Razzolini

On Wed, Feb 27, 2019 at 4:47 AM Giancarlo Razzolini via aur-general < aur-general@archlinux.org> wrote:

Em fevereiro 27, 2019 3:56 Eli Schwartz via aur-general escreveu:

...

If the only thing we can find to complain about is his attitude towards Manjaro, then we obviously cannot find anything to complain about. :)

I was surprised by this attitude since all my interactions with Drew in the past were quite friendly. Most (all?) were on IRC. I don't recall him being this aggressive on IRC.

Having said that, I don't think we should ever treat anyone like this, regardless of distro. I have very little to say on the AUR packages that has not been said, but those interactions with users are something we need to also take in consideration.

Regards, Giancarlo Razzolini

I'd like to say this, be careful not to get into a "I'm perfect, I can do no wrong" attitude. Be mindful that everyone makes mistakes in their pasts and they can change, Yes, Consider the past, but also consider the present. Has the person changed for the better? If so, then base the application on that merit. No one is perfect, but don't let Drew's past sins affect his application for trusted user. Let his recent interactions speak louder than his past interactions.

Very Respectfully, Taylor Lookabaugh

As a complete newbie I might not have the rights to chime in here.

But isn't it never too late if Mr. DeVault may add an apologetic comment to @noobpurple under https://github.com/swaywm/sway/issues/1227 now?

Sincerely yours, Darren Wu

On Wed, Feb 27, 2019, 21:53 Drew DeVault via aur-general < aur-general@archlinux.org> wrote:

On 2019-02-26 11:37 PM, Brett Cornwall via aur-general wrote:

...

I would also chip in with the following from early 2017:

https://github.com/swaywm/sway/issues/1227

(I am also not in any sort of witch hunt, just thought this would be relevant.)

It should go without saying that I regret what I said here as well. I was going some stressful financial problems when those comments were written. Doesn't excuse anything, and I'm sure we could find examples of my jerkitude that I can't say the same for.

Instead I'd like to ask this: if I'm to be damned by my past behaviors, is there a path to redemption? Is there any criteria we could establish for demonstrating good behavior? Or, would I have to live with a forever vague sense of unease among the voters? Not to say that the unease isn't justified - it may in fact by the right answer to reject applications based on that unease. If any concerned can think of more tangible criteria, though, it would make it easier for me to dispell your concerns or give me some personal development goals to meet.

I had the following sitting in my drafts and, after seeing Mr DeVault's TU application withdrawal, regretted not having sent it. Edited to refer to the unfortunate conclusion.

On Wed, Feb 27, 2019, 16:10 Darren Wu via aur-general < aur-general@archlinux.org> wrote:

Instead I'd like to ask this: if I'm to be damned by my past behaviors, is there a path to redemption?

As a complete newbie I might not have the rights to chime in here.

But isn't it never too late if Mr. DeVault may add an apologetic comment to @noobpurple under https://github.com/swaywm/sway/issues/1227 now?

This thread has started giving political correctness the bad name it deserves. Not so long ago another applicant had to go through a humiliating interrogation, strong words and insults included, and not many apologies were issued by his accusers; now some others are demanding (politically correctly, thankyouverymuch) from Drew DeVault to act as others before him haven't.

Drew DeVault handled all that pressure with overly due composure and high professionalism, a strong token of his ethos, rarely found in some of his impeccable inquisitors, which obviously wasn't enough because they kept coming back for more. Even his sponsoring TUs had a hard time defending such an apparent felon.

Next time, demand a copy of the applicant's juvenile criminal record, a signed forgiveness from the Vatican and a sworn statement of adherence to The Rules. Oh, and ten hand-written pages of "I shall be a good boy", because nobody wants to work with a degenerate like https://gfycat.com/ambitiousfluidkrill

This whole "TU application" procedure has proven itself flawed because it allows anybody, in full impunity and immunity, to slander, bully and abuse applicants, to the point of making them regret they had applied in the first place.

On Wed, 6 Mar 2019 at 18:04, Brett Cornwall via aur-general aur-general@archlinux.org wrote:

I feel that by conflating applicant vetting with political correctness you're letting your own political viewpoints get in the way of a proper applicant screening. Some of the criteria of a TU involve interfacing with the community; What users will think of Arch. How is it 'political correctness' to judge fitness of a position based on past behavior?

It is, when the focus of judgement lingers disproportionately on something that happened years ago and which was smaller than small potatoes. Additionally, your initial comment "I am also not in any sort of witch hunt, just thought this would be relevant" is an awful politically correct adaptation of the "I'm not a racist, but" excuse.

I agree that he held himself well during the application process... but anyone that's been in a hiring position can tell you that applicants can be very good at hiding their faults when in a position of scrutiny. That's the process, after all: Applicants dress themselves up and the hiring staff look for the cracks.

This weak analogy, which presumes all applicants are guilty until proven innocent, cuts both ways; if you extend it further then when those applicants become hiring staff themselves, they unleash their hitherto well-hidden faults and lash out upon new applicants. Wait, what?

The TUs with questionable behavior are being discussed at this very moment - how can you suggest that DeVault was given unfair treatment?

Unfair is when you're getting a laptop for free and make a big deal about a scratch on the lid.

Just because a developer is well-known doesn't mean that they're fit for every role.

I pointed out a repeat pattern of behaviour with regard to TU applications. And if a couple of a- or f-words over the years weigh more than one's technical prowess and intent of being a good TU, then you should reconsider your criteria.

Please provide examples of bullying and slander towards the applicant during the TU process.

I wasn't only referring to this applicant: see https://lists.archlinux.org/pipermail/aur-general/2018-October/thread.html The mere fact that Lukas Fleischer had to step in on behalf of the Arch team and acknowledge the problem[0], should tell everyone something. I thought it to be the best possible conclusion. The problem is that his closing words ("We will work it out internally. People make mistakes. We learn from it, try to improve and move on.") apparently meant nothing to some people.

As a recent TU addition, I felt that my "inquisitors" treated me quite well during the process.

Well, you have to admit that you had got way less surface of exposure than DeVault for "the hiring staff to look for cracks".

[0] https://lists.archlinux.org/pipermail/aur-general/2018-October/034488.html

Em fevereiro 27, 2019 10:53 Drew DeVault via aur-general escreveu:

On 2019-02-26 11:37 PM, Brett Cornwall via aur-general wrote:

...

I would also chip in with the following from early 2017:

https://github.com/swaywm/sway/issues/1227

(I am also not in any sort of witch hunt, just thought this would be relevant.)

It should go without saying that I regret what I said here as well. I was going some stressful financial problems when those comments were written. Doesn't excuse anything, and I'm sure we could find examples of my jerkitude that I can't say the same for.

Instead I'd like to ask this: if I'm to be damned by my past behaviors, is there a path to redemption? Is there any criteria we could establish for demonstrating good behavior? Or, would I have to live with a forever vague sense of unease among the voters? Not to say that the unease isn't justified - it may in fact by the right answer to reject applications based on that unease. If any concerned can think of more tangible criteria, though, it would make it easier for me to dispell your concerns or give me some personal development goals to meet.

I don't think that's needed, you have proven so far that you can handle criticism, which is a good indicative. As I said, I was just surprised. You never know, sometime you might get someone on a bad mood or something like that. I stand by what I said though, that everything should be taken into consideration. Including past behavior and present, which doesn't mean to focus on the bad stuff, or just wash it away with good stuff. After all, we're all a sum of all that, good or bad.

I appreciate that your sponsors are also backing you up in this, not just technically. Thanks and I wish you luck.

Regards, Giancarlo Razzolini