How does Arch protect against supply chain attacks

xorsanitysanity · 2026-10-09 18:05:27

(concerning pacman safety)

Hi. arch noob here,

I've been experimenting and starting to rice (hoping this is the right terminology) my Arch setup but keep seeing things online about massive supply chain attacks where a repository owner is hacked or socially engineered so the stable or main branch of a given repository becomes backdoored or tampered with. I've legitimately enjoyed my experience thus far with Arch, but am concerned about such attacks and am wondering what Arch does to resist similar attacks. Is there something like a small holding period to see if there is obvious tampering with a package installed via pacman before it is released to the public? Is there something I can do to manually lower my risk? I've not touched the AUR yet for this reason.

Thanks,

xorsanitysanity

Lone_Wolf · 2026-10-09 19:02:39

None of the supply chain attacks this year have had any effect on archlinux official repos.

As for using AUR packages : I have over 50 installed and no issues at all.
But I'm one of the almost extinct (according to some) breed of people that check pkgbuild, aur commit history and upstream/download url before installing any aur package.

Supply chain attacks in general : stay away from npm, electron, flatpak and other stuff that relies on external deps unless you are sure those external deps are trustworthy.

seth · 2026-10-09 19:56:04

what Arch does to resist similar attacks. Is there something like a small holding period to see if there is obvious tampering with a package installed via pacman before it is released to the public

You do understand that in this case arch *is* the supply chain?
If one of the TUs goes rogue or Allan gets funny we're fucked.

where a repository owner is hacked or socially engineered so the stable or main branch of a given repository becomes backdoored

The xz disaster was technically not a supply-chain attack. Upstream (through a malicious de-facto maintainer change) turned evil.
The supply-chain aspect was because the git tree remained clean and only a manually provided tarball (not used by arch) was infected.

The xz-attack didn't work for various reasons against arch (in a nutshell: the target wasn't xz but sshd, that required sshd to link libsystemd, the openssh developers wisely refused and arch didn't accept/apply a downstream patch to override their decision either; to limit exposure the malware would not have activated on arch even iff it had built from the infected tarball) BUT you need to be aware that if upstream turns evil and laces 100k LOC with some nimble malware (the xz infection was very detection-evasive) you're essentially screwed as well.

To lower your risk you first need to understand what your individual risk is.
Who would invest how much to get what from infecting your system?

If you're Joe Desktopuser the worst thing somebody could probably do would be to encrypt your data for ransom.
Regardless of even that, there're only two kinds of users: those how have backups and those who had plans for backups.

If you're running a (private) server and worry about becoming a malware hub, limit the attack surface and monitor the system (behavioral analysis, intrusion detection, etc)

If you're a high-exposure target (government official etc.) you should frankly not be asking such questions in this place, but keep sensitive data air-gap'd.

Allan · 2026-10-10 02:20:53

seth wrote:

If one of the TUs goes rogue or Allan gets funny we're fucked.

I am very much open to bribes.

cfr · 2026-10-10 07:16:29

xorsanitysanity wrote:

I've legitimately enjoyed my experience thus far with Arch, but am concerned about such attacks and am wondering what Arch does to resist similar attacks.

I'm curious what alternative you are considering. It is quite difficult to function these days without any kind of connection to the internet.

xorsanitysanity · 2026-10-10 16:50:56

@Cymru (maybe @ mentions work here)

I've been distro hopping (mainly between debian forks and NixOS) trying to balance customization and security, my problem has nothing to do with internet. Rather, my problem is whether or not pacman does anything to protect against a source code repository (for example, bluetui) going evil. In this scenerio the repository (similar to the liblzma [I think] situation) has malicious code published to its source. Debian, from my understanding, will have a small holding period even for critical security updates just to ensure that the code hasn't become a password stealer or something worse. I understand that Arch is rolling release, I just wonder if there are any mechanisms provided by pacman or whatever mirror it pulls from I can utilize to protect myself against such threats.

Thanks for the swift responses

seth · 2026-10-10 17:46:55

@cfr is *from* Cymru
(And no, the @ does nothing special(

What makes you think waiting an arbitrary time will shield you or offer any kind of protection against upstream turning evil?
You can use the ALA to trail arch by a month or so, but that's security-by-wish-belief.

It's not really related but debian was one of the few infected distros because the accepted the malicious downstream patch linking sshd with libsystemd against the judgement of the ssh developers, they also once caused

loqs · 2026-10-10 18:55:12

A holding period only works if someone or something will be performing verification during the hold period. It works for git CI projects on the assumption that a compromised release will be detected within X days by some undefined mechanism and the releases yanked and all releases more than X days old should be not be compromised.

headkase · 2026-10-11 03:30:19

Allan wrote:

seth wrote:
If one of the TUs goes rogue or Allan gets funny we're fucked.
I am very much open to bribes.

lol

mpan · 2026-10-11 04:03:39

The bribes do not work well in Arch community. Some package maintainers were bribed with donuts or cat pictures, but so far they failed to deliver supply chain attacks. Microsoft’s Npm is much better at that (see AUR situation earlier this year). Jia Tan managed to get into major companies’ repos, but our package maintainers forgot to open doors for them. Completely useless. I don’t know how FOSS can continue with people who can’t even properly process bribes. /s

seth · 2026-10-11 07:47:44

https://bbs.archlinux.org/viewtopic.php … 1#p2113111

From my experience the main problem is that while the fees are reasonable, you're also required to actually watch…

Arch Linux

#1 2026-10-09 18:05:27

How does Arch protect against supply chain attacks

#2 2026-10-09 19:02:39

Re: How does Arch protect against supply chain attacks

#3 2026-10-09 19:56:04

Re: How does Arch protect against supply chain attacks

#4 2026-10-10 02:20:53

Re: How does Arch protect against supply chain attacks

#5 2026-10-10 07:16:29

Re: How does Arch protect against supply chain attacks

#6 2026-10-10 16:50:56

Re: How does Arch protect against supply chain attacks

#7 2026-10-10 17:46:55

Re: How does Arch protect against supply chain attacks

#8 2026-10-10 18:55:12

Re: How does Arch protect against supply chain attacks

#9 2026-10-11 03:30:19

Re: How does Arch protect against supply chain attacks

#10 2026-10-11 04:03:39

Re: How does Arch protect against supply chain attacks

#11 2026-10-11 07:47:44

Re: How does Arch protect against supply chain attacks

Board footer