Issue tracker moved to https://gitlab.archlinux.org/archlinux/aurweb/-/issues
FS#10298 - "Trusted" AUR packages
Attached to Project:
AUR web interface
Opened by Geoffroy Carrier (gcarrier) - Sunday, 27 April 2008, 18:47 GMT
Last edited by Callan Barrett (wizzomafizzo) - Thursday, 29 May 2008, 09:45 GMT
Opened by Geoffroy Carrier (gcarrier) - Sunday, 27 April 2008, 18:47 GMT
Last edited by Callan Barrett (wizzomafizzo) - Thursday, 29 May 2008, 09:45 GMT
|
DetailsI'm proposing some kind of "safe" state for AUR packages.
A few packages can't be released into community because of licensing issues. A few packages don't even have enough votes for but could deserve this state. The idea would be for such packages to be shown as "safe" on AUR's website and yaourt. That would for example mean that a sysadmin wouldn't have to check the PKGBUILD nor confirm anything in yaourt to install them, and could rely on it directly. That wouldn't mean that the upstream program is safe, only that the PKGBUILD is not malicious. Some proposed on IRC to use the # of votes for that, but a package can be changed and turn into malicious and keep its votes. Packages could only be trusted "safe" by TUs (or any other new role) and would loose this "safe" state on any change. Or this state could be reserved to packages maintained by TUs (or any other new role). I come from the Debian world and think that safety is an important point. My opinion is that Archlinux should put an emphasis on "warranties" (not the legal meaning, but some "moral" meaning). As always, my English is far from perfect and I thank you for trying to understand me ;) |
This task depends upon
Closed by Callan Barrett (wizzomafizzo)
Thursday, 29 May 2008, 09:45 GMT
Reason for closing: Won't fix
Thursday, 29 May 2008, 09:45 GMT
Reason for closing: Won't fix
In short: wanna help? Apply for becoming a TU. When we will be enough to keep up with it without going crazy, then we will talk about adding new features that require extra work for us.
@Daenyth: devs and TUs are entirely different entities, there's no hierarchy and that's on purpose. Arch strives to reduce bureaucracy and verticalization to the bare minimum, and you can be sure that such a proposal will be rejected by almost everyone because the Arch Way focuses on the KISS philosophy...
What I mean is that when an AUR user visits the page for a PKGBUILD, he has some additional buttons to use in addition to "Flag out of date"
* Mark as dangerous (PKGBUILD contains overt or subtle malicious code: forkbombs, "rm"s, etc)
* Mark as poorly formatted (PKGBUILD does not comply with Arch packaging standards)
* Mark as broken (PKGBUILD does not compile or the compiled package does not work as advertised)
And a display:
X users marked this PKGBUILD {dangerous,broken,malicious,outofdate}. Most recent flag: foodate at bartime
The criterias would need to be discussed and the choice may not be easy. Some considerations though:
* I used "out-of-date" for broken packages (as it's often due to changes in other packages). I think that "out-of-date" could be replaced in my use by "older than upstream" (terms to find) AND "broken".
* I'd like to know if dangerous packages happen often. Maybe every package reported dangerous would need to be inspected by a TU (and deleted if necessary).
* I think being able to report Safe would be great. Then "dangerous"/"safe" votes could result in a karma.
@bardo: I've been thinking about it for the last days and I'll take you at your word. I'd like to spend more time for Archlinux and will soon candidature for TU. I have a draft ready in my mailer and just want to speak with a (ex-)TU first, and make sure I would make a useful work (considering I have a lot to learn).
If you want to help out the community by cleaning up the AUR you should apply to become a TU, there can always be more TUs.