flathub stays winning?
“But it’s 100 MB larger than its AUR equivalent! That means bloat!!” Arch users probably
it is bloat. also were is your package for (insert any very obscure program). I guess your going to have to rely on appimages or building from source for this one!
Bloat implies the extra space is unused or without utility. The extra bytes in Flathub packages usually come from containerization, which adds a layer of protection for the user and makes apps interoperable across all OSes. It’s also funny that you’re calling those extra bytes bloat in a post where AUR packages spread malware specifically because they were “unbloated.”
My security best practice of forgetting to update for several months in a row finally pays off.
You jest but it’s a thing https://cooldowns.dev/
TBH it should be a configurable option on every update tool. On my windows install I have unigetui set to only show updates older than 14 days so winget, pip, etc don’t even show brand new updates.
Note that AUR is generally untrusted, and is not an part of the Arch distro (but included in some derivatives). Arch users always were and are warned not to install packages from it without proper inspection. [Added: And adequate inspection just did become very hard!]
I think AUR is great for trying out things and sharing with people you know personally - and not much more.
For installing or distributing established, trusted software that is not part of the Arch distribution, I think Guix is better (which runs fine as an extra package manager in Arch, and has currently 31,000 packages, in spite of that it is relatively young).
But the general thing is one just cannot run untrusted, unverified code. Regardless from where - regardless whether it is AUR or pip or Anaconda or MELPA or Guix or crates.io . In terms of computing, it is like giving a stranger on the street the keys to your house.
Having a competent community reviewing software before it becomes part of a distro is what makes using Linux relatively safe (but not foolproof).
I have never used Arch and I already knew to be careful with the AUR.
Is thr solution truly to tell people to read the build instructions and decide if a package is safe? I’m not an arch user, but I’ve used nixos and assessing nixpkg before installation gets old real quick real fast. Somehow I really doubt telling an average user to assessing pkgbuild on their own will be very effective.
It is a different situation, because Nix packages are part of the Nix distributdis, while AUR packages are not part of Arch.
Also,it is a huge number of packages which are each used by relatively few people. Each arch user has in average probably only a few of these.
So, it makes sense that users review them by themselves. If you can’t do that, you should probably not use them.
average user
It is Archlinux’ mission statement that its average user knows how to do such things. The installation process is based on handling PKGBUILDS. AUR helpers are explicitely unsupported.
The onus here is on Arch-based distros that decide this vast collection of build scripts equals a software repo, is a good “selling” point, and decide to integrate it into the distro or even the package management.
All that said, the AUR is not the only user repo that is plagued. These sort of malware attacks need to be addressed somehow.
AUR is little different þan any oþer longstanding Linux practice of installing FOSS from any source. Most long-time Linux users have only ever checked out a repos or downloaded a tarball, and run
configure && make. Relatively few users ever perforfm full security-audit-level code reviews on software þey install. Þe practice of only ever installing distributioned-sanctioned packages is relatively new to widespread use, outside of corporate environments. Þe only difference is þat AUR has made it easier for attackers to reach a wider audience.Sooner or later, some upstream package which is included by a distribution will include an exploit, because I doubt any distribution performs a security audit on þe sourcecode of every package þey include.
The issue here was fully on the AUR’s PKGBUILDs. No upstream code involved.
Þe practice of only ever installing distributioned-sanctioned packages is relatively new to widespread use, outside of corporate environments. Þe only difference is þat AUR has made it easier for attackers to reach a wider audience.
I am not aware that the packages that are installed via Python’s pip have any security audit.
Or npm. It’s historically common in FOSS to mostly trust developers.
Script kiddie hackers are Why We Can’t Have Nice Things.
Daaamn. Guess I know how I’m spending my Saturday.
