Sure, but that affected multiple distros. And yet it didn’t affect Arch, so… ![]()
Arch does not directly link openssh to liblzma, and thus this attack vector is not possible.
Source: >https://archlinux.org/news/the-xz-package-has-been-backdoored/
Sure, but that affected multiple distros. And yet it didn’t affect Arch, so… ![]()
Arch does not directly link openssh to liblzma, and thus this attack vector is not possible.
Source: >https://archlinux.org/news/the-xz-package-has-been-backdoored/
That is true for OpenSSH specifically, but it misses the bigger picture of how supply chain security works.
The fact is, the backdoored xz packages were still distributed directly through Arch’s official repositories. According to the official Arch Linux News Archive, the compromised versions (5.6.0-1 and 5.6.1-1) were actively distributed and ended up inside the official March installation medium, virtual machine images, and container images created between late February and late March.
The code didn’t execute its final payload on Arch simply because the attacker chose to target a specific configuration used by other distros. But the infrastructure still blindly pulled, packaged, and distributed a state-sponsored backdoor to official Arch channels without anyone realizing it, until a Microsoft engineer caught it by accident upstream.
If the next upstream attacker decides to target an Arch-specific configuration instead, a “quick glance at the PKGBUILD diff” will still be completely useless. That is exactly why relying solely on repository curation or manual user checks isn’t enough anymore. The threat came from the official channels, not the AUR.
But it made it through to every other distro’s repos as well.
You seem to be singling out Arch as being “insecure” but it’s no more insecure than any other distro - unless you use the AUR without understanding what it is and checking the PKGBUILDs. A compromised upstream package will be incorporated into any and all distros that use that package. No distro is checking the source code of all the upstream projects that they import..
This is becoming a dead horse. Maybe time to close this one.
I think it’s clear that we disagree on various issues, and we have different visions of what to do or how to approach things.
That’s not a bad thing, on the contrary, but I think I’ve bored everyone enough on the subject.
Well, since I started this thread - and have appreciated the robust range of views expressed - perhaps it’s time to wrap it up. Since @Sermor has both given and taken his share of push-back on some of the core issues, I’ll mark his latest post as our shared “solution.”
Onward we go! ![]()
“For profficient” and “lacking common sense engineering and management” - is completely different.
If some things are stupid and makes life harder - its not because they “for proficient”.
Its easy tho to wank your ego by solving challenges noone asked for.
AUR repisitories collection should not allow ownership change. As any public repisitories collection.
Its stupid and morronic.
Given its not just random public github clone, but has specific usage. It do needs some cleanup.
And also. Subcategories of stuff so ppl can trust specific user/keys/url instead of flat catalog of random trash.
After fixing (gaga gugu lol lets just give control over someone repo to some random anonim) there may be meaningfull discusdion.
AUR repisitories collection should not allow ownership change. As any public repisitories collection.
Its stupid and morronic.
Ok, so let’s say the maintainer of theyay package, a volunteer like all maintainers, has life stuff come up that prevents them from effectively maintaining the package. Are you saying he should never be “allowed” to disown the package?
It’d essentially become abandoned with a “maintainer”.
Maybe if he can’t maintain it, he must be forced to delete the package. Someone else can now create it. But how is that any different to disowning the package, and allowing another willing maintainer adopt it, except now change history is also lost?
Not that anything we say here will makes a spec of difference to how the AUR operates, but I’d love to hear actual constructive solutions, rather than drive-by opinions.
Now it’s worth also noting, that AUR moderators have been manually handling adoption requests. A package isn’t orphaned anymore without their ok, and the new maintainer is assigned by a moderator after communication with the would-be maintainer.
We not talking about packages here.
We talking about individual repositories that contain PKGBUILD file that may or may not be properly composed to produce any package whatsoever.
There is no package maintainers in AUR. Because - there is no packages.
Proper way to handle this - do nothing.
If Jon forgot he is pushed jon-doe-important-app to AUR. Steve can create steve-buckle-inportant-app repo.
If Jon want to pass hes repo to someone - he can do it by passing ssh key and other stuff, like normal sane people do.
You cannot have repository without chain of trust that forms by people waighed by responsibility
This is why the absolute minimum is to have repo name composed from username/reponame
As github does. As SUSE build something does, and Fedora in similar way I think.
Just look how github handles it. Thete is no rocket science here. Its really basic stuff.
Like you dont pass around persons accaunts no matter how important repo pretty name is. It is not freaking repo hosting service responsibility.
There is no package maintainers in AUR. Because - there is no packages.
That’s a shame. They even went to the trouble of making an entire set of guidelines for these non-existant package maintainers. Seem like a waste.
I jest, but I understand the point you’re attempting to make. The AUR is essentially recipes for building packages. As you can see though, they are commonly referred to as “packages” almost everywhere, so ![]()
Individual git repositories with maybe recepies(there is no mechanism that guarnties it is indeed a recipie for a package and not lets say npm malware)
Not shame, more like bizzare delusions. You pointing them correct.
What Arch team states about AUR screamenly missalignht with reality of what it really is.
Its really bizare - like Arch sources states that AUR is for package adoption to main repos.
But when last time this actually happen? Codium, brave, waterfox, xlibre(ok lets not touch this one). Lots of really popular AUR repos some of which many years old, why no adoption?
And how many AUR repos owerall? Over 100 000.
Its all for adoption?
Is there even that much of usefull computer programs in the world?
And this also makes statements of AUR team making(now) some moderation or something lafable.
Its not moderatable
in its current form for sure.
I am totally fine to call this repos packages tho.
Its convinient.
But you cannot think or treat AUR as actual package repository. It is completely different thing.
Is there even that much of usefull computer programs in the world?
Well depends on what you find useful. And what you are running, and also not a single sane person is installing all at once as not all are useful on every system.
why no adoption?
Either people are doing themselve or probably not needed (a guess)
Individual git repositories with maybe recepies(there is no mechanism that guarnties it is indeed a recipie for a package and not lets say npm malware)
True and false all at once, You can know but it would take the end user taking steps to test the package first before installing on their own system.
with reality of what it really is.
Wondering if you know what reality is and if you are just trolling to try keep the thread open at this point.
True and false all at once, You can know but it would take the end user taking steps to test the package first before installing on their own system.
I say nothing about ways to know. Only about absence of mechanism. End user taking steps - its post factum research activitivities.
It do not change what is inside repo.
Wondering if you know what reality is and if you are just trolling to try keep the thread open at this point.
This sentence is bizzare…
No. Kira do not have time for trolling. Althought, I think somewhere after 2010 people lost meaning of this word… So I definetly not confident about what person means when speaks about “trolling”.
But your wording is much nicer and makes it clear easily.