Re: [aur-general] Enforcing AUR package quality (was Re: Trusted user application: Drew DeVault)
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 > > 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 > -- Cristiano Zerbinatti (Chene) whatsapp (19) 9-9430-5595 skype cristiano.chene
Re: [aur-general] Enforcing AUR package quality (was Re: Trusted user application: Drew DeVault)
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 > 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 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
Re: [aur-general] Enforcing AUR package quality (was Re: Trusted user application: Drew DeVault)
On February 28, 2019 12:43:02 PM EST, Eli Schwartz via aur-general 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 >> wrote: >> >> >> >>> 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
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: > > > >> 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 signature.asc Description: OpenPGP digital signature
Re: [aur-general] Enforcing AUR package quality (was Re: Trusted user application: Drew DeVault)
On February 28, 2019 11:34:08 AM EST, Jerome Leclanche wrote: >On Thu, Feb 28, 2019 at 5:22 PM Daniel M. Capella via aur-general > wrote: >> >> On February 28, 2019 8:58:06 AM EST, Jerome Leclanche > wrote: >> >> >> >> >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
Re: [aur-general] Enforcing AUR package quality (was Re: Trusted user application: Drew DeVault)
On February 28, 2019 11:33:36 AM EST, "brent s." 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 > wrote: >> >> >> >>> 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_prototype Listing the false-positives could be good, especially as that would point out what needs to be improved in namcap. -- Best, polyzen
Re: [aur-general] Enforcing AUR package quality (was Re: Trusted user application: Drew DeVault)
Am 28.02.2019 um 17:34 schrieb Jerome Leclanche: On Thu, Feb 28, 2019 at 5:22 PM Daniel M. Capella via aur-general wrote: On February 28, 2019 8:58:06 AM EST, Jerome Leclanche wrote: 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 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. 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.hs
Re: [aur-general] Enforcing AUR package quality (was Re: Trusted user application: Drew DeVault)
On Thu, Feb 28, 2019 at 5:22 PM Daniel M. Capella via aur-general wrote: > > On February 28, 2019 8:58:06 AM EST, Jerome Leclanche > wrote: > > > > >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
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: > > > >> 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_prototype -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
