Well, I guess I'll avoid updating for the next few days. A bit worrisome that I did so last night.
I wish I had a clear operating system to switch to for safety and the benefits that come with the AUR or the Nix ecosystem. Unfortunately it seems that the era of being able to naively and gratefully trust in the armies of volunteer maintainers is over.
LLMs make large scale and long-term attacks easy and cheap. You could (and if I was a three letter agency, I would probably do so!) maintain ten thousand packages as three thousand separate "individuals" for years before cashing in the trust you've built up.
> naively and gratefully trust in the armies of volunteer maintainers is over
I'm almost scared to ask, did you not even review the PKGBUILD or anything else before installing stuff from the AUR?
Nixpkgs has a completed different model compared to AUR, the changes that end up in nixpkgs are all reviewed by maintainers, while AUR is literally free-for-all "anyone can push anything at any time", I don't think you ever could "naively and gratefully trust" AUR in the way you might have been.
> did you not even review the PKGBUILD or anything else before installing stuff from the AUR?
I'd venture most people actually don't review pkgbuild; especially on upgrades.
The other issue of course is that, the devils in the details. Fetch a binary as part of the installation (or, just fetch a binary itself, no compilation) then you're boned.
You can even hide nefarious code in the compilation/build steps, Jia Tan style.
Cool theory, but the same reason I pull my shoes off by standing on my heel and pulling, despite it saving me no time (I will have to untie them anyway when I put them on again).
Humans are short sighted, want to solve the situation immediately and will do the laziest thing possible to accomplish a given task.
Call me naive (I don't use arch) but if that's the only change then what's the point releasing the change? Unless pkgver refers to an external dependency or a binary, in which case you might as well say reading the changelog counts as reading the code
Usually you concat them to form the GitHub tarball URL or similar, so on updates you only review the version/hash bumps, as on install you've validated the right GitHub organization/domain already.
So on install, you review ideally everything, but at least the URL/organization/domain. Then on updates, you've already validated them, so the pkgver bump is the only thing of interest.
The version string is used to build an external URL.
You're right, I don't audit every line of code in new versions of Firefox/Chrome/etc. I chose to trust the download URL when I first installed that package. Then on updates, I can check at a glance that the script hasn't changed to point to another URL or in other suspicious ways.
There are two possible threats here: "random AUR user" and "Google". I'm protected from the former deciding to bundle malware, but not the latter.
AUR packages consist of packaging a third-party software (whether binary or source built as part of the package) for use on Arch.
Most updates are just bumping the upstream software version and its checksum, as GP describes, and yes arguably you should be reviewing the change to that software too, but that's a separate threat. And it may be a proprietary binary, in which case on update you've already decided to trust the third-party, so the diff shows you that nothing has changed in that regard, the trusted party simply released a new opaque version.
> I'd venture most people actually don't review pkgbuild; especially on upgrades.
No, I'm sorry but who on earth installs random software from random strangers, without a single step of validating before giving it access to (presumably) the same computer you do banking on?
> The other issue of course is that, the devils in the details. Fetch a binary as part of the installation (or, just fetch a binary itself, no compilation) then you're boned.
Sure, that's why when you review the PKGBUILD, and instead of it using the official GitHub organization / domain (which you of course validate) for downloading the binary/source, you don't install it.
I agree it's still vulnerable to Jia Tan style attacks, but installing from AUR is essentially "curl http://random-website.com/script.sh | bash", and reviewing a PKGBUILD takes a few seconds, and stop/cancel if something is sus, it's really that easy.
> No, I'm sorry but who on earth installs random software from random strangers, without a single step of validating before giving it access...
Realistically most users?
It's already quite a technical barrier to run Arch Linux, and the knowledge to further know about/understand PKGBUILD can only comes with time and is yet another layer filtering people's ability to know how to even try to catch something malicious.
Now consider the layer of even experienced user that's in a bit of rush and doesn't have time to review the full diffs they're upgrading to.
Ralistically it's nearly statistically impossible that 100% of users would be able to all catch and block a given exploit themselves. A shared responsibility model of security [1] comes to mind, and while it's great for users to be active participants in their security, their action/awareness should be a last resort. I wouldn't blame the user.
> doesn't have time to review the full diffs they're upgrading to.
Again, why are people expecting that you need to review the entire thing? You don't have to, you have to look at the download source (a github organization or a domain name or a cdn bucket) and look at what dependencies/other junk it pulls in. Usually this is 3-5 lines at max, and usually only the binary/source is taken from github/server, the rest is from official Arch repositories.
Of course it's unrealistic to expect users to review 100% of the code they run on their machine, that's why no one is expecting this, nor claiming that users should do this. But reviewing 3-5 lines when installing software from literal strangers on the internet, isn't so much to ask.
Many packages are _way_ more complex than 3-5 lines to review. To take an example (perhaps a bit extreme, but realistic as many nVidia users _have_ to install it), check nvidia-580xx-dkms
Every patch (which runs in kernel space) may of course contain backdoors, so you'd have to review them. Every install line in the PKGBUILD may be installing a malware.
Of course it is _possible_ to review all of it, but clearly not simple, even for a fairly technical user.
Sure, if you assume that every attack would be as glaring as the ones we've seen before, that makes it easier. But think of an attack at the level of the xz one and virtually no one would catch it.
> It's already quite a technical barrier to run Arch Linux
People are supposed to clear that barrier by studying the Arch Wiki and other technical materials so that they understand what they are doing, why they are doing it, and the risks involved.
When they install random software pushed by random people they know nothing about much less trust without even so much as a glance at the PKGBUILD, they're not overcoming any barriers, they're YOLOing their personal computers and hoping it turns out fine.
Taking the same example as above, if you have any nVidia card pascal or older, you have no other choice than using AUR for your driver; it was literally advertised as such on the Arch Linux home page :
>Users with GTX 10xx series and older cards must switch to the legacy proprietary branch to maintain support:
> Install nvidia-580xx-dkms from the AUR
And those are packages very difficult to thoroughly review. At some point, just saying "users have been warned, too bad" might hold from a _legal_ point of view, but I feel like it is deflecting the blame a bit too much.
> No, I'm sorry but who on earth installs random software from random strangers, without a single step of validating before giving it access to (presumably) the same computer you do banking on?
I would assume essentially everyone? `curl https://random-website.com/script.sh | sh` is one of the most common way of installing software outside of perhaps Flatpak. AppImage is essentially the same as piping a script from the internet into bash.
> reviewing a PKGBUILD takes a few seconds
This assumes a naive attack that is easily visible from the PKGBUILD. Unless the attacker makes no effort to hide their activity, the PKGBUILD will look perfectly ordinary while still installing malware.
What PKGBUILD referencing official sources that been attacked would not be easily visible? The second the source changes away from official sources, you stop installing from it. It's one line you have to review, usually pointing to either a Github release or a CDN/download host under the official domain.
PKGBUILDs are more powerful than that. They might download dependencies for the build from a package registry like npm, pypi, or crates, they might download and apply patches, and run arbitrary build scripts.
Changes to some of that might be easy to catch, but if the PKGBUILD depends on external resources, it can be quite hard to audit. I am not saying this is good practice, but you can see these sort of things happen all the time on the AUR.
Yes, indeed they might, but if you start seeing sketchy stuff like that, then don't continue, I'm not sure I understand what's hard here. Or do continue, but then if those are AUR packages themselves, review them as such. Personally I just ignore anything not built from official binaries/sources.
If the PKGBUILD depends on more stuff then just officially available things, don't blindly install it and wish for the best. Just like if you "curl | bash" install something, you do at least look at the URL right? It takes a couple of seconds, maybe tens of seconds if you don't recognize the domain/github organization since before.
Yes, contrary to popular belief, even I am affected by context and change what I converse about as the discussions topic and context drift, this is called having a conversation.
I'll stand by that I think most Arch Linux users, extrapolated from the people I know also run it, review at least the domain/GitHub organization for random AUR packages, and all of them are aware of what the AUR actually is, and is for.
I don't think most people here on HN who are clearly misunderstanding what the AUR is, are actually Arch users, or if they are, they haven't read the header that been visible since forever on the AUR.
> No, I'm sorry but who on earth installs random software from random strangers
Everyone. People who don't tend to build from source and the convenience of package managers has outweighed this for most people for years now. Even if you review the code do you review every library it pulls in? Because I have to tell you I don't believe you, and if most people did do that then these supply chain attacks would be minor news.
I can tell you misunderstand what the AUR actually is. It's not a package registry maintained by anyone, and it's also not limited to "build from source" or whatever. It's more like npm if anything, if you're familiar with that distribution mechanism.
> It's more like npm if anything, if you're familiar with that distribution mechanism.
True, but I'd reverse the order. It's npm, pip, cargo, gem and all the others that are like the AUR. They're every bit as dangerous as the AUR, yet the AUR is the only one that singles itself out by warning people of the danger.
Anyone can sign up and push packages. I've literally done that myself, even though nobody in the Arch Linux community knows or trusts me. AUR is the only one where users are repeatedly made aware of this danger. All the others normalize and encourage importing random unvetted dependencies for the sake of developer convenience.
Yes, and this is why npm is never installed on my hosts.
Folks podman is good. Very, very good. You want good developer ergonomics? Use dev containers. The cost of pulling npm packages Willy nilly on the host is not worth it!
Potential malware will share a kernel with the host. One exploit and we're owned. Virtual machines are the better solution. Infinitely smaller attack surface. If they crack hardware hypervisors, it means the entire industry is in deep shit, not just us.
I went so far as to code up my own development virtual machine orchestration software. Now I'm making a custom Rust network stack for it.
I misunderstood your comment more and in that case I apologise. I thought you meant you review all packages you install or upgrade from any source.
In my case I'm guilty of not checking brew updates (even from casks) on Mac, but I'm also guilty of only updating them every couple of months so it probably balances out.
> No, I'm sorry but who on earth installs random software from random strangers, without a single step of validating before giving it access to (presumably) the same computer you do banking on?
Well, for one almost everyone on Windows. That’s changing with winget and such but the standard Linux method is still an anomaly in desktop computing as a whole.
Those users do look at the domain/URL though, where they are getting it from. The way to do that when using AUR, which they are explicit about, is to review the download source from PKGBUILD, which would be the same as a Windows user looking at the addressbar when they download something.
I know it's hard to believe, but many users, even Windows ones, actually check if they're on the right website/in the right GitHub organization, before downloading binaries.
> No, I'm sorry but who on earth installs random software from random strangers, without a single step of validating before giving it access to (presumably) the same computer you do banking on?
That would be every day that I run apt-get, pkg add, brew install, or download a random .exe/.dmg to update my machine.
A decade of telling people that if they don't update constantly they're at risk, also affects us computer people.
Being able (and willing) to inspect source tree is the exception here, not the standard.
> That would be every day that I run apt-get, pkg add, brew install, or download a random .exe/.dmg to update my machine.
Everything except that last part, are not "random strangers on the internet", those are maintainers who maintain the registry/repository you've chosen to use. And when you use those, they use "mirrors" hosted on their own infrastructure.
AUR is a very different thing from this, where essentially anyone, at any time, can become a "mirror" and host whatever code they want, with zero review.
I obviously don't review stuff when I use pacman and official Arch package repositories, because again, those aren't "Wild west of random binaries", like the AUR.
Realistically, maintainers are strangers on the internet to me, and crucially, it is common to add unofficial repos, as well as use non-platform package managers like npm, cargo and pip.
Personally, "strangers under a banner of long-standing organization XYZ" is different to me than "jkb_25342" on GitHub with one repository, with no source and only binary releases. Realistically, of course you're right, I don't know everyone who maintain the software I work, but I am familiar with the organization. Basically, you need to figure out where you can place your trust, which again for me personally, depends on a lot more things than "met face to face and know who they are".
I get the impression many of the commenters either don’t know what the AUR is, or have no idea how it works (the AUR guidelines are on top of the front page…)
The latter might be a problem caused by hosting it on the archlinux.org domain: it creates a *feeling* of trust, for the uninitiated.
> I get the impression many of the commenters either don’t know what the AUR is, or have no idea how it works (the AUR guidelines are on top of the front page…)
Yup, 100%. Probably I've spent way too long time trying to make people (in the various AUR submissions here on HN) realize that the AUR probably isn't what they think it is, as most replies/comments about the AUR seems misinformed about what it is for and how it works.
> Me. Who reads the source code of every program they run?
No one. Who codes their own operating systems before they launch a calculator on their own computer? No one as well. Why the irrelevant questions? They're all very different things.
You literally have to review one line, that points to a remote URL somewhere, that's it. If it's wrong/sus, don't install it, you don't even have to review more than that.
Thank you for explaining, since in the year-plus of using Arch that has never been shown in a tutorial or in the OS itself. "paru <package>" is all I've known, and the AUR wiki makes it sounds like 15 steps of compile from source.
Have been reading source code for over 15 years now. I read the source code of a lot of software, just for curiosity's sake. I go out of my way to read the source code of random scripts I find laying about and that I want to run, and I do so before running them. PKGBUILDs are in that category, as are random scripts people throw on GitHub.
Only difference is now I ask AI models to read the source too. Chances of malware slipping by both myself and AI is lower than it slipping by either in isolation.
> No, I'm sorry but who on earth installs random software from random strangers, without a single step of validating before giving it access to (presumably) the same computer you do banking on?
I personally know nobody on either the Fedora or KDE teams. So I shouldn't do my banking on my Fedora KDE box?
It'd have been hard for anyone else to make it clearer to other's, that you don't actually understand what the AUR is nor how PKGBUILDs work. I'm not saying people should review the code/source/binary itself, I'm saying that people do tend to look at the URL/domain at least once, a glance, before installing binaries.
I review the PKGBUILD often, but not always. The majority of the time when I do, it amounts to seeing a URL change. If I actually do check the URL it points to, it's just to verify it's official/the actual repo or source I intended to trust.
I was honestly never very worried about the attack vectors that are visible in PKGBUILD. Historically, with the rather popular AUR packages I install, any attack would be noticed rather quickly, which limits would-be attackers to those who don't care who they hack and don't mind it being short-lived. The threats I was more worried about were those from more malicious/advanced sources that would attack more subtly upstream – but if I've already decided to download and run a precompiled binary from a repo, I've already decided to accept that risk.
In other words, in the past, I relied mainly on the goodness and vigilance of the community, only occasionally investing time to check myself on less mainstream packages or repos.
Was this ideal? No. Was it sufficiently responsible? As it was my own machine and my own data at risk, I believe so. And to be honest, I've not had a single problem in over a decade of doing so.
> I wish I had a clear operating system to switch to for safety and the benefits that come with the AUR or the Nix ecosystem.
Can't have it both ways.
Your packages can come from a small number of trusted individuals who maintain the software distribution. Naturally, this limits your choices to the packages they personally maintain. If you need something outside of that set, you need to ask them to include it or source it yourself.
Alternatively, your packages can come from a software repository that allows internet randoms to push literally anything. That expands your selection to all software ever created, which includes malware since nobody's doing the work to filter that stuff out.
Arch Linux offers both paradigms. Make an informed decision.
I used alpine linux and it looks pretty easy to setup your own repository, including build scripts for packages. I now use OpenBSD and the port systems of the BSD (each are different BTW) make it also easy to add extra software.
The explicit expectation with the AUR has always been that you can't blindly trust the PKGBUILD files. It's more like running an installer from a random website on Windows than it is to using official distro repositories. I think the wiki also always advised against using AUR helper tools that blur the lines between official repositories and the AUR.
The Arch wiki explicitly links to the AUR for lots of things, but the prime example is probably the NVIDIA page - https://wiki.archlinux.org/title/NVIDIA - this page is going to be massively viewed, and if you have Pascal or older architecture the suggested driver is from, you guessed it, the AUR.
Nowhere on this page does it suggest that the AUR is at all untrustworthy.
Sadly, this is the future of a lot of FLOSS development unless people start to see their projects as their legacy instead of a simple hobby or a way to scratch an itch.
Once your project obtains any sort of real notoriety, it starts having a blast radius, and you need to have at least some idea of who is pushing what to it when and why. The Linux kernel has a pretty good system of this for the time being with Linus being BDFL. There's governance, there's a standard, and most importantly, there are resources coming in.
If your wares are being used by large groups of people you've never met and in ways you cannot possibly imagine, then it's time to start doing the boring paperwork and political parts of managing the community around it, not just pushing commits and adding features.
Linus gets paid to be a BDFL. Pay me enough and I too will sit down and benevolently dictate things all day long. Until then, the world will have to make do with the blast radius.
I'd love to set one up, but I don't think it's enough... That's not the whole story. I bet the actual fundraising is a full time job unto itself.
I joined the GitHub Sponsors thing and somwhow got a few sponsors, but it wasn't even close to "quit $DAYJOB and focus on free software" territory. Achieving success here would be a dream come true but even the biggest open source projects aren't making anywhere close to a good individual salary. As the biggest free software project ever, Linux is always the exception.
lmao, no. start paying people for FLOSS development, and maybe then we can talk about holding them accountable for their projects. as long as there are no contracts and no payment, there’s no point in making demands of these people.
Doing the boring paperwork to create a foundation or something similar is a step towards things like contracts and payment. Otherwise you're just a dude with a computer and how in the hell is my department supposed to pay you for services?
The existence of such organizational qualities should be something we look out for as software engineers when picking out dependencies for our projects.
Well, I guess I'll avoid updating for the next few days. A bit worrisome that I did so last night.
I wish I had a clear operating system to switch to for safety and the benefits that come with the AUR or the Nix ecosystem. Unfortunately it seems that the era of being able to naively and gratefully trust in the armies of volunteer maintainers is over.
LLMs make large scale and long-term attacks easy and cheap. You could (and if I was a three letter agency, I would probably do so!) maintain ten thousand packages as three thousand separate "individuals" for years before cashing in the trust you've built up.
> naively and gratefully trust in the armies of volunteer maintainers is over
I'm almost scared to ask, did you not even review the PKGBUILD or anything else before installing stuff from the AUR?
Nixpkgs has a completed different model compared to AUR, the changes that end up in nixpkgs are all reviewed by maintainers, while AUR is literally free-for-all "anyone can push anything at any time", I don't think you ever could "naively and gratefully trust" AUR in the way you might have been.
> did you not even review the PKGBUILD or anything else before installing stuff from the AUR?
I'd venture most people actually don't review pkgbuild; especially on upgrades.
The other issue of course is that, the devils in the details. Fetch a binary as part of the installation (or, just fetch a binary itself, no compilation) then you're boned.
You can even hide nefarious code in the compilation/build steps, Jia Tan style.
Why especially upgrades? Upgrades are way easier to review than new installs. Most diffs I see are just these two lines:
It takes like 5 seconds to read and press Y.Cool theory, but the same reason I pull my shoes off by standing on my heel and pulling, despite it saving me no time (I will have to untie them anyway when I put them on again).
Humans are short sighted, want to solve the situation immediately and will do the laziest thing possible to accomplish a given task.
pop each lace down one eyelet and you'll never have to untie them again if the heel is both sturdy and forgiving enough
yeah but then it doesn't feel 'right'
Call me naive (I don't use arch) but if that's the only change then what's the point releasing the change? Unless pkgver refers to an external dependency or a binary, in which case you might as well say reading the changelog counts as reading the code
Usually you concat them to form the GitHub tarball URL or similar, so on updates you only review the version/hash bumps, as on install you've validated the right GitHub organization/domain already.
Babashka has this for example (https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=babas...):
So on install, you review ideally everything, but at least the URL/organization/domain. Then on updates, you've already validated them, so the pkgver bump is the only thing of interest.The version string is used to build an external URL.
You're right, I don't audit every line of code in new versions of Firefox/Chrome/etc. I chose to trust the download URL when I first installed that package. Then on updates, I can check at a glance that the script hasn't changed to point to another URL or in other suspicious ways.
There are two possible threats here: "random AUR user" and "Google". I'm protected from the former deciding to bundle malware, but not the latter.
AUR packages consist of packaging a third-party software (whether binary or source built as part of the package) for use on Arch.
Most updates are just bumping the upstream software version and its checksum, as GP describes, and yes arguably you should be reviewing the change to that software too, but that's a separate threat. And it may be a proprietary binary, in which case on update you've already decided to trust the third-party, so the diff shows you that nothing has changed in that regard, the trusted party simply released a new opaque version.
> I'd venture most people actually don't review pkgbuild; especially on upgrades.
No, I'm sorry but who on earth installs random software from random strangers, without a single step of validating before giving it access to (presumably) the same computer you do banking on?
> The other issue of course is that, the devils in the details. Fetch a binary as part of the installation (or, just fetch a binary itself, no compilation) then you're boned.
Sure, that's why when you review the PKGBUILD, and instead of it using the official GitHub organization / domain (which you of course validate) for downloading the binary/source, you don't install it.
I agree it's still vulnerable to Jia Tan style attacks, but installing from AUR is essentially "curl http://random-website.com/script.sh | bash", and reviewing a PKGBUILD takes a few seconds, and stop/cancel if something is sus, it's really that easy.
> No, I'm sorry but who on earth installs random software from random strangers, without a single step of validating before giving it access...
Realistically most users?
It's already quite a technical barrier to run Arch Linux, and the knowledge to further know about/understand PKGBUILD can only comes with time and is yet another layer filtering people's ability to know how to even try to catch something malicious.
Now consider the layer of even experienced user that's in a bit of rush and doesn't have time to review the full diffs they're upgrading to.
Ralistically it's nearly statistically impossible that 100% of users would be able to all catch and block a given exploit themselves. A shared responsibility model of security [1] comes to mind, and while it's great for users to be active participants in their security, their action/awareness should be a last resort. I wouldn't blame the user.
[1] https://docs.cloud.google.com/architecture/framework/securit...
> doesn't have time to review the full diffs they're upgrading to.
Again, why are people expecting that you need to review the entire thing? You don't have to, you have to look at the download source (a github organization or a domain name or a cdn bucket) and look at what dependencies/other junk it pulls in. Usually this is 3-5 lines at max, and usually only the binary/source is taken from github/server, the rest is from official Arch repositories.
Of course it's unrealistic to expect users to review 100% of the code they run on their machine, that's why no one is expecting this, nor claiming that users should do this. But reviewing 3-5 lines when installing software from literal strangers on the internet, isn't so much to ask.
Many packages are _way_ more complex than 3-5 lines to review. To take an example (perhaps a bit extreme, but realistic as many nVidia users _have_ to install it), check nvidia-580xx-dkms Every patch (which runs in kernel space) may of course contain backdoors, so you'd have to review them. Every install line in the PKGBUILD may be installing a malware. Of course it is _possible_ to review all of it, but clearly not simple, even for a fairly technical user.
Sure, if you assume that every attack would be as glaring as the ones we've seen before, that makes it easier. But think of an attack at the level of the xz one and virtually no one would catch it.
> It's already quite a technical barrier to run Arch Linux
People are supposed to clear that barrier by studying the Arch Wiki and other technical materials so that they understand what they are doing, why they are doing it, and the risks involved.
When they install random software pushed by random people they know nothing about much less trust without even so much as a glance at the PKGBUILD, they're not overcoming any barriers, they're YOLOing their personal computers and hoping it turns out fine.
> I wouldn't blame the user.
I would. They were warned.
Taking the same example as above, if you have any nVidia card pascal or older, you have no other choice than using AUR for your driver; it was literally advertised as such on the Arch Linux home page :
>Users with GTX 10xx series and older cards must switch to the legacy proprietary branch to maintain support: > Install nvidia-580xx-dkms from the AUR
And those are packages very difficult to thoroughly review. At some point, just saying "users have been warned, too bad" might hold from a _legal_ point of view, but I feel like it is deflecting the blame a bit too much.
[dead]
> No, I'm sorry but who on earth installs random software from random strangers, without a single step of validating before giving it access to (presumably) the same computer you do banking on?
I would assume essentially everyone? `curl https://random-website.com/script.sh | sh` is one of the most common way of installing software outside of perhaps Flatpak. AppImage is essentially the same as piping a script from the internet into bash.
> reviewing a PKGBUILD takes a few seconds
This assumes a naive attack that is easily visible from the PKGBUILD. Unless the attacker makes no effort to hide their activity, the PKGBUILD will look perfectly ordinary while still installing malware.
What PKGBUILD referencing official sources that been attacked would not be easily visible? The second the source changes away from official sources, you stop installing from it. It's one line you have to review, usually pointing to either a Github release or a CDN/download host under the official domain.
PKGBUILDs are more powerful than that. They might download dependencies for the build from a package registry like npm, pypi, or crates, they might download and apply patches, and run arbitrary build scripts.
Changes to some of that might be easy to catch, but if the PKGBUILD depends on external resources, it can be quite hard to audit. I am not saying this is good practice, but you can see these sort of things happen all the time on the AUR.
Yes, indeed they might, but if you start seeing sketchy stuff like that, then don't continue, I'm not sure I understand what's hard here. Or do continue, but then if those are AUR packages themselves, review them as such. Personally I just ignore anything not built from official binaries/sources.
If the PKGBUILD depends on more stuff then just officially available things, don't blindly install it and wish for the best. Just like if you "curl | bash" install something, you do at least look at the URL right? It takes a couple of seconds, maybe tens of seconds if you don't recognize the domain/github organization since before.
Ah but you switched now from "I don't think people do this" to "people shouldn't do this". You're right about the latter but wrong about the former.
Yes, contrary to popular belief, even I am affected by context and change what I converse about as the discussions topic and context drift, this is called having a conversation.
I'll stand by that I think most Arch Linux users, extrapolated from the people I know also run it, review at least the domain/GitHub organization for random AUR packages, and all of them are aware of what the AUR actually is, and is for.
I don't think most people here on HN who are clearly misunderstanding what the AUR is, are actually Arch users, or if they are, they haven't read the header that been visible since forever on the AUR.
> dependencies for the build from a package registry like npm, pypi, or crates, it might download and apply patches, and run arbitrary build scripts
You're supposed to review every single one of those too.
> `curl https://random-website.com/script.sh | sh` is one of the most common way of installing software
Sure wish GitHub READMEs hadn't normalized this.
> No, I'm sorry but who on earth installs random software from random strangers
Everyone. People who don't tend to build from source and the convenience of package managers has outweighed this for most people for years now. Even if you review the code do you review every library it pulls in? Because I have to tell you I don't believe you, and if most people did do that then these supply chain attacks would be minor news.
I can tell you misunderstand what the AUR actually is. It's not a package registry maintained by anyone, and it's also not limited to "build from source" or whatever. It's more like npm if anything, if you're familiar with that distribution mechanism.
> It's more like npm if anything, if you're familiar with that distribution mechanism.
True, but I'd reverse the order. It's npm, pip, cargo, gem and all the others that are like the AUR. They're every bit as dangerous as the AUR, yet the AUR is the only one that singles itself out by warning people of the danger.
Anyone can sign up and push packages. I've literally done that myself, even though nobody in the Arch Linux community knows or trusts me. AUR is the only one where users are repeatedly made aware of this danger. All the others normalize and encourage importing random unvetted dependencies for the sake of developer convenience.
Yes, and this is why npm is never installed on my hosts.
Folks podman is good. Very, very good. You want good developer ergonomics? Use dev containers. The cost of pulling npm packages Willy nilly on the host is not worth it!
> podman
Potential malware will share a kernel with the host. One exploit and we're owned. Virtual machines are the better solution. Infinitely smaller attack surface. If they crack hardware hypervisors, it means the entire industry is in deep shit, not just us.
I went so far as to code up my own development virtual machine orchestration software. Now I'm making a custom Rust network stack for it.
I misunderstood your comment more and in that case I apologise. I thought you meant you review all packages you install or upgrade from any source.
In my case I'm guilty of not checking brew updates (even from casks) on Mac, but I'm also guilty of only updating them every couple of months so it probably balances out.
> No, I'm sorry but who on earth installs random software from random strangers, without a single step of validating before giving it access to (presumably) the same computer you do banking on?
Well, for one almost everyone on Windows. That’s changing with winget and such but the standard Linux method is still an anomaly in desktop computing as a whole.
Those users do look at the domain/URL though, where they are getting it from. The way to do that when using AUR, which they are explicit about, is to review the download source from PKGBUILD, which would be the same as a Windows user looking at the addressbar when they download something.
I know it's hard to believe, but many users, even Windows ones, actually check if they're on the right website/in the right GitHub organization, before downloading binaries.
> No, I'm sorry but who on earth installs random software from random strangers, without a single step of validating before giving it access to (presumably) the same computer you do banking on?
That would be every day that I run apt-get, pkg add, brew install, or download a random .exe/.dmg to update my machine.
A decade of telling people that if they don't update constantly they're at risk, also affects us computer people.
Being able (and willing) to inspect source tree is the exception here, not the standard.
> That would be every day that I run apt-get, pkg add, brew install, or download a random .exe/.dmg to update my machine.
Everything except that last part, are not "random strangers on the internet", those are maintainers who maintain the registry/repository you've chosen to use. And when you use those, they use "mirrors" hosted on their own infrastructure.
AUR is a very different thing from this, where essentially anyone, at any time, can become a "mirror" and host whatever code they want, with zero review.
I obviously don't review stuff when I use pacman and official Arch package repositories, because again, those aren't "Wild west of random binaries", like the AUR.
Realistically, maintainers are strangers on the internet to me, and crucially, it is common to add unofficial repos, as well as use non-platform package managers like npm, cargo and pip.
It’s all strangers stuff
Personally, "strangers under a banner of long-standing organization XYZ" is different to me than "jkb_25342" on GitHub with one repository, with no source and only binary releases. Realistically, of course you're right, I don't know everyone who maintain the software I work, but I am familiar with the organization. Basically, you need to figure out where you can place your trust, which again for me personally, depends on a lot more things than "met face to face and know who they are".
I get the impression many of the commenters either don’t know what the AUR is, or have no idea how it works (the AUR guidelines are on top of the front page…)
The latter might be a problem caused by hosting it on the archlinux.org domain: it creates a *feeling* of trust, for the uninitiated.
> I get the impression many of the commenters either don’t know what the AUR is, or have no idea how it works (the AUR guidelines are on top of the front page…)
Yup, 100%. Probably I've spent way too long time trying to make people (in the various AUR submissions here on HN) realize that the AUR probably isn't what they think it is, as most replies/comments about the AUR seems misinformed about what it is for and how it works.
> for the uninitiated
Arch Linux is not for the uninitiated.
Me. Who reads the source code of every program they run?
I've learned not to trust the AUR because the barrier to malice is lower, but I run system updates every other day.
> Me. Who reads the source code of every program they run?
No one. Who codes their own operating systems before they launch a calculator on their own computer? No one as well. Why the irrelevant questions? They're all very different things.
You literally have to review one line, that points to a remote URL somewhere, that's it. If it's wrong/sus, don't install it, you don't even have to review more than that.
Thank you for explaining, since in the year-plus of using Arch that has never been shown in a tutorial or in the OS itself. "paru <package>" is all I've known, and the AUR wiki makes it sounds like 15 steps of compile from source.
> Who reads the source code of every program they run?
Me. It's even easier now with AI.
So, you don't.
Have been reading source code for over 15 years now. I read the source code of a lot of software, just for curiosity's sake. I go out of my way to read the source code of random scripts I find laying about and that I want to run, and I do so before running them. PKGBUILDs are in that category, as are random scripts people throw on GitHub.
Only difference is now I ask AI models to read the source too. Chances of malware slipping by both myself and AI is lower than it slipping by either in isolation.
> No, I'm sorry but who on earth installs random software from random strangers, without a single step of validating before giving it access to (presumably) the same computer you do banking on?
I personally know nobody on either the Fedora or KDE teams. So I shouldn't do my banking on my Fedora KDE box?
It'd have been hard for anyone else to make it clearer to other's, that you don't actually understand what the AUR is nor how PKGBUILDs work. I'm not saying people should review the code/source/binary itself, I'm saying that people do tend to look at the URL/domain at least once, a glance, before installing binaries.
[dead]
I review the PKGBUILD often, but not always. The majority of the time when I do, it amounts to seeing a URL change. If I actually do check the URL it points to, it's just to verify it's official/the actual repo or source I intended to trust.
I was honestly never very worried about the attack vectors that are visible in PKGBUILD. Historically, with the rather popular AUR packages I install, any attack would be noticed rather quickly, which limits would-be attackers to those who don't care who they hack and don't mind it being short-lived. The threats I was more worried about were those from more malicious/advanced sources that would attack more subtly upstream – but if I've already decided to download and run a precompiled binary from a repo, I've already decided to accept that risk.
In other words, in the past, I relied mainly on the goodness and vigilance of the community, only occasionally investing time to check myself on less mainstream packages or repos.
Was this ideal? No. Was it sufficiently responsible? As it was my own machine and my own data at risk, I believe so. And to be honest, I've not had a single problem in over a decade of doing so.
That's clearly got to change now, though.
> the changes that end up in nixpkgs are all reviewed by maintainers
They review the “recipes”, sure. But I don’t know if I’d trust that every diff of the source of every package update is reviewed by them.
> I wish I had a clear operating system to switch to for safety and the benefits that come with the AUR or the Nix ecosystem.
Can't have it both ways.
Your packages can come from a small number of trusted individuals who maintain the software distribution. Naturally, this limits your choices to the packages they personally maintain. If you need something outside of that set, you need to ask them to include it or source it yourself.
Alternatively, your packages can come from a software repository that allows internet randoms to push literally anything. That expands your selection to all software ever created, which includes malware since nobody's doing the work to filter that stuff out.
Arch Linux offers both paradigms. Make an informed decision.
I agree one hundred percent! Doesn't mean I can't wish I could have it both ways :)
> the era of being able to naively and gratefully trust in the armies of volunteer maintainers is over
The maintainers you're supposed to trust are Arch Linux's actual staff made up of package maintainers, formerly known as trusted users.
AUR packages are maintained by randoms on the internet. Anyone can sign up and push a package.
I used alpine linux and it looks pretty easy to setup your own repository, including build scripts for packages. I now use OpenBSD and the port systems of the BSD (each are different BTW) make it also easy to add extra software.
The explicit expectation with the AUR has always been that you can't blindly trust the PKGBUILD files. It's more like running an installer from a random website on Windows than it is to using official distro repositories. I think the wiki also always advised against using AUR helper tools that blur the lines between official repositories and the AUR.
The Arch wiki explicitly links to the AUR for lots of things, but the prime example is probably the NVIDIA page - https://wiki.archlinux.org/title/NVIDIA - this page is going to be massively viewed, and if you have Pascal or older architecture the suggested driver is from, you guessed it, the AUR.
Nowhere on this page does it suggest that the AUR is at all untrustworthy.
Also see: https://news.ycombinator.com/item?id=49123208
for context, 2 days ago:
Arch Linux disables AUR package adoption (https://news.ycombinator.com/item?id=49123208)
Sadly, this is the future of a lot of FLOSS development unless people start to see their projects as their legacy instead of a simple hobby or a way to scratch an itch.
Once your project obtains any sort of real notoriety, it starts having a blast radius, and you need to have at least some idea of who is pushing what to it when and why. The Linux kernel has a pretty good system of this for the time being with Linus being BDFL. There's governance, there's a standard, and most importantly, there are resources coming in.
If your wares are being used by large groups of people you've never met and in ways you cannot possibly imagine, then it's time to start doing the boring paperwork and political parts of managing the community around it, not just pushing commits and adding features.
Linus gets paid to be a BDFL. Pay me enough and I too will sit down and benevolently dictate things all day long. Until then, the world will have to make do with the blast radius.
He gets paid because there's a foundation set up to direct resources around kernel development, including his compensation.
You can see the fiscal info around that foundation here [0]
I know it's boring paper bullsh*t but this is the sort of thing more people need to set up.
[0] https://projects.propublica.org/nonprofits/organizations/460...
I'd love to set one up, but I don't think it's enough... That's not the whole story. I bet the actual fundraising is a full time job unto itself.
I joined the GitHub Sponsors thing and somwhow got a few sponsors, but it wasn't even close to "quit $DAYJOB and focus on free software" territory. Achieving success here would be a dream come true but even the biggest open source projects aren't making anywhere close to a good individual salary. As the biggest free software project ever, Linux is always the exception.
lmao, no. start paying people for FLOSS development, and maybe then we can talk about holding them accountable for their projects. as long as there are no contracts and no payment, there’s no point in making demands of these people.
Doing the boring paperwork to create a foundation or something similar is a step towards things like contracts and payment. Otherwise you're just a dude with a computer and how in the hell is my department supposed to pay you for services?
The existence of such organizational qualities should be something we look out for as software engineers when picking out dependencies for our projects.
So another active attack? Does anyone have any other details?
https://news.ycombinator.com/item?id=49123208
That's the already-known attack being implied by "another".