Because of the AUR malicious attacks, I have just cleaned my system of all ‘non-essential’ AUR software and left only AUR software installed that is not readily available elsewhere (so far as I know).
TBH I’d like to see/ suggest building a place where AUR software used by EndeavourOS users, can be promoted to similar to the extra ‘category’. The idea being, this class (category) will let folks who use eos understand users have vetted select AUR products (via our use) and they might feel a ‘bit more secure’ using the same tools others do. Very Laissez-faire, I know.
Right now I, for example, only use the following AUR software (some is ancient… like me).
yay -S caffeine-ng i3lock-fancy-git lightdm-settings xautolock xkbset
I believe part of the problem here is also that the malware packages generally look like the real thing and can be off by a simple letter in spelling. While a List of “Safe” Packages is always something worth having it would need to be consistently updated as the status of packages change. This could be time consuming
This has to do with a few aspects but ranking and popularity are among them. Certainly getting more involved with promoting the packages you use is a good idea.
It’s not a bad idea but we also have the show your pacman -Qm post which could essentially do this “Safe” list however some of it is outdated.
Unfortunately, like many other ideas, boils to one point: users need to accept that AUR is not and will not be safe. Only person responsible for vetting packages is you. Any other solution will give you false sense of security and at some point in future will be abused over time.
In thread Malicious AUR Checkup Script@1093i3511 and I had a discussion about what is one of the main problems in AUR that the Arch team should address, because it has simply turned out to be a fatal flaw in two respects, and we, as Arch users—or at least as Endeavour users—should definitely start something like a petition or something similar so that something actually gets done about it.
For one thing, there are far too many orphaned packages. These were the main targets in the first wave of attacks on the AUR. In our opinion, they should be deleted. One way to handle this would be to flag them for deletion after they’ve been orphaned for a certain period, and then, after a shorter period, delete all those for which no one has come forward to explicitly take over as a maintainer. Of course, that won’t happen, but it could. Second. User registration. @1093i3511 mentioned that currently, only a fraction of AUR users are actually registered. This must become the standard. No registration, no access to the AUR. Period. We should vehemently demand these two things from AUR-Users, at first as EOS users, but then later as Arch-Users.
This complete lack of accountability has led to utter chaos, and leaving everything to the whims of AUR users who aren’t even registered is no longer acceptable. Mandatory registration must be enforced without exception; otherwise, the next mess will start all over again tomorrow, and Arch will lose users left and right. Maybe not us, but there will be an exodus if the regular AUR is truly that chaotic and such attacks occur regularly.
It seems to me that the Debian world has largely dodged the AUR type problem via derivative distro repositories. As a long time user of Debian/ arch derivatives, I think the arch family ought to take action; what that is I can’t really say. But I do believe the arch ecos is likely at a cross-road—it may well be that Linux is, as well.
No. There’s a lot of software that works as is and doesn’t need to be touched for years if ever again. Just removing them because the maintainer moved on is not a solution.
Who is not being accountable? The AUR has worked as is for 20 + years. Do things need to be looked at Maybe. The fact is the AUR is not OFFICIAL. The issue isn’t the AUR the issue is AUR Helpers that make it easy to install apps from the AUR excusing people the responsibility of doing it themselves. Maybe learn to install packages manually and then use and AUR helper
And are orphraned the whole time? Are this also real orphrans? I am not long enough here that I could have recognized that. So what are the orphrans which were misused?
As I knew that from work with registered Users it’s known what packages she/he has or leaves and when leaving the user can declare who follows or if the package is obsolete or not and if its working on and is known, who made it and can be asked. Can such be tracked within a registration?
You are absolutely entitled to have a opinion, but there are a lot of people out there that have a opinion of something they have no full understanding about, and because someone cries out we should do something about this elephant in the room, that turns out to be mouse, they roam the streets with big signs and yelling at the top of their voice. My feeling is you are one of those people please stop this.
Okay, the AUR helpers make it to easy to get packages from the AUR installed. That ist right. Your point. It’s clear that I as the one who uses AUR are accountable for it also and must take care what i install and and if I don’t pay close enough attention and aren’t careful enough, then it’s also my fault.
Just let me clarifiy: Even if there are some AUR packages that are more than 10 years old, essentially don’t see any adoption and which are already marked for deletion. Those essentially won’t be that attractive for a malicious take over / malware infusion candidate.
Within the campaign they did targeted packages that were unmaintained and that are still in use.
Sure, you could take over an 15 year old package of some obscure software project. But that won’t make it a prime candidate to deliver malware.
In short, it’s unlikely that a package deletion request would be successful, solely based on the fact that the package is without a maintainer and hasn’t been updated within several years. Better would be: proof that upstream the sources aren’t available anymore, the package is redundant due to being part of the official repos or is definitely non-functional.
I do agree that there are way to many packages without an maintainer within the AUR. And that this should be addressed somehow. But in the end, it’s still the arch user repository.
That is only my own assumption from my side, I can’t back this up with any numbers. It’s not obvious for those which choose one of the arch-based distros.
And I guess it’s pretty unlikely that the AUR would recieve an account registration requirement to download packages, that would only result in an enormous backlash in terms of data privacy and other topics that may be associated to that question.
Okay, so everything should stay as it is and it is my thing to check thoroughly, whenever I install something from the AUR. And as long as I don’t understand the AUR totally and collect enough expierience with it i should not give any advices although I meant it as suggestions. This evidence brough me up and has inspired tremendous respect in me and so I thought how we can react to it. I didn’t know that you can act in the AUR although not registered. That’s what impressed me the most.
Thank’s for the clarification of your position and arguments. Seems that I overinterpreted it and drawn too strikt arguments out of it. A group of you all told me that my conclusions are not measured and I took for me now that it is my dutie to decide what i ever install from the AUR and that the AUR is unregulated and that this will not change much in future. So thats it what I take from this whole theme and I will learn to handel it and stop arguing to regulate the AUR.
From my point of view: I still think that the AUR’s shortcomings still could be addressed.
But I wouldn’t approach the issue based upon regulations, but merely out of the angle of user responsibility and user engagement.
In short, if there is a package that you’re using and the maintainer steps down, consider to take it over. If you’ve got the means to do so. If you stumble upon an issue: report it. And get familiar with the options a AUR account has to offer. Getting involved, checking the PKGBUILDs as advised.
In short: There seems to be a whole lot of critique of the AUR in general. And the limited control the Arch maintainers have to tame this behemoth, which is still not an easy feat. It seems like those who aren’t that familiar with the workings and underlying principles tend to be scared away from the AUR due to this incident, switching to alternatives. Instead of getting engaged, they switch to flatpaks or snaps instead and just don’t bother.
Personally, I did looked into reviewing packages that are orphaned and hasn’t been updated for a long time. But I lack the experience in identifying if a old package is truly obsolete, or if it is just some package that might be pretty niece but still functional nonetheless. The sheer amount of orphaned packages is simply not really encouraging to work through that quantity of packages manually, just to flag them for deletion.
That being said, it’s not solely the task of the Arch dev team to tidy up the AURs mess. The acutal user base could significantly contribute to address the issue. And that malware campaign had at least shown that some stepped up and proactively searched the AUR for the very same malware infusions. Thus the whole thread was more or less mitigated relatively fast. And all the malicious code injections have been roll back more or less immediately.
The only suggestion I would make: Limit the amount of orphaned packages a single user can adopt in a given time. If they want to adopt more they have to go through the AUR maintainers.
For example limit the amount to 5 packages a week, which still seems plenty. With that someone can’t just compromise 500 packages in a day, but it would take two years.
You have a package installed from Extra. Unbeknownst to you, that package loses the maintainer, and falls to the AUR, and is taken up by a bad actor. Unless you’re constantly checking and managing your packages, and reviewing pkgbuild updates (as has been discussed elsewhere), how do you cover that case?
Subjectively, I think feeling ‘a bit more secure’ isn’t going to be where I’d want to draw that line where a breach is a binary situation. Your system is either compromised or it isn’t, it can’t be a “little bit compromised”
It’s great to have defence in depth (of usage) but vigilance is only good as it’s current state of oversight. - I could look at that list of promoted AUR software, pick a package, and it could be compromised, because that recommendation was only a point in time.
TLDR : I think we all need to be responsible for our compliance and security.
I wanted to contribute here, but I don’t think it’s worth doing so. I honestly just… use whatever method the developer recommends and so far, things have been fine for me.
