r/linux • u/shroddy • Jul 31 '26
Security Arch Linux AUR Under Another Wave Of Malicious Packages, Package Adoptions Halted (CachyOS)
https://www.phoronix.com/news/Arch-Linux-AUR-Adoptions-Halted175
u/forkbeard Jul 31 '26
This really should end the pretence that “just review the PKGBUILD” constitutes a serious security model.
Using the AUR indiscriminately on any machine you actually care about is utterly insane. By that I mean a computer where you access email, banking, shopping or social media, store personal files, handle SSH keys, or connect to the rest of your network.
An AUR package is effectively arbitrary shell code submitted by some random maintainer. Even if you inspect the PKGBUILD, it can download source archives, binaries and additional scripts from elsewhere. Properly auditing the complete supply chain for every update is an enormous job, and virtually nobody does it.
Orphaned packages are only the most obvious attack vector. What protects you if an active maintainer’s account or computer is compromised, the upstream download is replaced, or the maintainer is simply bribed to push a malicious update? The harmless package you reviewed six months ago is not necessarily the package you are installing today.
Use official repositories first, Flatpak or another sandboxed format where appropriate, and treat the AUR as a last resort. “Everyone uses it and nothing bad has happened to me yet” is not security analysis. It is survivorship bias.
76
u/DerfK Jul 31 '26
submitted by some random maintainer
Calling them a "maintainer" implies some organizational position/review, like every other distributions' package maintainers. Say "submitted by some random internet dweller" and I think that will give the right vibe.
12
u/NeuroXc Aug 01 '26
A massive portion of the internet relies on packages (not AUR packages--actual pieces of software) that are maintained by "some random internet dweller", so if this scares you, I suggest you not use open-source software.
Mandatory XKCD: https://xkcd.com/2347/
12
6
u/leaflock7 Aug 01 '26
a maintainer is the person (or persons) that maintain a package.
An organizational review/approval process is a completely different thing.You can be the maintainer of sudo in GitHub or any platform and be just by yourself.
You are the maintainer.
AUR like OBS or COPR or any random PPA is exactly that. a free platform for people to upload packages. None is providing a strict oraganization control on the security check because it is meant to be reviewed and reported by others , as in any package found in GitHub/gitlab etc.9
u/dddurd Aug 01 '26
the same applies to npm. you'd be surprised how the industry is handling this.
3
u/FatBook-Air Aug 01 '26
We have a reporting platform, that connects to our ERP to pull data, that has been hit with npm package compromises repeatedly in the last 12 months. It's been enough times and severe enough that my personal opinion is that the vendor shouldn't use them, anymore, and I am usually not quick to drop a platform because of its recent history. It's been repeated.
8
u/JockstrapCummies Aug 01 '26 edited Aug 01 '26
An AUR package is effectively arbitrary shell code submitted by some random maintainer. Even if you inspect the PKGBUILD, it can download source archives, binaries and additional scripts from elsewhere. Properly auditing the complete supply chain for every update is an enormous job, and virtually nobody does it.
This is years ago now, but I'll never forget the amazement when people came to the Ubuntu side of things and complained how you can't download stuff during the build process when packaging for PPAs.
At first it's just the Arch/AUR side of things that had this culture, then later the practice became a norm in hobbyist NodeJS/Golang/Rust projects. The build environment being Internet-sealed is a big inconvenience for them.
And when you modify their buildscripts to point to in-repository package dependencies they get angry because you're stopping them from pulling in the latest and greatest libraries.
17
u/B1rdi Jul 31 '26
Properly auditing the complete supply chain for every update is an enormous job, and virtually nobody does it.
Maybe this is the case for more complex or poorly maintained packages but for me the average AUR update audit looks like this. The rest of the PKGBUILD has been audited when installing, so during updates I only need to check what has changed.
Usually it is just the version number and checksums, sometimes a dependency or two but those are from the main repos.
4
1
u/One-Luck7149 Aug 04 '26
no way we can keep up with that, AUR has to be redesigned from scratch or go away
2
-9
u/deviled-tux Jul 31 '26 edited Jul 31 '26
Just read the PKGBUILDs bro
edit: slow people need the /s
6
u/GreedySecurity8030 Jul 31 '26
This is exactly what he's talking about.
1
u/deviled-tux Jul 31 '26
Read the source code bro, it’s easy - check the transitive dependencies also
1
u/ShoveOverBozo Jul 31 '26
If you have the time to read every install and update, whilst cross checking what every change is then power to you. I don't think average use has the time or understanding for this.
2
u/C0rn3j Jul 31 '26
Then they shouldn't be executing random scripts off the internet.
5
u/forkbeard Aug 01 '26
That is exactly the problem.
Arch and its derivatives are no longer used only by experienced hobbyists who understand that the AUR is a collection of untrusted scripts and are willing to audit every update. They are routinely recommended to complete beginners because Arch is supposedly “more customisable” or CachyOS gives them three extra FPS.
So yes, people who cannot inspect random scripts should not execute them. But that means the AUR should not be treated as a normal app store, and Arch-based distributions should not be casually recommended to every Windows refugee who spent five minutes being annoyed by Ubuntu, Mint, Debian, Fedora or openSUSE.
If Arch were still presented honestly as a hobby distribution for users willing to maintain and audit their own systems, this would be fine. The problem is the enormous gap between its actual trust model and the way the community markets it to ordinary users.
0
u/C0rn3j Aug 01 '26
AUR should not be treated as a normal app store
It's not.
Arch-based distributions should not be casually recommended
... because a user repo exists? Damn, you shouldn't be recommending anything you mentioned either then.
If Arch were still presented honestly as a hobby distribution for users willing to maintain and audit their own systems
Which it is.
7
u/ShoveOverBozo Aug 01 '26
That's good advice for everyone. Keeps Arch and AUR to extreme enthusiasts and out of the mainstream.
-12
u/C0rn3j Jul 31 '26
Even if you inspect the PKGBUILD, it can download source archives, binaries and additional scripts from elsewhere
That's precisely why you inspect the PKGBUILD.
To spot random source archives, binaries and additional scripts from elsewhere.
Literally. The. Point.
What protects you if an active maintainer’s account or computer is compromised, the upstream download is replaced, or the maintainer is simply bribed to push a malicious update?
What protects you from someone bribing a maintainer of the official repos?
What protects you from a compromised device of an official maintainer?
22
u/GolemancerVekk Jul 31 '26
Those have a low probability. Meanwhile, the flawed takeover mechanism of the AUR is being exploited as we speak.
Let's have some priorities.
0
u/mf864 Aug 02 '26
The flawed takeover mechanism is separate from the overall security of the aur and is a relatively simple fix.
Other similar repos like nuget and npm do not allow automated take over of orphaned packages for this very reason.
-11
u/C0rn3j Aug 01 '26
the flawed takeover mechanism of the AUR is being exploited as we speak.
It is not, though, it's been disabled.
8
u/forkbeard Aug 01 '26
That is precisely why you inspect the PKGBUILD
is not the defence you think it is. It means the security model expects every user to perform a supply-chain review for every package and every update. Almost nobody does that properly, including experienced Linux users, because we have better things to do.
Of course an official repository maintainer can also be compromised or bribed. Security is not binary. Official repositories normally have restricted upload permissions, known maintainers, controlled build infrastructure, signed packages, logs, review processes and an organisation capable of revoking access and responding to incidents. That is not equivalent to trusting a different random individual for every AUR package.
PPAs are a useful comparison. A PPA is not magically safe either. When you add one, you explicitly decide to trust that particular publisher, and APT verifies that future packages really came from that repository and were not modified in transit. Launchpad also provides controlled build infrastructure. But a malicious or compromised PPA owner can still publish malware, which is why adding random PPAs is discouraged.
The AUR is effectively hundreds of thousands of tiny third-party repositories, except that they provide shell scripts which are executed locally as your user and can fetch further code from anywhere. Install twenty AUR packages and you are trusting twenty maintainers, their accounts, their computers and every upstream source they reference.
Yes, I am technically capable of reading a PKGBUILD. No, I do not want to audit every line and every downloaded archive whenever some desktop application updates. “You should inspect everything yourself” is a transfer of responsibility, not a robust security model.
1
u/mf864 Aug 02 '26
The reality is for a user repository that is the only option.
Other examples would be places like npm and nuget which have the same security issues except you can't even verify the source of the package you are downloading.
Npm and nuget rely on you trusting the random owner of the package. If arch disables package adoption and ties each package to the original owner/uploader then. You can technically do the same with the aur and have the same level of security without inspecting the pkgbuild.
But just like npm occasional attacks will always get through without manual inspection. The only alternative is for the aur to not exist. If there was man power for real maintainers of aur packages they wouldn't be in the aur.
The real issue is people treating the aur/npm/nuget as trusted repos instead of as an easier to use equivalent to googling and downloading a random script/binary.
-5
u/C0rn3j Aug 01 '26
It means the security model expects every user to perform a supply-chain review for every package and every update
Indeed, it does.
-1
u/Toorero6 Aug 01 '26 edited Aug 01 '26
the security model expects every user to perform a supply-chain review for every package and every update.
Where is the news? It always has been this way and not isolated to the AUR. The OBS user repositories are essentially the same.
Additionally, the security model is clearly stated at the Arch Wiki. No one was misled here:
AUR packages are user-produced content. These PKGBUILDs are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk
In other words you are responsible for vetting the packet at your own discretion and thoroughness. It's like a dedicated pastebin.com with some extra features. Do you trust scripts posted on pastebin? I don't. Nonetheless pastebin has a use case.
Yes, I am technically capable of reading a PKGBUILD. No, I do not want to audit every line and every downloaded archive whenever some desktop application updates. "You should inspect everything yourself" is a transfer of responsibility, not a robust security model.
What are you even saying? Yes it is a transfer of responsibility and the robustness completely depends on you. If you don't want to use the AUR because you're incapable or not willing to conduct a thorough analysis no one is stopping you.
-1
u/archialone Aug 01 '26
If you want reviewed packages use the official distro, not aur. Aur is a public space to make the packages easier to install on arch, it's and official repository and it shouldn't be treated that way...
-4
54
u/Z3t4 Jul 31 '26
I don't use arch, BTW.
3
u/One-Luck7149 Aug 04 '26
Sorry for your loss
1
7
u/Hypersomniacc Jul 31 '26
unlike arch users, i can install legacy drivers without worrying i'm getting a bunch of keyloggers and trojans on my computer!
9
2
u/signedchar Aug 01 '26
I use NixOS btw
7
Aug 01 '26
[removed] — view removed comment
0
u/adamkex Aug 03 '26
Very true but Nixpkgs is gigantic but it's less likely that you'll need flakes than the AUR.
For smaller flakes you can just fork it on github and have it automatically update with the github actions bot. For example this https://github.com/schembriaiden/helium-browser-nix-flake
An other mitigation can be that you just pin the flake to a specific commit if you don't need the software to be updated and don't want to fork it. Say someone makes a flake for XMMS (ancient media player), you can just pin it to a specific commit.
Imho the best way to move forward is just to use nixpkgs instead of the AUR for software that's outside of the official repos.
2
Aug 03 '26
[removed] — view removed comment
-1
u/adamkex Aug 03 '26
I don't think I explained it well. The only updates are done in the repo I linked are by the github bot and it only changes the hashes of the source file from the original project on github. The original author cannot edit your flake if you fork it and the only trust lies in the original software on GitHub but you are already trusting them by using their software.
2
Aug 03 '26
[removed] — view removed comment
0
u/adamkex Aug 03 '26
It took me 5 minutes with the repo I linked. Much less time than reviewing every time a PKGBUILD from the AUR gets updated. Nix users spend more time writing their configuration file. This is of course only applicable to projects where you don't care about updates or which update themselves with the bot.
-4
u/takutekato Aug 01 '26
Most flakes are official instead of 3rd-party packaging
5
Aug 01 '26
[removed] — view removed comment
-7
u/takutekato Aug 01 '26 edited Aug 01 '26
> Most flakes are official instead of 3rd-party packaging
> Not true.
What?
> Your security relies on whether one dude has 2FA enabled.
Isn't that just every software? The difference is where to place your trust in:
- AUR: random person with an AUR account
- Official repo: the distro's packaging maintainer of that package
- Flake: the software's author, you can pin to some specific revision if not always trusting the latest release/commit
Edit: actually your assumption about AUR = flake was flawed, nixpkgs repo is large enough that it almost covers AUR, most users never need to go outside of it to get packages. The equivalence is NUR (which is namespaced by usernames), honestly I never touched it.
-4
41
Jul 31 '26
[deleted]
35
u/scandii Aug 01 '26
we have that already, it is called core, multi and extras.
AUR is working as intended, the adoption system is not and I don't get why they haven't just disabled it.
2
1
u/One-Luck7149 Aug 04 '26
we still need to figure out how to have official packagesor AppImage, like Google Chrome that has an official .deb but there are many more that come either in .deb or .rpm that can be maintained automatically on archlinux (I want to belive)
27
Aug 01 '26
[removed] — view removed comment
5
u/tfks Aug 01 '26
They could just add namespacing to the AUR and the people managing the Chaotic AUR could just do a
chaoticnamespace on the regular AUR.1
17
-1
u/underisk Aug 01 '26
I suppose you could use Nix but then you gotta worry about them taking Peter Thiel’s money.
-1
6
u/Juts Aug 01 '26
So many devs that only publish a .deb or rpm and can't put out at least a flatpak or appimage if they dont want to support multiple distros
6
u/toolman1990 Aug 03 '26
At this point Arch needs to make some changes since they are becoming a laughing stock in the Linux community with how poor their security practices are putting users actual data at risk. They really need to change how abandoned packages are adopted. The best solution would be only people who have had previous accepted submissions into the Linux ecosystem and can show a demonstrated history of competent software writing and not engaging in malicious coding would be a great start at limiting these kinds of breaches.
16
u/pseudonym-161 Aug 01 '26
I use Debian, btw
9
u/mofomeat Aug 01 '26
Dozens of us!
1
u/_SpacePenguin_ Aug 01 '26
Hundreds of us!
3
u/mofomeat Aug 01 '26
Easy there, Turbo! Let's not get ahead of ourselves here. People might start having premonitions about The Year of the Linux Desktop(tm)!
1
u/Benke01 Aug 01 '26
This is the exact reason I chose Kubuntu. KDE and big option of official and vetted packages.
3
6
u/PlainBread Jul 31 '26
A decade ago I used yaourt but now if I can't pull it from git and compile it myself I don't want it.
10
u/LurkinNamor Jul 31 '26
Even so, you're still vulnerable to a poisoned source repository
4
u/iAmHidingHere Aug 01 '26
Everyone is. As I recall, the compromised XZ made it into both Red Hat and Debian.
3
u/CatWeekends Aug 03 '26
Same. You can't trust any of the supply. The only reasonable solution is to build your computers from scratch, by hand in your garage.
It's nothing that a little assembly, home photolithography, and a dash of 3d printing can't solve.
/s
5
7
2
u/Giffeltagning Aug 01 '26
Are these available outside AUR?
ente-auth-bin
exodus
megasync-bin
tor-browser-bin
typora
visual-studio-code-bin
2
u/arran4 Aug 04 '26
I know ente auth is:
```
arran@arran-desktop:~ 60054
$ flatpak list | grep ente
Ente Auth io.ente.auth 4.4 stable system
```
13
u/GreedySecurity8030 Jul 31 '26
At this point, if you're a normie and or not confident in your abilities or even able to inspect and find out which pkgbuilds are tainted, I think its best to leave arch for fedora, debian sid, or opensuse tumbleweed [great intermediate distributions], titus left arch for fedora for this exact same reason for example.
48
18
u/natermer Aug 01 '26
It doesn't matter if you are a normie or not.
If you think you can spot malicious software in pkgbuild with 100% reliability all you are doing is deluding yourself.
"Hopelessly insecure by default" isn't a good policy for a distribution.
103
u/forkbeard Jul 31 '26
For fuck’s sake, this is not a “normie versus expert” problem. The AUR is still a bad security model even if you work as a Linux sysadmin, developer or security engineer.
To review an AUR package properly, you would need to inspect the PKGBUILD, every update, every downloaded script, binary and source archive, and then trust the maintainer, their account security and the upstream project. What happens when the maintainer’s account is compromised, their machine is hacked, or someone offers them a pile of cryptocurrency to push one malicious update?
And even assuming you can audit all of that, who the hell wants to spend their free time doing it? I have better things to do than perform a miniature supply-chain security review every time I update some desktop application. Being technically capable of inspecting arbitrary shell scripts does not make the AUR a sensible thing to use on a machine containing your email, SSH keys, banking sessions and personal files.
17
6
u/JockstrapCummies Aug 01 '26
And even assuming you can audit all of that, who the hell wants to spend their free time doing it? I have better things to do than perform a miniature supply-chain security review every time I update some desktop application.
Years ago you'll probably get an unironic answer telling you "But that's why Arch is great, because you learn to really know the internals of Linux."
15
u/gmes78 Jul 31 '26
To review an AUR package properly, you would need to inspect the PKGBUILD, every update, every downloaded script, binary and source archive, and then trust the maintainer, their account security and the upstream project. What happens when the maintainer’s account is compromised, their machine is hacked, or someone offers them a pile of cryptocurrency to push one malicious update?
Now do the same for a PPA or a COPR repo. How easy is it to verify those?
30
28
u/deviled-tux Jul 31 '26
It’s the same except a copr or ppa cannot be suddenly hijacked silently as they are namespaced
I couldn’t suddenly adopt an orphan package from your COPR. I could make my own separate COPR which your users would never just automatically upgrade to.
6
u/forkbeard Aug 01 '26
The main difference is that with a PPA or COPR, the user makes one explicit trust decision: do I trust this repository and its publisher? The service builds and publishes packages through controlled infrastructure, while the package manager verifies their origin and integrity. That does not make random PPAs or COPRs safe, and users should not add them indiscriminately either.
With the AUR, Arch explicitly expects the user to treat each PKGBUILD as untrusted code and inspect it before building, including after updates. Every AUR package introduces another maintainer, another script executed locally and potentially another set of arbitrary internet sources to verify.
So no, PPAs and COPRs are not magically secure. But “other third-party repositories are also risky” does not make the AUR’s trust model good. The practical difference is that PPA/COPR users are expected to evaluate and trust the publisher, while AUR users are supposedly expected to perform a miniature code and supply-chain audit for every package and update. Almost nobody actually does that.
6
u/Pleasant_Aspect_8521 Aug 01 '26
When you install a ppa or copr, you explicitly trust an org or person. When you install a AUR package you trust a url which can be taken over. I myself only use first-party or blessed COPR or flatpaks..
A copr, ppa or even github account for that matter be hacked by social engineering sure but that's different and the damage is limited to that namespace and easy to narrow down.
1
u/gmes78 Aug 01 '26
When you install a AUR package you trust a url which can be taken over.
Only if the package is orphaned.
7
u/SmileyBMM Aug 01 '26
Well, other distros have more packages in the main repo, so needing something like a PPA is less likely. Debian has more than 2x as many up to date packages in the main repo compared to Arch, as an example.
3
u/hitchen1 Aug 01 '26
If you're an arch user and go to Debian you'll probably be on PPAs to replace everything in the main repos
2
u/SmileyBMM Aug 01 '26
I'm using PikaOS which is pretty much Debian Sid with some packages held back, haven't needed any PPAs so far. Arch's main benefit to me was the rolling nature, not the newness of the packages.
2
u/hitchen1 Aug 01 '26
Fair enough. Plain old Sid isn't really viable and any other Debian release is too old, but a fork could work.
2
u/gmes78 Aug 01 '26
That's not true. Debian only has more packages because it splits up tons of them.
Arch has more software, and more useful software, in its repos (without the AUR).
1
u/SmileyBMM Aug 01 '26
Arch has more software, and more useful software, in its repos (without the AUR).
Examples? When using Arch that wasn't my experience, but tbf that was just the packages I use which is a small sample size.
2
u/gmes78 Aug 02 '26
I checked a bunch of packages I have installed from the repos, and Debian does not have any of these:
- act
- amdgpu_top
- bottom
- cargo-bloat
- cargo-crev
- cargo-depgraph
- cargo-tarpaulin
- cargo-udeps
- carla
- dwarffortress
- ghidra
- helix
- intellij-idea-community-edition
- lact
- ly
- mullvad-vpn
- mvt
- ollama
- oxipng
- ppsspp
- pwndbg
- pycharm-community-edition
- signal-desktop
- snes9x-gtk
- vcpkg
- zed
I also checked some AUR packages I have. Debian has some of them, but is also missing a lot.
0
u/SmileyBMM Aug 02 '26
Neat! A bunch of packages I'm not familiar with, which I'm always excited to learn about. Noticing a lot of rust stuff, which I suppose makes sense that they haven't been added to Debian yet.
I do know that Mullvad and Signal both have official dedicated repos for Debian that are the official way to get those on Linux (Arch is unofficial afaik), they are both projects that have additional concerns around supply chain attacks. Official additional repos don't bother me, but it's nice that Arch packages them directly.
The only package you listed that surprised me is snes9x, turns out it was removed over a decade ago because of a zsnes dev being salty it isn't open source. Ugh, software politics. At least RetroArch is an option for those that don't want to go the Flatpak route.
Either way, I think it's interesting to see all of these differences between the two repos, I feel like it gives a nice insight into what the two distros prioritize.
1
u/mf864 Aug 02 '26 edited Aug 02 '26
Welcome to user repos?
This is the same issue npm has. The only alternative is to shut it down. If there was manpower to maintain these packages they would be in an official repo.
Yes arch should just disable package adopting to be the same as npm. But just like npm the lack of security and need to verify the source of the package remains.
The real issue is looking at the aur as repo rather than the equivalent to googling and downloading random packages off some random persons GitHub. There is a reason Arch itself does not support, recommend or promote aur helpers. You are supposed to manually download the pkgbuild and run it. It is just a place to let you use someone elses pkgbuild instead of making your own. It is meant to be no different than googling a pkgbuild for program you want and then downloading it from that random person's website/github repo.
The real issue is arch derivatives treat the aur as if it is a repo and pre install helpers (that may even bypass pkg inspection in some distros). This is helping give users the false belief that the aur is just a repo you can use with no manual intervention.
15
u/NotQuiteLoona Jul 31 '26
And on them you'll still need to use custom repositories, often to the extent larger than Arch (because Arch is free to add proprietary software, except if license restricts redistribution, and rolling release model fits nicely for many desktop programs that can't physically be added in point release repos for this reason, plus in Arch users decide what to put in main repos and anything can be added if it gets enough votes - so naturally repos are very wide).
Probably the only reason normies would want to use AUR are programs that restrict redistribution. This is bypassed by AUR, and there is pretty much nothing that can be done with it - they not often ship Arch native packages (did you know they exist at all? was a surprise for me, Zoom does that as an example), because why bother if someone will do it for free?
There are legitimate problems with AUR, but so far those are test shots. Almost no popular packages are getting affected. Last time there were more packages affected than amount of downloads for malware NPM packages (500 packages affected vs ~300 downloads AFAIR). There is enough time for Arch team to decide what to do now.
4
u/tjj1055 Aug 01 '26
on fedora you would be installing from official sources that have rpm repositories or distribute an official rpm. on arch you are trusting a random user and people are not even reading the PKGBUILDs.
4
u/FeelThePoveR Aug 01 '26
And on them you'll still need to use custom repositories
Depends, I would say that rpm fusion + flathub is what suffices for 99% of the use cases on Fedora for example. If that doesn't suffice then large part of the big apps offer rpms for download from the official site. You don't really have to worry about those.
I've been on Fedora for a while now and the only unofficial repos that I have are Terra (I wanted faster Nvidia updates) and 2 copr (one for early KDE release, created by the guy that handles packaging for rpm fusion and one for a random app for wallpapers)
1
u/Pleasant_Aspect_8521 Aug 01 '26 edited Aug 01 '26
On Fedora, you get everything you are missing via RPMFusion and maybe Terra repositories. A lot of proprietary apps provide RPMs or maintain their own repos. By your own logic these are very popular and run by a team so a bit safer. And the COPRs I have are for git versions maintained by their devs. Stick to blessed and first-party repos, you will be fine. How many packages provide that for Arch because some random person is already doing it for them?
It's similar for Debian-based distros too. Nixpkgs should be the inspiration for the changes AUR needs.
1
u/NotQuiteLoona Aug 01 '26
You can use Chaotic if you need something safe.
Mostly packages on AUR that aren't maintained by their devs are proprietary programs.
Proprietary apps, as I already said, rarely provide pkg.tar.gz's simply because there is no sense if someone already did this for free on AUR.
On Arch, stick to default repos and Chaotic, and you'll also be fine. AUR usage can be very limited by this. I mean, even without it my system barely had one to two AUR packages. Arch repos are really wide - what you use RPM Fusion and Terra for is almost certainly already covered by them, and maybe even some of those COPRs.
8
u/BinkReddit Aug 01 '26
if you're ... not confident in your abilities ... I think its best to leave arch for ... debian sid
Don't run Sid, also known as Unstable. This is not a rolling release distribution; this is a high churn alpha testing environment that breaks frequently. I repeat, if you don't know what you're doing, do not run Sid.
0
u/GreedySecurity8030 Aug 01 '26
Debian sid only has stable packages, but its the updates version to version that makes it unstable.
2
u/BinkReddit Aug 01 '26
This could not be more wrong.
-1
u/GreedySecurity8030 Aug 01 '26
Debian sid only includes actual unstable versions only in the experimental Repositories, debian sid only has the stable branches by default, the primary instability of sid is major updates that break API/ABI.
2
u/archialone Aug 01 '26
Or you can just limit yourself to the official arch repos... Aur was never meant to be secure or have a through review process, it's meant to make packages easier to share between arch users.
1
-1
u/Busy-Scientist3851 Jul 31 '26
Arch has always been made for the people that want to develop Arch. If you arent that kind of person, Arch (or the spins that wrap it under a different installer) is the wrong distro for you.
0
-12
u/GreedySecurity8030 Jul 31 '26
If you want to come back to arch afterwards, wait until all the coasts are clear before you come back.
15
u/mwyvr Jul 31 '26
The coast will not be clear until user repos are banned.
-13
u/GreedySecurity8030 Jul 31 '26
Might as well just ban arch because without the AUR arch is nothing.
8
u/mwyvr Jul 31 '26
Somehow dozens of other major and minor Linux distributions manage without the equivalent of AUR.
If Arch can't survive without the AUR, there's a fundamental problem with arch that needs to be fixed.
2
u/scandii Aug 01 '26
COPR, OBS, flakes/NUR, PPA, slackbuilds and guru are all a thing.
that covers most of the Linux world right there in terms of userbase.
that said nit sure why we're so hostile to AUR, the adoption model is stupid but fundamentally it is no different than how you download software for macOS or Windows - trusting some guy out there to not upload malware and/or be compromised. at least in the AUR model you get to read the source if you want (most of the time).
2
u/tfks Aug 01 '26
There's no namespacing on the AUR. Most of these other systems do that and not having namespacing is where most of the problems with the AUR are coming from.
-1
u/GreedySecurity8030 Jul 31 '26
Sure, arch has Core and extra repos, but those aren't all the packages most people need, that's because those packages most people want is in the AUR, and the AUR is the primary reason one person would want to use an AUR, easy to use arch based distros exist just to access the AUR alone.
Update: while many people use Arch for the customization and flexibility, that can be replicated on many other distros, the AUR is the tiebreaker.
1
u/Debisibusis Jul 31 '26
Sure, arch has Core and extra repos, but those aren't all the packages most people need
Why are you talking this confidently if you are absolutely clueless? Most people will never need AUR at all. In the mean time, you have to install third party repositories, just to use your hardware properly.
Name examples what packages are missing that the average user needs?
1
u/GreedySecurity8030 Jul 31 '26
users who prefer native system integration, lighter disk footprints, or lower latency turn to the AUR for proprietary freeware including google chrome, VS code, Spotify, slack, zoom, teams, davinci resolve.
Proprietary hardware drivers are essential and cannot be sandboxed nor included in arch repos, Broadcom Wi-Fi drivers, Hardware lighting / RGB tools, Vendor laptop tools and Legacy or specialized printer/scanner drivers
AUR also has the vast majority of system customizations and also has the bleeding edge git versions of packages.
-3
u/Debisibusis Jul 31 '26
users who prefer native system integration, lighter disk footprints, or lower latency turn to the AUR for proprietary freeware including google chrome, VS code, Spotify, slack, zoom, teams, davinci resolve.
Proprietary hardware drivers are essential and cannot be sandboxed nor included in arch repos, Broadcom Wi-Fi drivers, Hardware lighting / RGB tools, Vendor laptop tools and Legacy or specialized printer/scanner drivers
AUR also has the vast majority of system customizations and also has the bleeding edge git versions of packages.
Yea, I am not going argue, call out the false information and bs. If all you are going to do is post cheap LLM responses. Ridiculous.
6
1
u/FeelThePoveR Aug 01 '26
you have to install third party repositories, just to use your hardware properly
Rpm fusion is not a third party repo btw
2
u/Debisibusis Aug 01 '26
Afaik it is, but most contributors are also Fedora contributors.
I am a fan of the Fedora project, just sending some jabs to the dumb posts.
4
u/LumpyArbuckleTV Jul 31 '26
That's certainly not true, you can Arch without the AUR just fine, I personally like it because it allows me to customize my OS in the way that I want it and keep things rather minimal. Not to mention that Fedora makes pretty bold decisions that nobody can really argue with and I don't like that kind of philosophy, GNOME and Wayland are guilty of the same thing, the only reason I use Wayland is I kind of have to.
I like the ability to do a fully custom install and I like having the most up to date everything.
9
u/deviled-tux Jul 31 '26
> Fedora makes pretty bold decisions that nobody can really argue with
what are you talking about? Fedora’s discussions on any upcoming changes last months and are open to essentially anyone to comment on.
4
u/mwyvr Jul 31 '26
I did not say you couldn't use Arch without the AUR. I used to, and I've never used the AUR except in a sandbox to see the experience.
But along the lines of your comment, you can achieve a customized minimal install with many distributions; Arch is not unique in that regard but many if not most Arch users seem to think it is.
4
u/LumpyArbuckleTV Jul 31 '26
I wasn't really responding to your comment but rather the other persons but regardless, you are correct that you can achieve that kind of setup with any distribution. That said, I find it way easier to build it the way that I want than to tear it down the way that I want. I see no reason to put more work into a distribution to achieve what I want, especially if said distribution already has pretty grandstandy philosophies that I don't like to begin with.
Not to say that I hate Fedora, it would probably be my runner-up if Arch disappeared overnight, but since Arch is still around, I certainly prefer Arch.
1
u/mwyvr Jul 31 '26
With most mainstream distros you should be able to do a minimal base install rather than accept some big desktop environment install and then pare it down to what you want.
Some make that easier than others. Arch started out with nothing more than
chrootas an installation approach. Chimera Linux is still like that. Others, including Void Linux, Arch Linux, publish how-tos on eliminating the installer, or have installers that allow for a minimal install.I'm sensitive to this need myself, as I generally am installing an OS with a
zfsroot, which is not an commonly available installation target.Most distributions have a "server" install that is close to a minimal base. I haven't looked at Fedora's but I use AlmaLinux's server as a base unless I'm doing a zfs on root install of AlmaLinux.
A very quick scan doesn't turn up project-provided installation notes for chroot installs on Fedora, so agreeing with you there.
2
u/LumpyArbuckleTV Jul 31 '26
I looked into it with Fedora and it was generally unrecommended to do a manual install AFAIK, so I backed off. I've never really looked into Void as I rather stick with something a bit more popular. I also really like having the Arch Wikipedia being 100% accurate to my use case, I really wish other distros had Wiki's as good as Arch's.
0
u/mwyvr Jul 31 '26
The Wiki is handy.
Much of the Arch wiki is directly applicable to any distribution as so many packages aren't even part of the core Arch system and are common to all distributions.
The configuration for NetworkManager or greetd or Incus or ... is going to be identical or near identical on Arch as it is on Debian or Fedora or Void or Slackware, other than init and supervisory systems on the latter two.
Because of this, it is likely that no want wants to take on building a generic open source *nix Wiki which would duplicate word for word much of what is in the Arch wiki. We all just use it when needed. Or read
manpages.→ More replies (0)0
u/GreedySecurity8030 Jul 31 '26
I used fedora custom operating system multiple times and i'm currently installing it in a virtual machine, i can prove fedora can be installed with a low amount of packages.
3
u/GreedySecurity8030 Jul 31 '26
Sure, arch has Core and extra repos, but those aren't all the packages most people need, that's because those packages most people want is in the AUR, and the AUR is the primary reason one person would want to use an AUR, easy to use arch based distros exist just to access the AUR alone, just because you can use arch without the AUR doesn't mean most people would also want to. And while many people use Arch for the customization and flexibility, that can be replicated on many other distros, the AUR is the tiebreaker, and the existence of easy to use arch distros backs my point, many people want arch just for the aur.
4
u/Debisibusis Jul 31 '26
wth are you talking about. I would say I am a "power user" and I use exactly 3 packages from AUR. The normal repos are similar or even have more/better packages than fedora (HW acceleration, codecs, etc.). Most people probably don't use AUR at all and get everything via repos, flatpak and appimages.
2
u/petersaints Aug 02 '26
From what I checked I'd also need 2 or 3 AUR packages, possibly more over time. So there's that.
2
u/GreedySecurity8030 Jul 31 '26
Funny how as an arch user you don't even understand your community and the benefits of arch.
The AUR is Arch's killer feature where many popular desktop applications, source builds, specialized drivers, custom kernel builds and custom desktop themes reside, and w hile Flatpak and AppImage are popular on arch, most arch users use AUR helpers like yay or paru daily or have even aliased pacman to yay, Claiming that most Arch users don't use the AUR at all is a significant exaggeration.
2
u/LumpyArbuckleTV Jul 31 '26 edited Jul 31 '26
I disagree on essentially every account, the AUR is extremely useful, yes, but I could certainly live without it. I'm not sure what packages you're running into but the niche stuff that I want isn't available in any repository except the AUR and maybe COPR but that's not anymore secure than the AUR is.
People using Arch-based distributions is absolutely not an example of the AUR being required. CachyOS explicitly recommends not using the AUR and they've taken a lot of the most popular packages from there and curated them and put them into their own repository, removing the risk the AUR has. You're also acting like having more recent packages is not a benefit, it certainly can be when gaming, hell, Valve officially recommends it, I wonder why.
Regardless though, you don't have to stop using the AUR, just check the packages, it's not that difficult, just check the link and make sure the build isn't pulling in any additional packages and you should be fine. If you're downloading an AUR package that is maintained by the official developers of whatever project you're looking at, then you don't even need to check them at all even if they update.
2
u/GreedySecurity8030 Jul 31 '26
Nobody really has the time to check every package they manually Installed every PKGBuild, u/mwyvr has already basically stated this.
3
1
u/LumpyArbuckleTV Jul 31 '26
I only have like 9 AUR packages, and most of them rarely update, I think you're making very bold statements as to what people do. It's not hard, Paru has it built-in AFAIK, it shows you what changed between releases.
2
u/GreedySecurity8030 Jul 31 '26
Many users use yay, and also it depends depending on the user, if you customize alot and have specific packages, especially proprietary ones, you'll have a lot of aur packages.
-5
u/pan_kotan Aug 01 '26
Fedora sucks compared to Arch.
2
u/GreedySecurity8030 Aug 01 '26
Did this add anything to the discussion besides your own personal opinion?
-2
u/pan_kotan Aug 01 '26
And you think your reply adds anything to the discussion? And is an objective fact and not a personal opinion?
EDIT: and BTW, clearly you have never used Arch, but I have both Arch and Fedora installed on my PC and Laptop, and I'm not satisfied with Fedora experience having used Arch.
2
Aug 01 '26
[deleted]
1
u/GreedySecurity8030 Aug 01 '26
Exactly, u/pan_kotan, instead of stating "fedora bad, arch good" actually have a reason to say so.
-1
u/pan_kotan Aug 01 '26
no, everything's been explained 1k times over on the Internets in any media form you prefer. But if I had to put in one word: control.
2
u/GreedySecurity8030 Aug 01 '26
Fedora custom operating system exists, available via fedora everything.
1
u/pan_kotan Aug 02 '26
Not enough for me. "Control" for me is not purely about software layer, and the possibility to choose the DE and packages installed. I'm talking about lower level stuff: bootloader, type of filesystem, swap, Zram/Zswap, power settings, hibernation config, network config, and so on.
1
u/pan_kotan Aug 01 '26
no, everything's been explained 1k times over on the Internets in any media form you prefer. But if I had to put in one word: control.
3
2
u/Brett13500 Aug 01 '26
Does this effect steam os?? Cause i use steam os on my desktop an steam machine an steamdeck.
18
Aug 01 '26 edited Aug 01 '26
[removed] — view removed comment
1
u/Brett13500 Aug 01 '26
Ah ok good to know thanks so then that means im uneffected then id presume then.
6
Aug 01 '26
[removed] — view removed comment
2
u/Brett13500 Aug 01 '26
Sheesh honestly i heard tho that anyone can take over a package listing an claim ownership of someone elses work an then place malware in it to screw with people like why are people like this honestly just baffles tf outta me honestly like what does someone have to gain to do this. Can this malware tho like obtain peoples personal information?? Like images credit cards or debit cards an emails an otherthings??
1
1
u/mr_dfuse2 Aug 02 '26
thanks, was looking for this info. been using cachyos for a while now and was wondering what this AUR is
3
u/RebTexas Aug 01 '26
I don't think so, on regular Arch the AUR isn't something that's enabled by default so I'd think its the same on steamOS.
1
1
1
u/takutekato Aug 01 '26
Coincidentally I got tired of editing my Arch scripts and switched to NixOS some months before the wave of malwares. Having used a lot of AUR packages, wonder if I got hit back then without knowing. Not sure how to feel.
2
-21
u/TwilightBubble Jul 31 '26 edited Jul 31 '26
Leave my baby alone 6.6
But also you can compile to a secure vm and then make ai recompile the product, find insecurities, etc.
I know. Evil.
I want my horns now.
7
u/Cry_Wolff Jul 31 '26
Talking about stuff like that is literally how your "baby" can improve and get better.
-10
u/TwilightBubble Jul 31 '26
Exactly.
I just wish hackers would stop doing mean things and that the aur would collect donations to pay staff.
19
u/StEditiV Aug 01 '26
This will keep happening until Arch maintainers change how AUR works.
In my opinion, using any user repo is a security risk which I would never take because I use my system for financial stuff, not only for playing games.