103
Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Affected Packages
(www.phoronix.com)
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
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).
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).
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.
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.
I have never used Arch and I already knew to be careful with the AUR.
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.
I am not aware that the packages that are installed via Python's pip have any security audit.