Because there is this myth that only Windows users get infected because Windows is insecure, that packages are vetted, that code being open source means that a backdoor insertion would quickly be discovered, and so on.
Packages are vetted, in the repos, just not in AUR.
They also keep tools that would easily/automatically build and install packages from AUR out of the main repos, to encourage manual handling and individual consideration of AUR package build scripts.
Also this malware was found in AUR within a few hours of it going up.
Exactly. It's actually kind of a success story for the AUR, since they found the malware so quickly.
Of course, it would be more interesting if we could scan or survey the AUR to get a percentage of suspicious packages. I've long been under the impression that some popular AUR packages (e.g. Google Chrome) are pretty safe from tampering. For anything else, I glance over the PKGBUILD to make sure it's not doing anything obviously fishy, and I've never noticed anything.
They are built by the core Arch developers, or as in the case of the 'community' repo, by 'Trusted Users', the latter being people who have done high quality maintaining of packages in the AUR and shown good community involvement.
Having met these criterias, they need to be sponsored by an existing TU, and then it will be put up to a vote.
Do you know if there is any kind of review process? For example, let’s say a core maintainer’s machine is compromised and the attacker submits a new package on their behalf. Does anyone else need to review and sign off on the new package?
Depends on what you deem "vetted". Builds from source from a trusted source. Try ask if they can PGP sign their sources. Builds fine. Pushed to the repos. If its an package from core or extra it goes through testing for a few days.
Also been a push towards reproducible builds, and the stones have been laid with pacman 5.1.
Unofficial user repositories contain unofficial user software. Shockers!
Sarcasm aside, I think a lot of the pearl-clutching over this incident is down to people not understanding the difference between the official repositories and the AUR.
Of course, one should be careful about what one installs on their system. Even more so an Arch user, which should be technical saavy in the first place.
Anyways, I know I don't manually review everything I install on my system, I trust the packet manager.
I'm not an Arch user so I don't know, but doest the AUR repo have some kind of code signing or automatic analysis of the packages?
AUR is not an "official" repository at all -- indeed the acronym stands for "Arch User Repository". Kinda like github, you can go put whatever you want in there, and people can download and install it on their machines if they want to.
The "correct" way to install something from AUR is to go grab the install script, READ THROUGH IT CAREFULLY, then knowing that you just downloaded a thing uploaded by someone unafilliated with Arch, you make your decision on whether or not to run/install it. That said, there are (non-official) package managers that you can use which give you a package-manager-like experience installing packages from AUR and do a pretty good job of sweeping all of that under the rug. Convenient? yes; a good idea? it's your system, you decide (my opinion is 'no').
> a good idea? it's your system, you decide (my opinion is 'no').
This frustrates me. Because there is a large vocal group that opposes the use of yaourt (the most popular AUR package manager), I spent a year building packages by hand, just to see if there was something I was missing. I was not. It's just a complete PITA. In the end, I wrote scripts that just about duplicated yaourt -- checks for new versions of packages that I've installed, downloads the latest comments so I can see if there has been any controversy, checks for and installs dependencies, etc, etc.
There is nothing in the manual process that makes it more safe than installing with yaourt. Yaourt prompts you to edit the PKGBUILD file (and even defaults to this!). It is just as easy (and in fact, I think easier) to neglect to check what it's doing when you are building by hand.
After a year of building by hand, I went back to yaourt because I have better things to do with my time than write scripts that duplicate it.
I think the real issue is that many people do not want to legitimise AUR as a source of packages for everyday people. I can sympathise with this point of view and even agree to it to a certain extent. However, avoiding using a tool like yaourt is cutting off your nose to spite your face, IMHO.
> There is nothing in the manual process that makes it more safe than installing with yaourt. Yaourt prompts you to edit the PKGBUILD file (and even defaults to this!). It is just as easy (and in fact, I think easier) to neglect to check what it's doing when you are building by hand.
I get your point, but I think part of the reason for the official stance against AUR helpers is that they incline users to skip any manual vetting of the PKGBUILDs on their own. In practice, you're always going to have some subset of the population who won't even look at the source PKGBUILDs (helper or not), but I think this is a valid concern. If you download the package sources manually, the effort required to type "makepkg" versus "less PKGBUILD" isn't significant. Contrast this to using a helper, where pressing a key to continue building is an awful lot more tempting than having the helper open the PKGBUILD in your editor (where you now have to press many more keys to continue)--regardless of the defaults.
What I tend to do is use an AUR helper to download the package sources and then manually build them from there. Helpers are incredibly useful for searching/downloading sources from the command line, but I'm not completely convinced having them build/install everything unattended is a particularly great idea. Part of this is the nature of the AUR and part of this is because if you use enough packages from the AUR, sooner or later, you're going to have to intervene and fix something (which defeats the point of using the helper in the first place). Plus, using the helper as a glorified fetch tool gives you something of an intermediate package cache as opposed to dumping everything in /tmp and nuking it between boots.
That said, I do agree it's more to avoid legitimizing the AUR. There's good reasons for this (legal and otherwise). But I think it's important for people to decide precisely how they wish to use the AUR as long as they understand the repercussions.
Also, I believe yaourt is considered deprecated as it hasn't seen updates in quite some time. I'd suggest something else like aurman or yay.
> If you download the package sources manually, the effort required to type "makepkg" versus "less PKGBUILD" isn't significant. Contrast this to using a helper, where pressing a key to continue building is an awful lot more tempting than having the helper open the PKGBUILD in your editor (where you now have to press many more keys to continue)--regardless of the defaults.
You could make the same argument about effort to skip checking being fewer keystrokes to argue that yaourt makes its more convenient to check because that is also fewer keystrokes than typing an additional command manually in the command line. Thus I think the actual reality is people who are lazy will skip a self audit regardless of how they choose to build the package. Ie youart isn't problem.
> Plus, using the helper as a glorified fetch tool gives you something of an intermediate package cache as opposed to dumping everything in /tmp and nuking it between boots.
So change the build location. It's all configurable. /tmp makes sense as a default but I have mine set elsewhere. On a previous system I even had yaourt configured to build in its own ZFS tank.
> Also, I believe yaourt is considered deprecated as it hasn't seen updates in quite some time. I'd suggest something else like aurman or yay.
I often hear the same complaint made about Android apps (re it's not been updated in a while) but when it already does everything it needs to then why should it need to see further updates? It's not like yaourt doesn't keep track of security updates (I mean it's all just wrappers around GNU and BSD tools so if there's a bug in tar or OpenSSL then they will be updated independently anyway).
I've been using yaourt for several years and frankly I've never once felt "damn, this thing needs more maintenance".
AFAIK yaourt specifically is discouraged because its possible for a malicious PKGBUILD file to execute code before it is displayed to you (as a consequence of the way yaourt parses the files). Other AUR helpers do not have this problem.
In my opinion, this is a hard problem and not one that we can expect Arch Linux to take on or solve. We're talking about how we establish that a software package (source code, build script, binaries, etc.) can be deemed trustworthy such that we feel comfortable installing it onto our machine (which may hold important data, personal, financial, etc.) I don't think anyone has a good solution, with the Apple App Store at one extreme and (in my opinion) something like AUR at the other.
Arch discourages tools like yaourt because it makes it so easy to install some an unvetted package and that opens you up to the very real risk of installing malware. As you point out, downloading the package and building it isn't any safer if you don't read through the script. It's easy to make the argument that a casual read through of the package file will only catch the most obviously bad packages and a clever person could easily find better ways to hide their malware payload, so why bother looking at all?
If you aren't going to read the package files, you may as well use a tool like yaourt; there's effectively no difference. In my own experience it's rare that I have to install something from AUR so I can take the time to briefly scroll through the package files and check where the source code is coming from, easy stuff like that.
In the back of my mind, I understand I'm taking a risk; I think that's what Arch is trying to accomplish by discouraging tools like yaourt.
I can't speak for all AUR managers but the one I use (yaourt) is probably the most popular one on Arch and it definitely does prompt you to audit the package before you compile it.
No, AUR packages are PKGBUILD files, which are essentially little batch scripts that run inside a fakeroot.
IMHO, the danger of a PKGBUILD itself doing something nasty is small--it would be limited to things like recording `uname -a`, listing all your installed packages: the things mentioned in the article.
The real danger is that the PKGBUILD is installing some software, which you will later run with full user privileges. If you don't notice that the Git repo listed in the PKGBUILD file is wrong, you won't notice that you're actually installing a backdoored version of the package.
The PKBUILD runs in the fakeroot, but AFAIK the .install files (postinstall hooks etc) run on the host system directly, with root permission. Definitely something you will always want to review.
(Also, I don't really get the critique of tools like yaourt, since they make it easy to inspect the PKGBUILD and - if present - install files. The tool simplifies downloading, you still need to review yourself!)
The AUR repo is, basically, a free for all. It’s not the official repository, which is trustworthy - it’s just a hosting space for user-provided build instructions.
Someone was questioning if `libvlc` could be considered dangerous. However the package download our packaged `vlc` packages and just repackages the `/usr/lib/libvlc*` files into a new package.
Following the URLs it appears that it sets up a systemd timer to post some system info to pastebin every hour. However the script also appears to have a mistake which I think would cause it to only log to /root/home/*/compromised.txt.
So much for being sneaky malware, he wasn't even trying to hide it... Any insertion of a `curl` command to some shady looking TLD piping to bash is going to be a massive red flag to even unsophisticated linux users.
Even moreso: the fact that it's well-known as a pastebin means that it should be obvious data coming from it are user-generated and could come from anyone.
Thanks! I got bored of looking for a yaourt replacement because they seemed all the same, and discussions of AUR helpers often turn into flamewars, but PKGBUILD diffs is a valuable feature. Trying aurman :)
Honestly, no, not everyone knows this. Maybe when there was just arch linux and no spinoffs; but manjaro provides an easy path to a rolling-release arch(-like) distribution, and it treats AUR as a first-class citizen in its GUIs. I think there was a popup at some point when an application first accesses AUR that tells you that AUR is unsupported and to go to a wiki to understand it, but I think it could use better messaging. A warning at the header of the AUR section of the package manager gui would be a good start.
Distributing them as repackaged binaries would be against the terms. I'm unsure what distros ignores the terms and packages them anyway. It is a clear liability for any larger distributions at least.
It happens with other archwiki topics too, I encounter it regularly though can't think of good examples from the top of my head currently. E.g. the btrfs article mentions several AUR utilities though admittedly nothing important I need right now :)
For MTP: gvfs-mtp is in the main repos, and pretty much the fullest-featured MTP implementation that exists, which includes all the extensions Android made to it to turn it into a block-oriented file system.
Honestly, MTP is terrible on every OS though. Mac and Windows have it a _lot_ worse for interacting with MTP devices.
Yeah it's funny, my first thought was since I started using Arch, the most common thing I hear people say is that packages from AUR should be considered unsafe until you've read the PKGBUILD, at least. It's a good thing it gets brought up so much, unfortunately.
Even yaourt defaults to prompting you to read all the packages scripts and displays a red WARNING UNSAFE when the package is unmaintained as this one was.
It has options to configure it to do everything automatically, but you have to actively go in and set it so.
I love yay[1]. It has few dependencies, integrates well with pacman, has a useful search function, and is incredibly easy to use. I recommend using the binary version (yay-bin[2]) available in the AUR since it doesn't require compilation and has the fewest dependencies of any AUR helper.
I like and use auracle. It's basically a rewrite / redo of cower, the core of pacaur, by the same developer. Pacaur was the most popular alternative to Yaourt, but is now discontinued.
You should read the PKGBUILD, even on upgrades. In this case the bad guy took over an orphaned package (with 853 votes) and updated it. You could have looked at the upvotes 5 years ago and blindly upgraded to his new version last week.
Many packages use rolling versions from git commits, so while the PKGBUILDs don't get updated, any time a user re-runs makepkg on that PKGBUILD the latest commit is pulled and built.
In those cases, a PKGBUILD might be months or years old, but still consistently up to date and valid.
Not a great idea. Upvotes don't really tell you shit about testing, quality, or trust. I mean how many votes does acroread have (hint: a lot). The votes is merely to give arch some idea of how popular an AUR package is so that it can be absorbed officially.I have had a few of my AUR packages scooped up this way. Voting may indirectly indicate that the package is useful, but it doesn't say the thing doesn't contain malware nor does it indicate that the script is poorly written for other reasons. I orphaned a few quite popular AUR entries with high vote counts. The counts don't magically go away, and at that point anybody on the internet is free to adopt it.
As an Arch user this bothers me since a while. On the one hand the AUR contains packages I don't want to miss, on the other hand installing and updating from the AUR is tiresome.
Recently I switched to the AUR helper aurman which is great, but it still doesn't free you from reviewing PKGBUILD changes. Sometimes I wish there would be some kind of review process where popular packages could be labeled as 'reviewed' (e.g. by experienced/trusted arch users) and an (optional) option within the AUR helpers to accept 'reviewed' packages without presenting the PKGBUILD for review.
I know that wouldn't be perfect either, but at least it would increase the efficiency and as a user one could focus on the less popular packages where it is unlikely that someone else will find some malware.
In a sense we already have that, in the form of the `community` repo: Trusted Users mark a package as safe, adopt it, and it gets packaged up and supported.
Perhaps the answer is a few more TUs to get some of the popular AUR packages adopted and officially supported.
Is there a public database of linux malware found in the wild that one can study to know what kind of things to look for when reviewing PKGBUILDs and other open source code?
In general, but also containing malware found in code belonging to the different distributions, like PKGBUILDs. I'm just thinking that part of the problem with the lack of review of AUR packages by the users is that it's not really obvious what one should be on the lookout for. What does linux malware found in the wild generally look like?, is what I'm wondering. I would think that it would benefit us all to make the cases where malware is found more easy to study.
The case shown here is pretty obvious looking, but I don't think it would be too difficult to make it better hidden. Seeing what kind of tricks are statistically more common would make PKGBUILDs easier to review.
If you haven't heard of it before, and if you're not an experienced dev, it can be tricky to spot. So what I'm trying to say is that I think you're right in that it's difficult for random people (even if they have a strong tech background) to do secure code reviews.
It's not about everyone being prepared to find malware anywhere, though, but only in the cases where they each do. For random users of AUR packages, if they (for whatever reason) trust a project's author, then they only need to check the package author's work. If they could have access to historical examples of real life malware specifically on PKGBUILD files, that would make it much easier to have an idea of what kind of details they should be on the alert for.
For kernel devs, specifically the kind that reviews patches submitted by others, I would think it would also be useful to have data on previous successful and failed attempts at introducing backdoors into the kernel.
Right now, I think that for anyone that wants to see this kind of data for any particular kind of software, they'd have to search for it through various mediums like mailing lists or the blog you linked to (through google).
That's an interesting link, by the way. Thanks for sharing.
EDIT: Removed redundant part. Misread what parent post meant.
But what's a successful backdooring attempt? Any security bug/vuln found in the kernel could have been planted. But perhaps what's what you meant, to have a database of such things, though I doubt it'll make it easier. Serious attackers would either use a custom method or look at what is rarely used on the list so it doesn't trigger any alarms.
I'm surprised that this hasn't happened a lot earlier to be honest. It probably has but haven't been picked up by someone. It's a user submitted repo with over 44000 packages (source repology [0]).
It has happened to the snap store recently, but AUR has been around for ages.
> Following the discovery all dangerous instances were removed and the user account suspended.
I heard they're making a change to the policy for uploading packages to AUR. The next time this happens the user will automatically receive an email that says, "Hey, don't do that."
I tried installing Arch Linux, and it was harder then installing SunOS 4.3. The instructions were absolutely wrong. I wish I could give it another try, but I just don't have time to experience the wow's of the early 90s just to get a browser up.
The Arch wiki used to have an amazing Beginner's guide along with the general Installation Guide. They've since dropped it from the wiki, but there are archived versions that I still bring up every now and then when setting up a new Arch install. Here's one: https://csdietz.github.io/arch-beginner-guide/
Yes, but this may be a good reminder for fellow Arch users who have grown complacent reviewing things they install from AUR.
I've gotten to the point where I do not install any AUR helpers on my systems, and manually download PKGBUILDs and install with makepkg. These extra steps force me to 1) review the PKGBUILD + *.install files, and 2) make me reconsider whether or not I want to go through the effort for a package (i.e. "do I really want this thing")
If you want to see all software installed from outside repos defined in /etc/pacman.conf, you can use this pacman option:
pacman -Qm
It's always a good idea to periodically review this list as well.
I've seen the advice of not installing AUR helpers multiple times before. I guess it works for many, but I feel it takes more discipline to review the files when not using AUR helpers since you can just download them and makepkg them immediately, while all AUR helpers I've seen explicitly ask you if you'd like to first review the files in an editor with a default answer of [Y]es.
One of the problem I see with helpers is that a lot of them start to wrap the whole user's package handling experience (pacman wrapping) where it seems like it would be easy to ignore the prompts and "just download the package already". You can tell users the AUR is unsafe and to review PKGBUILDs but that doesn't mean they are going to listen or do it.
I did write a helper, mainly for myself and a few other arch users I know, and if not for having completed it enough to use it, I wouldn't do it again (I don't support pacman wrapping). I use like 5-10 packages from the AUR and I either maintain them or they _never_ change and I would know something is wrong.
The other point to this is how is this sort of compromise best communicated? It's important enough to hit [0] and obviously this news site, the mailinglist[1], but not the frontpage of arch itself.
> The other point to this is how is this sort of compromise best communicated? It's important enough to hit [0] and obviously this news site, the mailinglist[1], but not the frontpage of arch itself.
I brought it up partially, and the simple explanation is; We don't. It's unsupported and compromised packages happens. There is no system in place to warn about it and the frontpage is reserved for news about issues regarding official packages.
> while all AUR helpers I've seen explicitly ask you if you'd like to first review the files in an editor
The good ones do, yes.
> with a default answer of [Y]es.
And therein lies the problem. You may review a handful up front, but then convince yourself that all is good since it's much easier to just press 'enter' and move on. It's MUCH easier to ignore a PKGBUILD when you have to hit one key to skip it than it is if you have to manually download it, put it somewhere, and 'makepkg' on it.
Oh man, I'm feeling uninformed. So cower is being deprecated and Falconindy is rewriting it as auracle. I guess that's 2 programs I'll have to replace. At least I know this one's replacement.
I really hope one day Linux stops using package managers and switches to single-file binary installers as in Windows and Mac. Until that day, I won't feel completely comfortable using Linux.
Package managers are an inherently flawed way to distribute software, instead of obtaining your programs from whoever developed that program you get it from your OS developer!.
The Arch User Repository hosts whatever people want to upload to it, with basically no proactive vetting whatsoever. In addition, the installation scripts run arbitrary code, a portion of which must run with root privileges.
When a package gets orphaned, that means that anybody in the community can take over maintainership of the package.
There's a whole lot of trust that has to go on when installing a package from the AUR - and yes, this is a fundamental problem with the security model of Arch Linux, but that's been known for a very long time.
Honestly, I'd be surprised if this hasn't happened before with orphaned packages.
> yes, this is a fundamental problem with the security model of Arch Linux
No, it's not. AUR is not Arch, and is not "supported" by Arch.
It's a fundamental problem with the security model running code from randos on the internet. If someone published a git repo on GitHub that installed malware when you ran
git clone git://github.com/user/repo . && ./configure && make && sudo make install
you wouldn't be saying that "this is a fundamental problem with the security model of git."
From the AUR homepage, in big text:
> AUR packages are user produced content. Any use of the provided files is at your own risk.
AUR has the word "Arch" in its name and is linked right at the top of the Arch Linux homepage and from every Arch Linux webpage. So it's disingenuous to claim it is "not Arch.”
Contrast this to the old debian-multimedia, which had no links from Debian.org and which eventually yielded to pressure to change its name to make clear that it was not part of Debian.
Just to emphasize how little AUR is supported by Arch:
Even the 'AUR helpers' aren't part of the normal Arch repositories. So if you wan't a less manual access to the AUR you have to install such a program manually.
And the Arch Wiki states:
Warning: AUR helpers are not supported by Arch Linux. It is recommended to become familiar with the manual build process in order to be prepared to troubleshoot problems on one's own. [1]
I understand your point but the problem is that the title is "Arch Linux AUR Repository Found to Contain Malware" (and not, for example: "AUR Repository Found to Contain Malware"). I would argue that the implication (I guess reputation-wise if that matters) starts with the "Arch Linux" part. It's easy to jump on Arch because of this regardless of the fact that the AUR is not supported. At a cursory glance plenty of people (though incorrect) will equate this to "Arch Linux contains malware"
AUR PKGBUILDs are much more restricted than this, since they're restricted to a fakeroot.
Of course, if you're ultimately going to run the program, the binary set up by the PKGBUILD has a lot of control. But the PKGBUILD itself is limited in what it can do (to things like listing your installed packages, getting `uname -a`--the stuff mentioned in the article).
No. Whatever you stick in the install= file will run as root at install time. If you're using an AUR helper/running `makepkg -i`, the PKGBUILD absolutely can run code as root, without waiting for you to interact with the installed program. Installing a package from a PKGBUILD is no more or no less "powerful" to an attacker than `make && sudo make install`.
The install hooks are chrooted inside the pacman install directory.
But, yeah, they run as root, so they can still do damage.
My point was that the danger zone is when you trust the package, rather than when you run the PKGBUILD itself with `makepkg`. Of course `makepkg -i` runs both `makepkg` and `pacman` as root.
> this is a fundamental problem with the security model of Arch Linux
And with every other OS that isn't locked down so the user can't run arbitrary stuff.
The AUR is just the arch equivalent of downloading a `.exe` installer and running it. Yes, clearly there are security concerns there, but they aren't specific to Arch.
If you want a level of trust, then don't build AUR packages and install things using the package manager (AUR packages aren't supported by it) which have trusted maintainers and are signed.
> this is a fundamental problem with the security model of Arch Linux, but that's been known for a very long time
It's exactly the same problem that every other distro has when users compile or install unvetted community packages.
The only way to make unvetted community repositories safe is to have users look at the sources before building or installing. Arch encourages users to do that -- AUR helpers and binary repositories are discouraged, and the source package format is simple enough that an average user could probably spot something like this.
The thing is not that it's a new deficiency or something, it's just that Arch user conveniently ignore this when praising their distribution over e.g. Debian.
All it takes to build air packages is makepkg from the core pacman package. With gut you can grab aur packages from the terminal, and hit is also core. Every Arch install must have pacman and hit is in base-devel, a package group in core all AUR pkgbuilds are designed to assume is installed.
Urm, you need git, you need build tools... and pacman.
That's it. But oh yeah, because I do these things by hand and check whether the source urls point to the place I'd actually like to install (and other code doesn't download external sources, eg. in the PKGBUILD or external scripts like *.install files), I'm suddenly an exception.
I just noticed that the blue used on the Archlinux logo is actually quite consistent with Rick's hair color. https://i.imgur.com/kkE25w2.jpg Fits me. I don't give a damn.
> "but you don't get to separate the two in the case of an OS or distribution."
Actually I do get to do that. It's an important distinction because if the software isn't at fault, then a technically competent user can safely use it by merely not being as dumb as the average user. But if the software itself is at fault, then the technically competent user should stay clear of it. Idiots will be idiots no matter the distribution. If it weren't arch, they might be downloading third party RPMs or debs from untrusted sources. Would that be reason for a technically competent person to avoid RHEL or Debian? Of course not.
> It's an important distinction because if the software isn't at fault, [...]
Though the software is at fault. It created a false sense of security,
misleading the users. What else in Arch just feels secure, but in fact is not?
And then, if the users around the software generally exhibit a jockey
attitude, you get the whole environment built in a similar manner, not
a robust one. The software may technically not be at fault and technically
could be used in a safe manner, but you won't get much exposure to that, any
such use will be cumbersome and difficult (because nobody uses it this way),
so you still should stay clear of the software. So no, you don't get to
separate the users and the OS/distribution.
> Though the software is at fault. It created a false sense of security, misleading the users. What else in Arch just feels secure, but in fact is not?
AUR never tried to pass false sense of security, it is explicitly declared as not supported everywhere.
> And then, if the users around the software generally exhibit a jockey attitude, you get the whole environment built in a similar manner, not a robust one. The software may technically not be at fault and technically could be used in a safe manner, but you won't get much exposure to that, any such use will be cumbersome and difficult (because nobody uses it this way), so you still should stay clear of the software. So no, you don't get to separate the users and the OS/distribution.
Except it is not, experienced users of Arch community vocally recommends new users to not blindly trust AUR, and the dangers of AUR is also documented everywhere. This is also one of the reasons that yaourt is shamed in public Arch communities like /r/archlinux, since it defaults to poor security behavior.
> AUR never tried to pass false sense of security, it is explicitly declared as not supported everywhere.
Funny that I only ever hear of this when talking about security aspects, not
when discussing available software. In the latter case I always hear how many
things are there in AUR, especially comparing to Debian. AUR must have failed
miserably in not trying to pass false sense of security.
> Funny that I only ever hear of this when talking about security aspects, not when discussing available software. In the latter case I always hear how many things are there in AUR, especially comparing to Debian. AUR must have failed miserably in not trying to pass false sense of security.
One argument does not invalidate the other. It is true that tons of software are available in AUR that is not easily available in other distros. It is also true that AUR is not supported.
A similar thing happens with PPAs in Ubuntu or even with Flatpak/Snaps: they brings tons of additional software to the distro, however they're unsupported and can be security nightmares [1].
[1]:Yeah, even when Flatpak/Snaps are properly sandbox (since some apps are not), they can include software to mine cryptocurrencies for example.
Fortunately admins are not unreasonable and don't base their decisions on praises but on actual merits, so most servers run Debian rather than Arch (which is an interesting distro for other usage cases).
Maybe you could make the case for some cutting edge development or test box, but then again, I'd rather be testing on something that's as close to identical to the production environment as possible.
I used Arch on my laptop (primarily used for development) for several years. It mostly worked great and I always had access to the newest whatever with a minimum of hassle. I don't have many complaints, but occasionally after an update something critical would stop working.
I'm on Solus now and, so far, it's been pretty great. :-)
There is an expectation that projects dogfood their own software, but I really can't think of a rational reason for a production server not affiliated with the Arch project to be running Arch.
Rolling release is great for technically competent users to install on their workstations, but why would you ever want a rolling release on a production server?
Well, one thing which I know of several projects doing, is having an Arch server as one of the continuous testing servers. This way you can test against bleeding edge gcc/glibc/whatnot and catch bugs or breaking API changes long before they appear in major distros.
Nobody that values their job or sleeping well at night. It's basically one level of nuts above and beyond running Debian Sid on all your production servers.
I ran SID in a embedded customer box testing unreleased software, I did run it in KVM from a stable release since I wouldn’t have physical access if something went wrong, glad I did.
"This is yet another incident that showcases that Linux users should not explicitly trust user-controlled repositories."
LOL. Why should this only apply to Linux users? We should all be wary of downloading random things from websites.
AUR has always been labeled "user submitted", but I guess it's easy to forget that some "users" are really out to cause harm.