Solution to the AUR crisis

nomorewindows · Yesterday 16:21:17

Don't forget the m$ owned github is getting poisoned too, so it's not just AUR.

https://m.youtube.com/watch?v=oLK-OWdEm7I

Rust, systemd, nodejs, and bun.

Last edited by nomorewindows (Yesterday 16:25:03)

loqs · Yesterday 16:33:17

@Bumble if you ask your preferred LLM to evaluate the complexity of the changes you have suggested compared to the stuck integrate single sign on change or the rejected change allowed branch name from master to main I think you will see you are getting towards the complete rewrite level between AUR 3 and AUR 4.

Last edited by loqs (Yesterday 16:33:49)

ewaller · Yesterday 17:09:18

Bumble wrote:

... to be honest, I don't even know why I use the AUR anymore
if there was some package I didn't know how to build, or didn't want to, I would just ask an LLM
and it would get done in a heartbeat, even without human dialogue i can just mindlessly copy and paste error messages until it gets it right
this takes zero effort, and I'll probably be doing it from now on
and i'm not sure any of this is even necessary, because LLMs just make the AUR itself deprecated, but I'll leave this here in case anyone finds it useful

When using the AUR, one uses makepkg to create a package that can be managed by a package manager -- Pacman. Yes, one can hand install things. But, if one does something like a make install, things will get written to the file system that nothing is tracking, and nothing is watching for conflicts. What happens when a hand installed library overwrites a library managed by pacman installed for another program? The breakage may not be noticed until much later when that other program fails for some strange reason. How would one know how the breakage occurred? So now, you fix it by reinstalling the broken package. Now you just broke the thing you hand installed.

If one does not want to use the AUR, that is fine. But, if one can install by hand, one should also be able to do that by crafting a PKGBUILD and using makepkg as part of the process.

This is why we strongly suggest that AUR PKGBUILDS be audited prior to use. It is also a perfect example of why many of us are concerned about programs such as yay which obfuscate the fact that the AUR PKGBUILDS are not packages and are not vetted; rather it makes them appear to be first class packages.

Last edited by ewaller (Yesterday 18:42:37)

seth · Yesterday 18:30:30

loqs wrote:

you are getting towards the complete rewrite level between AUR 3 and AUR 4

Also

Bumble wrote:

make [it] a semi-private club that's welcoming to newcomers

to turn the AUR into something it currently is not and that arch already has, just better: the official repos.
Because at the end of the day adding arbitrary and arbitrary complex heuristics to make an educated guess whether something is trustworthy is still a gamble - an unnecessary one because you can just look at the PKGBUILD to make an even more informed guess whether this is going to do something nefarious. In doubt you can also just ask a Lazyness Looming Machine to explain and reason what this PKGBUILD does and whether any of that is concerning because

Bumble wrote:

if there was some package I didn't know how to build, or didn't want to, I would just ask an LLM

and reading this slightly differently than ewaller: if you're asking the LLM to generate a PKGBUILD, where do you guess it has the "knowledge" to do that?
Now guess what happens if the PKGBUILDs in the AUR where overwhelmingly spoiled with patterns that install some npm package
=> What do you think the LLM will infer is necessary for a proper PKGBUILD?

The single most trustworthy-to-you thing in this entire situation is the gray matter between *your* ears, so feel encouraged to leverage that.

Bumble · Yesterday 19:54:06

complex sounding, sure, but unlike most of the strange build practices that i've never understood, i could write that one in a day without an llm. at its core it's 6 different += 1 functions in python.

i don't think it's necessary either, personal vigilance is more important. it's just an attempt at solving the larger puzzle that's going on across the software world in general. to look at the broader spectrum, there are git repos that no longer accept outside help because too many people are contributing pure slop. so even new coders might not have a way to put their foot in the same doorways that a lot of people had prior.

the old order is definitely breaking, and it's similar to how the architecture for castles had to change once the cannon became widespread. if your walls are exposed at a 90 degree angle, they're going to crumble.

the philosophy of the aur isn't any different. whether now or 10 years from now either the platform changes or every single user has to change the way they interact with it. i think hardening the user is more arch-like.

loqs · Yesterday 19:57:45

Bumble wrote:

I could write that one in a day without an llm

Have you considered offering supporting for AUR's current code base?

seth · Yesterday 20:20:07

at its core it's 6 different += 1 functions

Leaving aside discussions about the complexity of a 6-factor ranking and the questionable value of such trust indicators

like a recent decrease in reputation

which of the 6 +1 functions decreases the reputation?

Also complexity exists in execution next to concept - https://en.wikipedia.org/wiki/Pell%27s_equation

Also

the old order is definitely breaking

No it's not.
Because

I think hardening the user is more arch-like.

that has always been the order of things and none of the recent attacks has been remotely sophisticated enough to undermine proper usage of the AUR.
A lot of people are currently just waking up to that reality - which is maybe the bright horizon here.

MTu08 · Yesterday 21:22:21

oh wow that's alot of people.

but yeah all of you are right, the AUR API has to be changed since forks and duplicates aren't allowed, and with something like this it'll just cause more work for the moderators for a package that is orphaned.
if that's the case what if packages can have a new flag besides orphaned (calling it "final" or "complete) that would specify that this package isn't redundant but simply doesn't need anymore updates? that way there isn't a need for new maintainers to adopt the package and it'll still be secure as it, no changes needed and no need to delete or take action.

that would leave an issue for orphaned packages tho as they'll be unreliable to set and better off deleted. i honestly think the AUR should have some way for a fan-revival of an orphaned packages if it's trusted so users can still use it without worrying about any security issues.

correct me if i'm wrong though.

MTu08 · Yesterday 21:27:29

Kirby wrote:

Correct me if I'm wrong, but aren't the majority of pkgbuild updates just to keep pace with a new upstream release? A new commit that changes only pkgver and sha256sums could be seen as mostly safe, while anything more than that can be marked for extra scrunity

i also agree with what kirby said, they made a valid point

loqs · Yesterday 21:54:06

MTu08 wrote:

Kirby wrote:
Correct me if I'm wrong, but aren't the majority of pkgbuild updates just to keep pace with a new upstream release? A new commit that changes only pkgver and sha256sums could be seen as mostly safe, while anything more than that can be marked for extra scrunity
i also agree with what kirby said, they made a valid point

Which comes back to Arch judged parsing PKGBUILDs as unsafe on security grounds and only parses .SRCINFO. If you mean the user should pay more attention to such updates I fully agree. From my reading of the phrase "marked for extra scrutiny" that involves something doing it automatically somehow.

seth · Yesterday 22:03:43

simply doesn't need anymore updates

"Prediction is very difficult, especially if it's about the future."

that would leave an issue for orphaned packages tho

Which would likely be the vast majority of cases no matter what.

fan-revival of an orphaned packages if it's trusted so users can still use it without worrying about any security issues

Repeat after me: you can trust an AUR PKGBUILD after you checked that it's not doing evil stuff.
People here and elsewhere falsely focus on the orphanage, but if you're not paying attention the PKGBUILD can be nefarious from the get go or the maintainer offers a benign package for some months and then activates the evil code or the maintainers account gets compromised or you're subjected to a MitM attack (which arguable means you probably pissed off some 3-letter agency)…

The AUR is not a trustworthy source and never has been.
It is a valuable source because you can look how things can be done - but YOU HAVE TO LOOK.

People seem to want the AUR into existence to be some weird distro repo where the building is for some reason distributed and multiplied, but that is nonsensical and not reality.

loqs · Yesterday 22:10:11

Perhaps it is because AUR is hosted by Arch and has maintainers users disregard all the warnings or do not understand they are effectively giving root access to a script they found on a pastebin and want a helper to protect them from the risks that involves?

MTu08 · Yesterday 22:17:04

i guess, to be fair alot of useful software are AUR only, it only makes sense why many people use it. an alternative or adding the well trusted repositories to the official ALPM would solve this issue, but as long as there are no alternatives issues like these will remain.
at this point any changes made by an adopted orphaned packages should be checked to avoid any problems, even if you should check the PKGBUILD before updating so less people would be at risk.
if i didn't get something feel free to correct me

Last edited by MTu08 (Yesterday 22:17:50)

loqs · Yesterday 22:26:24

MTu08 wrote:

an alternative or adding the well trusted repositories to the official ALPM would solve this issue

Users can do this already. If you mean Arch should by default add more repositories into pacman.conf I suspect the reason that does not happen is if the maintainers of those repositories became package maintainers (were vetted for trust) then (restrictions permitting) the packages could be added to the official repositories compared with having to constantly monitor repositories beyond Arch's control.

AaronBP · Today 02:05:24

There are some technical things AUR devs can do. They could write some mechanism to track when there have been an unusual number of user creation requests or orphan adoptions or new packages and then automatically lock things down for manual review. They could also scan pkgbuild/post_install for new pm dependencies and flag those for manual review, or other suspicious things like piping things from curl.

But ultimately, this is an inherent weakness of distributing software anonymously on the internet. It's not like this is a surprise. We all knew this was possible from the very beginning. The best advice now is the same as it was 15 years ago: do your due diligence. Use the AUR sparingly. Always read the PKGBUILD and install scripts. Check that the source URLs are legit and you trust the developers. Check for unnecessary dependencies. Check if any patches are doing anything suspicious. If things don't seem right, ask questions and maybe write the package yourself. One strength of Arch is how extremely simple the source package format is compared to Fedora or Debian. Anyone who can use Arch should be able figure out how to write one without too much trouble.

Ultimately no technical mitigations will eliminate the need for manual review by you, as the maintainer of your own system.

Last edited by AaronBP (Today 02:07:45)

loqs · Today 02:17:36

AaronBP wrote:

They could also scan pkgbuild/post_install for new pm dependencies and flag those for manual review, or other suspicious things like piping things from curl.

How to do that without sourcing the PKGBUILD in a way that will match how the PKGBUILD will be handled by makepkg? How would you detect the install target being set dynamically to avoid detection for example in a script that is downloaded?

From my perspective no scanning avoids a false sense of security.

AaronBP wrote:

Ultimately no technical mitigations will eliminate the need for manual review by you, as the maintainer of your own system.

I completely agree.

Last edited by loqs (Today 02:59:02)

seth · Today 08:18:06

From my perspective no scanning avoids a false sense of security.

There's a distinction between what internally can be done in static analysis to filter crap out of the AUR (randomly also catching malware) on periodic cleanups and what the AUR can promise to the users ("nothing")

there have been an unusual number of user creation requests or orphan adoptions or new packages and then

"unusual" is doing the heavy lifting here and it doesn't prevent attackers from building up resources (creating accounts, packages and adopt orphans over weeks and months) and then launch a concerted attack.

Arch Linux

#26 Yesterday 16:21:17

Re: Solution to the AUR crisis

#27 Yesterday 16:33:17

Re: Solution to the AUR crisis

#28 Yesterday 17:09:18

Re: Solution to the AUR crisis

#29 Yesterday 18:30:30

Re: Solution to the AUR crisis

#30 Yesterday 19:54:06

Re: Solution to the AUR crisis

#31 Yesterday 19:57:45

Re: Solution to the AUR crisis

#32 Yesterday 20:20:07

Re: Solution to the AUR crisis

#33 Yesterday 21:22:21

Re: Solution to the AUR crisis

#34 Yesterday 21:27:29

Re: Solution to the AUR crisis

#35 Yesterday 21:54:06

Re: Solution to the AUR crisis

#36 Yesterday 22:03:43

Re: Solution to the AUR crisis

#37 Yesterday 22:10:11

Re: Solution to the AUR crisis

#38 Yesterday 22:17:04

Re: Solution to the AUR crisis

#39 Yesterday 22:26:24

Re: Solution to the AUR crisis

#40 Today 02:05:24

Re: Solution to the AUR crisis

#41 Today 02:17:36

Re: Solution to the AUR crisis

#42 Today 08:18:06

Re: Solution to the AUR crisis

Board footer