I’ve long since been bothered by these blame deflections in the tech world. No one is reading the source for everything they install the same way no one is reading the full terms and conditions...
Exemplary
The only secure way to use the Arch User Repository is by reviewing every PKGBUILD.
I’ve long since been bothered by these blame deflections in the tech world. No one is reading the source for everything they install the same way no one is reading the full terms and conditions for every service they use. But whenever something goes wrong the blame deflection happens and it’s the users fault for not doing the impossible to avoid it.
Realistically we need systematic protections and checks rather than loading all the responsibility on to the user. Programs should be sandboxed as much as possible, all package maintainers should require checks and 2FA, etc. Programs should be given secure storage vaults they can drop things like auth tokens in where other programs can’t read them.
How is this blame deflection? The protections you're describing are reasonable, but they apply to a fundamentally different repo than the AUR, which is very specifically not a trusted distribution...
How is this blame deflection? The protections you're describing are reasonable, but they apply to a fundamentally different repo than the AUR, which is very specifically not a trusted distribution channel. This isn't the same as installing from a distro's default repositories. User review is the main security mechanism.
It’s larger than just the AUR, the way the average person uses Linux is deeply insecure, half the projects advise you to pipe curl to bash to install. Distros are built on a security model which...
It’s larger than just the AUR, the way the average person uses Linux is deeply insecure, half the projects advise you to pipe curl to bash to install. Distros are built on a security model which hasn’t been useful since the 90s.
Really the advice should be to stay away from the AUR because it’s fundamentally insecure, rather than telling people to review every build script which people just won’t do.
If Linux distros want to be actually secure in the modern day they need to assume the user isn’t auditing every line of code they run and should contain malware so it doesn’t have the ability to steal data from other apps.
I would be 100% agreeing with you if this had happened to literally any other distro, but you cannot tell me an arch user running unvetted scripts is not responsible for their actions. That is...
I would be 100% agreeing with you if this had happened to literally any other distro, but you cannot tell me an arch user running unvetted scripts is not responsible for their actions. That is ludicrous.
Yes, plenty of things can and should be improved in the broader Linux world, but we're talking about a niche of a niche of a niche that is very different from Ubuntu or Fedora, for example, where there is a claim of trust to precompiled packages in their repos. The documentation surrounding Arch and the AUR is very explicit in it being the user's responsibility to cover their own ass. I would be much more willing to have this conversation around the xz fiasco, for example.
AUR packages are user-produced content. These PKGBUILDs are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk.
Verify that the PKGBUILD and accompanying files are not malicious or untrustworthy.
Carefully check the PKGBUILD, any .install files, and any other files in the package's git repository for malicious or dangerous commands. If in doubt, do not build the package, and seek advice on the forums or mailing list. Malicious code has been found in packages before.
I don't think there's really a secure way of getting software that doesn't involve trust. It goes beyond distros as most developers will just pull down code and run it on their usually highly...
I don't think there's really a secure way of getting software that doesn't involve trust. It goes beyond distros as most developers will just pull down code and run it on their usually highly privileged machines. Since you can basically get code execution going by someone runninggit status in a repo (commonly done to get a nice status line), you can't even trust an "inert" repo. That is essentially the first command I run after git clone and it's basically muscle memory at this point! TBH for most users at this point never leaving the walled garden for the bazaar is probably advisable. For devs I think we need to rethink dependency management fundamentally. The supply chains attacks the last few months should be enough to convince even non paranoid CTO/CIOs that dependencies are bad. It's either that or maybe run organisations with an acceptance that you are breached (which might be a good idea anyway).
I'm not sure I agree. I don't use arch, but isn't this basically akin to downloading and running a script or a binary someone shared online? Yeah, it's pretty expected that you either verify the...
I'm not sure I agree. I don't use arch, but isn't this basically akin to downloading and running a script or a binary someone shared online? Yeah, it's pretty expected that you either verify the source or the content and it's always been that way. Except it's even worse, you will get updates for these programs and they will also pull dependencies of their own...
It has since been resolved. The full list of affected packages is here.
As recently discussed on the Arch Mailing list there appears to have been a large coordinated attack on the AUR some time within the last 24 hours that seems to have resulted in a rather sizable amount of packages being contaminated with malware.
I wonder if the compromise involved taking over orphaned packages? A lot of the compromised packages look old - there's a lot of python2 packages for instance. And I know for a fact that...
I wonder if the compromise involved taking over orphaned packages? A lot of the compromised packages look old - there's a lot of python2 packages for instance. And I know for a fact that neovim-nvim-treesitter was recently abandoned due to a ahem slight feud.
Yes, as far as I understand it any account can adopt a package and push out changes. Until there is some kind of vetting process, timeout, or moderation, this isn't resolved. Brodie posted a good...
Yes, as far as I understand it any account can adopt a package and push out changes. Until there is some kind of vetting process, timeout, or moderation, this isn't resolved.
I don't use Arch, BTW. Honestly it feels like AI is basically about to kill open source. Or at least open source that isn't a small, tight niche of trusted people, which in a lot of ways is how it...
I don't use Arch, BTW.
Honestly it feels like AI is basically about to kill open source. Or at least open source that isn't a small, tight niche of trusted people, which in a lot of ways is how it should be.
At a complete guess, maybe we'll see key signing parties and webs of trust become more commonplace? Those wound up being unnecessary in an era where one could trust the integrity of the average...
At a complete guess, maybe we'll see key signing parties and webs of trust become more commonplace? Those wound up being unnecessary in an era where one could trust the integrity of the average contributor, but if the internet is all LLM bots ...
My presumption anymore is that the bad actors used AI unless explicitly stated otherwise. I may be mistaken in this case, but it's hard to imagine the scale of the breach was accomplished entirely...
My presumption anymore is that the bad actors used AI unless explicitly stated otherwise. I may be mistaken in this case, but it's hard to imagine the scale of the breach was accomplished entirely by humans working alone. It may just be me assuming that a botnet controlled by AI was brought to bear on this and in fact it was just 10 or 15 people with 100 or so packages to target apiece. Speculation on my part, for sure.
I’ve long since been bothered by these blame deflections in the tech world. No one is reading the source for everything they install the same way no one is reading the full terms and conditions for every service they use. But whenever something goes wrong the blame deflection happens and it’s the users fault for not doing the impossible to avoid it.
Realistically we need systematic protections and checks rather than loading all the responsibility on to the user. Programs should be sandboxed as much as possible, all package maintainers should require checks and 2FA, etc. Programs should be given secure storage vaults they can drop things like auth tokens in where other programs can’t read them.
How is this blame deflection? The protections you're describing are reasonable, but they apply to a fundamentally different repo than the AUR, which is very specifically not a trusted distribution channel. This isn't the same as installing from a distro's default repositories. User review is the main security mechanism.
It’s larger than just the AUR, the way the average person uses Linux is deeply insecure, half the projects advise you to pipe curl to bash to install. Distros are built on a security model which hasn’t been useful since the 90s.
Really the advice should be to stay away from the AUR because it’s fundamentally insecure, rather than telling people to review every build script which people just won’t do.
If Linux distros want to be actually secure in the modern day they need to assume the user isn’t auditing every line of code they run and should contain malware so it doesn’t have the ability to steal data from other apps.
I would be 100% agreeing with you if this had happened to literally any other distro, but you cannot tell me an arch user running unvetted scripts is not responsible for their actions. That is ludicrous.
Yes, plenty of things can and should be improved in the broader Linux world, but we're talking about a niche of a niche of a niche that is very different from Ubuntu or Fedora, for example, where there is a claim of trust to precompiled packages in their repos. The documentation surrounding Arch and the AUR is very explicit in it being the user's responsibility to cover their own ass. I would be much more willing to have this conversation around the xz fiasco, for example.
Arch User Repository - ArchWiki
I don't think there's really a secure way of getting software that doesn't involve trust. It goes beyond distros as most developers will just pull down code and run it on their usually highly privileged machines. Since you can basically get code execution going by someone running
git statusin a repo (commonly done to get a nice status line), you can't even trust an "inert" repo. That is essentially the first command I run after git clone and it's basically muscle memory at this point! TBH for most users at this point never leaving the walled garden for the bazaar is probably advisable. For devs I think we need to rethink dependency management fundamentally. The supply chains attacks the last few months should be enough to convince even non paranoid CTO/CIOs that dependencies are bad. It's either that or maybe run organisations with an acceptance that you are breached (which might be a good idea anyway).This is one of the reasons why developers and distro maintainers are going big on containerized applications like Snap and FlatPack.
I'm not sure I agree. I don't use arch, but isn't this basically akin to downloading and running a script or a binary someone shared online? Yeah, it's pretty expected that you either verify the source or the content and it's always been that way. Except it's even worse, you will get updates for these programs and they will also pull dependencies of their own...
It has since been resolved.
The full list of affected packages is here.
This won't be resolved until there is some kind of moderation process surrounding the adoption of orphaned packages.
I wonder if the compromise involved taking over orphaned packages? A lot of the compromised packages look old - there's a lot of python2 packages for instance. And I know for a fact that
neovim-nvim-treesitterwas recently abandoned due to a ahem slight feud.Yes, as far as I understand it any account can adopt a package and push out changes. Until there is some kind of vetting process, timeout, or moderation, this isn't resolved.
Brodie posted a good overview of it here.
See also “Atomic Arch”: Nearly 900 AUR Packages Backdoored with a Developer-Targeting Infostealer and eBPF Rootkit
I don't use Arch, BTW.
Honestly it feels like AI is basically about to kill open source. Or at least open source that isn't a small, tight niche of trusted people, which in a lot of ways is how it should be.
At a complete guess, maybe we'll see key signing parties and webs of trust become more commonplace? Those wound up being unnecessary in an era where one could trust the integrity of the average contributor, but if the internet is all LLM bots ...
Was AI involved in the compromise in some way besides AI API keys being one of the targets being scooped up?
My presumption anymore is that the bad actors used AI unless explicitly stated otherwise. I may be mistaken in this case, but it's hard to imagine the scale of the breach was accomplished entirely by humans working alone. It may just be me assuming that a botnet controlled by AI was brought to bear on this and in fact it was just 10 or 15 people with 100 or so packages to target apiece. Speculation on my part, for sure.