I understand this was AUR. AUR or not could someone share their steps installing any package? How to ensure package you are installing (and deps) are not malware? Because installed (bad package) seems difficult to really undo.
Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages
191–200 of 227 posts
Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages
#192I like the aur wrappers for the convenience, but if I've already limited my AUR consumption quite a bit, I think from now on all aur updates will be manual. One thing programs like yay could do though is to tie the packages to the maintainer. If the maintainer changes, it should be treated as a completely separate package. Not a perfect solution, but could avoid a few automatic upgrades.
[deleted]
Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages
#193It is safe to assume that at least one actual Arch developer was compromised by this.
The followup attack on Arch itself is not going to be pretty.
Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages
#194Earlier quoted context omitted.
As someone already explained in a sibling comment, Arch Linux AUR packages are simple shell scripts that download source code from upstream, apply patches and install. I review them every time I have to install from AUR.
And what if upstream is problematic? Even if it stops this particular attack, reading just the AUR file feels like fighting yesterday's war. I don't think advice to the effect of, just read the parts of the code that have been used in attacks in the past but blindly trust everything else, makes a lot of sense.
> And what if upstream is problematic?
The same as when you install any software on macos or windows, even proprietary ones, that may themselves depend on third party libraries.
At every stage of development there is a possibility of malicious code being introduced.
Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages
#195Earlier quoted context omitted.
"Review" them how? Read every single line of code before installing something? If it's a binary package, how do you do that? Make reproducible builds for everything you install? Move to from source distro? Putting this on users is not a tenable solution. There's room for common sense, but blaming the users for this is ridiculous
As an arch user, I would always skim the PKGBUILD file of AUR packages to see if they install the software they claim to install from official sources and if there's something obviously fishy.
In this case even if you skimmed it you likely would have missed it since the malicious change was adding a new dependency called "atomic-lockfile".
Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages
#196Earlier quoted context omitted.
"Review" them how? Read every single line of code before installing something? If it's a binary package, how do you do that? Make reproducible builds for everything you install? Move to from source distro? Putting this on users is not a tenable solution. There's room for common sense, but blaming the users for this is ridiculous
> If it's a binary package, how do you do that? You find one that builds from source, or you still review PKGBUILD and friends and lean more on evaluating the reputation of upstream and its maintainers, or you simply decide never to install binary packages. Your policy is yours to decide. > Putting this on users is not a tenable solution. The alternative would be to not have an AUR. Archlinux has official package rep…
The AUR being hosted by the Arch project on the same domain gives an air of authority and reputation to it which is misleading.
Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages
#197Could we be heading towards a world where it's just more secure to write inhouse software again, only now with AI agents? Not closed source per se, but 'own source'?
It's more likely we will move to a world where desktop OSs have a security model like ios/android so malicious software can't steal your data.
Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages
#198Has anyone from the AUR team (such as that is) published a retrospective yet? This was some impressively fast firefighting but in all honesty, it seems like some changes are needed, either in AUR policies or in the wrappers. I should be able to set a minimum package age just like I can with pnpm. Orphaned packages should not be adoptable by just anyone. Maybe there should even be a global rate limit on this as a sign…
Better would be to namespace AUR packages. That way, ownership is not lost and we don't need orphaning at all.
Are you suggesting like .packaged-by.joe-Schmoe ? And then if Joe Schmoe abandons it, people should instead switch to .packaged-by.Abe-Lincoln etc?
Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages
#199Earlier quoted context omitted.
> The Arch distribution model, which operates like the Javascript ecosystem, as in having a barebones core and then a zoo of unregulated third party community packages does not seem fine these days It's hard to take the rest of your comment seriously when you don't seem to have a basic understanding of the parts involved here. Arch's distribution model isn't at all like npm (which I guess is what you're actually talk…
>But the AUR isn't Arch's main distribution model, and the official Arch repositories contain a ton of packages in the core, so not even the "barebones core" is correct here. I don't think that narrative is supported by the numbers. Arch's repositories are about a magnitude smaller than either the AUR or "batteries included" distributions like Debian. (about 10k to 100k packages), there are more people using Arch der…
> I don't think that narrative is supported by the numbers
Why are you looking at numbers? Arch Linux's official way of distributing software to it's users are the repositories called "core", "extra" and "multilib", anything else than those are "unofficial" and user's responsibility to how they handle it. No need to look at any numbers, literally go to Arch Linux's website and read how it works if you don't know since before.
> there are more people using Arch derivatives than arch
May be, find it hard to believe that's true outside of gaming, but regardless, that doesn't mean suddenly the AUR becomes safe. And if the complaint is about how these Arch-derivitives educate their users, go to their message boards and share this, that has little to do with Arch Linux itself, literally why there are multiple distributions in the first place.
> something north of 90% of arch users use the AUR.
Yes, like me, and probably every other Arch Linux user. I'm sure every developer on macOS at one time uses the terminal, does that mean "rm -rf" suddenly needs to go away?
> it's a random pseudonymous user who doesn't show up on Google
So what, why it matters? All that matters is that the package does what you expect, and use official sources if that's the point. My password manager's AUR package is built by someone I don't even recall the username of, is this a problem in practice? No, because I do what my OS tells me and reviews random 3rd party software I download from the internet. Every time I upgrade, I see that the only thing changing is the URL which points to the official domain, and a content-hash, that's it. The user could be a pirate in Somalia for all I care.
> I do not think that the majority of people running arch today in practice realizes that their password manager they installed from that repo everyone uses is managed by an absolutely random person on the internet.
I think if you look at a certain sub-section of users who install and do things without thinking, you're absolutely correct. But I don't think the rest of the user base who uses Arch for the very value proposition it offers, should suffer because there is a small sub-section of users who install OSes based on what influencers are pushing to their viewers today.
Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages
#200Earlier quoted context omitted.
Only thing I can find on requesting to take over an inactive account is here: > We do not accept requests to release, transfer, or reclaim usernames on the basis that they appear inactive or unused. If the username you want has already been claimed, you will need to select a different available name unless you are submitting a trademark complaint as described below. https://docs.github.com/en/site-policy/other-site-p…
Github has changed their policy in 2022. Before that it was possible to contact support to reclaim any username provided that they had no meaningful public repos and they were inactive for a long time. It was at the staff's discretion, there wasn't an elaborate policy of what constitutes inactive, but I've successfully reclaimed a username inactive for 2 years myself. The old policy was: GitHub account names are prov…
Meanwhile sometime around there I changed my GitHub username, and not reading up on the suggested process before doing so. The idea was to rename my account, then create a new account with the previous username, so no one else could squat it, as it's my firstname + lastname and the combination seems unique in the world, so it's basically just me. But a few seconds after renaming the account, it got squatted and even requesting to GitHub to reclaim it somehow, has fallen on deaf ears.
Lesson learned, create new accounts and never rename usernames, regardless of what rules the platform might share publicly.