How (and not) to fix the AUR

twelveeighty · Yesterday 18:48:50

aminepro wrote:

that hits hard, No why is there a problem with my english? please point out where my text seems weird to you so I can improve it

In good faith, (just my 2 cents), I also thought it was some form of generated text. I think it's because you use "machine-like" generated punctuation and capitals - even in the quoted text above: no capitals "T" and "P" for the first word of a new sentence, and a capital "N" after a comma. It makes the brain skip and lose its "place" when reading (mine, at least). Take it for what it's worth, though, I'm not a grammar teacher.

tridra · Yesterday 19:21:17

Yes, but what happens to your trust cascade once somebody turns out to be evil?
From your description you'd wipe the entire tree (subsidiaries get distrusted, but also the parent loses its trust - so their other subsidiaries ie. the siblings of the evil actor get wiped all the way down. And does the grandparent get punished because their child signed off on a malicious actor?)

Yes, kind of like certificate authorities. If a web browser distrusts them, all certificates they've issued may become invalid. This could become disruptive if the system becomes heavily dependent on the verified status. A fix could be to allow for multiple users to verify the same account so that if one tree goes down others can still support the system.

The current situation has no "verified user"? Everyone's equally suspicious.

What I meant is that if someone's account gets hacked, they wouldn't be able to do more damage than they can now. But in one case it would be an isolated incident compared to right now where the AUR is restricted because these kinds of attacks are expected to happen.

So what's the difference between you and an algorithm rating someone as trustworthy because they've X aur commits w/o being flagged for being evil?

I wouldn't say that someone is trustworthy, only that they're doing what they're supposed to be doing SO FAR. If we were to use an algorithm for this, I'd use it only to show that they've become eligible for verification and someone can verify their account. Human verification means accountability for me. If the entire thing is automated, there would be no point in having two tiers of users.

Whoracle · Yesterday 20:36:18

In generally I'm in the "Learn to read a PKGBUILD or don't use the AUR" camp, but one poster (sorry, can't remember and am too lazy to look for the quote) wanted to treat orphans separately. After thinking a bit, I think that _might_ work. Instead of the current orphan handling, there could be a way to automatically move stale packages (when do theey become stale is tbd) to an archive. Difference from the regular AUR: Logged-In-Access only. So they become frozen in their last known state, and you need an archive account for access. That way interested parties can always take a look at how things used to be done, but AUR helpers can't (easily) install from the archive. Adoption would move them back to the regular AUR, so not much difference there in terms of vandalism protection - you still need a way to handle adoption requests, but at least the orphans wouldn't be deleted, and if somebody is interested enough their code is one sign-up away.

Would also signal "Don't install this, but you can take a look at it" a bit more strongly than the current orphaned flag.

loqs · Yesterday 21:22:07

@Whoracle orphans and deleted AUR packages are still available via git as far as I am aware just not listed in the API / web interface. The only content deleted from AUR's git is that manually removed by AUR moderators due to vandalism, personal information e.t.c..

seth · Today 06:53:26

Whoracle wrote:

Instead of the current orphan handling

As a reminder, seth wrote:

The adoption path is a popular vector because the script kiddies are unimaginative. It's by far not the only way to vandalize the AUR to scare its users.

AUR helpers or anyone installing orphaned packages is actually not inherently problematic, but restoring deleted items will stick out from the regular orphan transition (hence the additional/extra suggestion to be more aggressive about removing actual cruft that's really just rotting around, ie. zombies, not orphans)

loqs · Today 07:11:14

seth perhaps the answer is not to fix AUR but remove it as a resource drain on package maintainers and let the community craft its own replacement without Arch's resources?

Last edited by loqs (Today 07:40:50)

seth · Today 07:32:29

seth wrote:

1. You cannot *fix* the AUR by aborting it. You can abort it, but that's not fixing it.

That's really just a matter of choice: do you *want* to do that or do you feel you *have* to do that?
If you *want* to do that, all discussions around the topic that seek to alleviate the pressure are pretty much moot by that point.

Gut feeling:
Community driven might suffer from a lack of trust in the infrastructure itself (more on the side of contributors than consumers) and will probably trend towards PPAs (personal PKGBUILD collections on github) which is the more consumer-centric "I trust this source" than project-centric "vast catalog of PKGBUILDs to mine from" approach.

Arch Linux

#51 Yesterday 18:48:50

Re: How (and not) to fix the AUR

#52 Yesterday 19:21:17

Re: How (and not) to fix the AUR

#53 Yesterday 20:36:18

Re: How (and not) to fix the AUR

#54 Yesterday 21:22:07

Re: How (and not) to fix the AUR

#55 Today 06:53:26

Re: How (and not) to fix the AUR

#56 Today 07:11:14

Re: How (and not) to fix the AUR

#57 Today 07:32:29

Re: How (and not) to fix the AUR

Board footer