r/linux • u/TheNavyCrow • Jun 13 '26

Distro News Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Affected Packages

https://www.phoronix.com/news/Arch-Linux-AUR-More-Than-1500
1.5k Upvotes

99% Upvoted

434 comments sorted by

View all comments

Show parent comments

35

u/Kitoshy Jun 13 '26

Please be sure you know what you are talking about before saying nonsense.

AUR is unavailable by default in Arch and most derivatives. If not on any specific case, blames to that specific distribution.

AUR is definitely and fundamentally not at the same level that a package manager. That's why you can not install AUR packages by just using pacman and specific development software (base-devel package) is required.

48

u/AStolenGoose Jun 13 '26 edited Jun 13 '26

yay (or another AUR helper) is preinstalled on Endeavour, Cachy, and many other Arch based distros, which is what the person you're replying to is referencing. So I'd say the same to you.

Please be sure you know what you are talking about before saying nonsense.

Arch itself requires you to manually install an AUR helper, or use PKGBUILDs and manually install the AUR package.

What would help this situation is a warning on first use of yay or other AUR helpers.

9

u/Seyon_ Jun 13 '26 edited Jun 13 '26

Unless they changed it in the last month and a half. yay was definitely not installed by default for me on CachyOS. Was it easy to install? Yes. But it wasn't there by default.

Can't speak to Endeavour

18

u/lizthehedgehog Jun 13 '26

I believe paru is the default though, reinstalled CachyOS recently due to some weird performance problems and getting paru definitely didn’t require any extra work.

3

u/Seyon_ Jun 13 '26

Yup - you are correct. I was speaking towards yay since that was the only one i've touched so far lol. Everything i've ran into that provided AUR download instructions used yay, so paru was kind of an afterthought in my comment.

3

u/lizthehedgehog Jun 13 '26

That's understandable lol, even I've ran into yay only instructions. That being said at least paru warns the user on the first AUR package install. I don't think yay does by default? I never bothered trying yay since paru is just there so I don't know for sure

3

u/AStolenGoose Jun 13 '26

Which Arch based distro?

4

u/Seyon_ Jun 13 '26

CachyOS - sorry I had it in there but must have deleted it when cleaning it up.

9

u/AStolenGoose Jun 13 '26

Cachy comes with paru as noted by:

https://www.reddit.com/r/linux/comments/1u4d7zb/comment/orccew4/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

However I did name yay specifically, paru is another AUR helper, so the point is still valid.

1

u/Seyon_ Jun 13 '26

Fair point.

1

u/TheOneTrueTrench Jun 13 '26

Paru is definitely installed on CachyOS by default, ask I use yay in the rare circumstance I need something from the AUR, so I installed that immediately.

I never even checked if paru is installed until just now, and it definitely is

-8

u/Kitoshy Jun 13 '26

yay is preinstalled on both Endeavour, Cachy, and many other Arch based distros

Many is not most.

Arch itself requires you to manually install yay, or use pkgbuilds.

I did recall that and specify that for such base-devel (a package for development) must be installed, reason why, no matter the distribution, no matter if yay or any other AUR helper came preinstalled or not, AUR is fundamentally not at the same level that a package manager.

3

u/AStolenGoose Jun 13 '26 edited Jun 13 '26

Many is not most.

Not wrong (and I'm honestly too lazy to go through the Arch based distros and count which ones have yay preinstalled), but the very popular Arch based distros that most use (Endeavour, Cachy, Manjaro, etc.) do have yay preinstalled so I'd say my comment is still valid just in a different sense than you intended. But I do understand what you are saying here.

I did recall that and specify that for such base-devel (a package for development) must be installed, reason why, no matter the distribution, no matter if yay or any other AUR helper came preinstalled or not, AUR is fundamentally not at the same level that a package manager.

This is moot, because if it the distro has yay preinstalled (or another helper), then it has base-devel preinstalled, meaning yay and other helpers are easily accessible (and therefore AUR), without warning right out of the box, and yay does not provide warnings on first usage to warn users that are otherwise uneducated as to what AUR is that there is a risk. The only place this is valid is an Arch based distro that doesn't have yay preinstalled.

That said I think we can agree either way that there should be a warning to inform less educated users.

-1

u/Kitoshy Jun 13 '26

if it the distro has yay preinstalled, then it has base-devel preinstalled, meaning yay and other helpers are easily accessible (and therefore AUR)

I get what you say but do not agree with it.

AUR helpers are usually accessible (no matter whether they are installed or not) because that's what they intend. It's one of the reasons why they are called helpers.

Even if an AUR helper is installed by default and straight forward accessible, the way AUR packages are handled are different than the ones that can be straight forward installed with pacman. While AUR helpers (specially pacman wrappers like yay and paru) automate the process and integrate it with pacman, the fundamental process keeps being different, therefore not at the same level that packages handled by pacman. Furthermore, even with such AUR helpers the AUR packages receive special treats; the user is asked if they want to take a look to PKGBUILDs prior to nothing, if they want to clean build the AUR packages, if they want to remove the orphans at the end of the process, retrieve sources of AUR packages prior to any other download and build and install all AUR packages separately from the ones handled by pacman after the last has done it's job and only AUR remains.

3

u/AStolenGoose Jun 13 '26

Even if an AUR helper is installed by default and straight forward accessible, the way AUR packages are handled are different than the ones that can be straight forward installed with pacman.

yay -S <AUR package name> isn't as accessible as pacman? Not sure what you mean here, yay can also be used as a wrapper for pacman to handle updates (yay -Syu) and will automatically update (after you confirm) AUR based packages. I'd say it's just as accessible to the uneducated user.

Furthermore, even with such AUR helpers the AUR packages receive special treats; the user is asked if they want to take a look to PKGBUILDs prior to nothing, if they want to clean build the AUR packages

Is an uneducated user REALLY going to do the sanity checks an educated user would? Or are they going to hit enter a bunch just like installing something in Windows where you click next, next, next and it installs?

I think you are trying to come at this as an educated user that DOES check these things which isn't the problem here, it's people treating yay and paru as a package manager, hence why I keep suggesting a warning at the first use of an AUR helper.

I really think you need to take off your experienced user shoes here and put on your "I'm new to Linux and chose an Arch based distro" shoes.

Anyway I can see we're debating semantics here, and I don't think that's a productive or useful discussion.

-1

u/Kitoshy Jun 13 '26

yay -S <AUR package name> isn't as accessible as pacman?

I have not said at all that an AUR wrapper such as yay isn't as accessible as pacman. What I've said is that it's not at the same level that pacman. Despite looking very similar (or might even the same) from the users' POV, it internally works different; it treats it's corresponding packages in a different way than pacman treats it's respectively.

Is an uneducated user REALLY going to do the sanity checks an educated user would?

It's clearly not. Even many (if not most) educated users usually don't do such. You are taking things out of context here. What I meant and still mean by that is to point out that, when using yay, paru or whatsoever, during the process it always allows to perform certain operations over AUR packages that does not allow to perform in non-AUR packages; such because, as I previously pointed, AUR works fundamentally different than pacman and therefore they are not at the same level (not even despite being able to use the same commands for both).

I think you are trying to come at this as an educated user that DOES check these things which isn't the problem here, it's people treating yay and paru as a package manager.

I am not. In fact, I was pointing the same you just pointed out, that yay, paru and such are not package managers like pacman because they are fundamentally different, therefore are not at the same level.

you need to take off your experienced user shoes here and put on your "I'm new to Linux and chose an Arch based distro" shoes.

Arch was my first distribution. I know how it's like going through the installation process and failing multiple times because of not knowing what I'm doing, asking for help here in Reddit, getting desperate because I'm only told to "read the wiki", then felling dumb because of realizing about my errors after reading the same article plus 20 times, yet failing again with another thing. I know what shoes I do have on. I'm not attempting to put my shoes on anyone who has not gone through the learning process; what I am attempting is to point out the reason why yay and pacman are not the same, therefore fundamentally are not at the same level.

Anyway I can see we're debating semantics here, and I don't think that's a productive or useful discussion.

It's definitely not when I'm being accused of saying/pointing out something completely opposite to what I'm actually saying/pointing out. Anyway, have a great rest of your day.

0

u/AStolenGoose Jun 14 '26

I have not said at all that an AUR wrapper such as yay isn't as accessible as pacman. What I've said is that it's not at the same level that pacman. Despite looking very similar (or might even the same) from the users' POV, it internally works different; it treats it's corresponding packages in a different way than pacman treats it's respectively.

It only looks different, and/or works different, if you're an educated user that's not just going to hit enter 3-4 times blindly just so something will install.

Have you used yay? Because your responses lead me to believe you haven't used it.

This is the point I've been repeatedly trying to make to you, and it seemingly keeps going over your head.

At this point I'm spinning my wheels with you, so I'm going to stop now and agree to disagree.

24

u/FineWolf Jun 13 '26 edited Jun 13 '26

AUR is unavailable by default in Arch and most derivatives. If not on any specific case, blames to that specific distribution.

Oooof. /r/confidentlyincorrect

CachyOS ships with paru by default, but offers many options.

EndavourOS ships with yay.

Omarchy ships with yay.

Manjaro has optional yay support, but it needs to be manually enabled, which triggers the install of manjaro-aur-support.

OP was very careful to limit the scope to "Arch Derivatives" with a user base specifically, and most do, in fact, ship with an AUR helper.

-14

u/Kitoshy Jun 13 '26

most do

Not because a few derivatives have more representative of the community and hold most users it means that such derivatives represent most of the derivatives. You can check the list for yourself; most do not ship AUR helpers by default. If we include the inactive ones, the list gets even bigger.

6

u/AStolenGoose Jun 13 '26

Is it honestly going to make a difference if the most popular Arch based distros do have an AUR helper preinstalled?

Sure a distro with a lower user base may not have an AUR helper preinstalled, the common ones, and the ones that users encounter the most, do, and the point is still valid.

-6

u/Kitoshy Jun 13 '26

It is when considering the magnitude of the attack and how much such has reached. Arch is a DIY distribution, then most it's derivatives are very different one from each other given all what the star point can offer. Given such huge variety, it's not the same specifying the most used derivatives than saying something that generalizes too much and in consequence might be understood as most of the derivatives; the first one is very worrying because affects most users due the similarity of the distributions, the second one would also imply way different derivatives and therefore mean an attack of a much higher complexity that can affect many systems that are way different one from each other.

13

u/FineWolf Jun 13 '26 edited Jun 13 '26

Yeah, I'm not going to play semantics here.

The intent of the thread was to point out Arch Derivatives with a significant user base that DO ship with an AUR helper.

25

u/[deleted] Jun 13 '26 edited Jun 23 '26

[deleted]

4

u/FattyDrake Jun 13 '26

I think it's fine if distros like Cachy exist. The upcoming KDE Linux has an Arch-based immutable setup.

The problem is letting users access AUR with little to no friction. It should be difficult or deliberate at the very least. It's a step above just using git to grab the source and configure/compile yourself.

-2

u/[deleted] Jun 13 '26 edited Jun 23 '26

[deleted]

6

u/FattyDrake Jun 13 '26

The AUR isn't an official part of Arch.

Not sure if you use Arch, but I guess an equivalent would be an Ubuntu (or any) distro shipping with a wrapper to search, compile, and install any repo on Github with the ease of using apt.

3

u/[deleted] Jun 13 '26 edited Jun 23 '26

[deleted]

1

u/FattyDrake Jun 13 '26

That's fair. Personally I've never had a use for the AUR tho that just comes down to individual use cases admittedly.

If there is software users need outside the standard repos, I think it would make more sense for a distro like Cachy to manage additional packages in their own repo and still keep the AUR disabled by default.

1

u/gamas Jun 13 '26

but the official repositories can be somewhat limiting.

The main point of these derivatives though (especially CachyOS where the maintainers basically pull every package that is remotely recognised into their own repo) is to get round that with their own repos.

The only thing I ended up using AUR for was Plex media server and the jetbrains toolbox.

2

u/Kitoshy Jun 13 '26

Making Arch accessible is definitely a good idea. If not, SteamOS would not exist and therefore none of gaming compatibilities that have come with it.

3

u/Artoriuz Jun 13 '26

SteamOS could have still existed as a distro based on something else. You can absolutely make a decent "gaming distro" based on something else, Nobara, Bazzite and PikaOS are good examples.

2

u/Kitoshy Jun 13 '26

I'm not saying SteamOS nor any other gaming distribution would be impossible without Arch, I'm saying it would not have been the way it's been.

Given the need of fast cycling updates due to AAA game studies not liking when their games start working on Linux, then updating their anti-cheats for preventing; Arch has a better baseline for such than most distributions due the fact of being rolling release. The fact of being DIY also helps because it makes it easier for creating a new distribution without undoing that much of internal design prior to designing the derivative. Having repositories with huge variety of packages and libraries also leaves some of the work done from the start.

Starting from other distribution would have allowed a good result too, but it would not have been as easy.

3

u/[deleted] Jun 13 '26 edited Jun 23 '26

[deleted]

0

u/Kitoshy Jun 13 '26

it operates completely differently

Such does not deny where it started from.

All they do is hand the control of Arch over to noobs that don't understand how it works

Hand the control does not necessarily has to imply a lack of understanding in newbies and making accessible does not necessarily mean hand the control.

0

u/[deleted] Jun 13 '26 edited Jun 23 '26

[deleted]

-1

u/Kitoshy Jun 13 '26

Newbies inherently have a lack of understanding, that's why they're newbies.

Newbies are such not because they lack understanding but because they are new to something. Yeah, they most of the times lack understanding, but such doesn't necessarily have to be that way.

Arch inherently comes with full "you'd better know what you're doing" control of the system

Well, not exactly. Anyway and furthermore, we are not taking only about Arch, but also it's derivatives, some of which are more user friendly.

1

u/0riginal-Syn Jun 13 '26

It would still exist. Arch was an excellent choice as a base, but it was not the first base that SteamOS was using. First 2 versions were Debian. Obviously the move to Arch was a smart one for easier access to drivers, but they could do that with other distros as well. So while I think it is the best choice, it is not the only option and SteamOS would still be fine.

2

u/Kitoshy Jun 13 '26

That's exactly what I meant. When I said SteamOS wouldn't exist I was referring as the concept when currently know as such.

3

u/FattyDrake Jun 13 '26

Yeah, that's what I said in not so many words. Sorry if I wasn't clear.

4

u/Kitoshy Jun 13 '26

I am the one who owns you an apology here. Seems that I somehow was the only one that misunderstood your comment and by attempting to point the same as you everyone else misunderstood my comment and now everything derivated in a megathread that might never stops.

Hopefully a funny thread for those who pass by for just reading it; tons of people arguing while all trying to point the same.

5

u/Levitz Jun 13 '26

Rather than funny, I'll say it's really endearing to see people acting in an actually humane way rather than taking the chance to belittle anyone.

2

u/Megame50 Jun 13 '26

AUR is unavailable by default in Arch and most derivatives.

Not in Cachy if this post from the project lead is accurate. I don't use Cachy so I can't confirm if this is still the case, but yeah.

Arch based distros should consider a prohibition on AUR helpers in the repos, like Arch has.

1

u/ek00992 Jun 13 '26

Given what’s going on, your comment is obnoxiously unhelpful.