How safe is Arch against malware being added to official packages?

M-Reimer · 2026-08-01 16:09:29

Since the AUR attacks keep coming I'm asking myself how long it will take for the first "official" package being shipped with malware or better: How well protected Arch actually is against this scenario?

AUR more or less always told users to read the source code of PKGBUILDs before executing them. Everyone can upload on AUR and so packages should not be trusted.

The situation is clearly different for packages coming from the official repos. It requires some "onboarding process" for new people to be allowed publishing there.

But isn't this still a risk? While on AUR you only get sourcecode and so it at least is possible to review that before executing, as far as I know Arch packages are still compiled on the individual PCs of Arch team members. So it is not impossible that a PKGBUILD without any suspicous stuff is pushed to GIT while the compiled binary still has something malicious in it?

Unfortunately there still seems to be no build machine which auto-builds PKGBUILDS, created by maintainers. This would prevent against something like this from ever happening.

Another way to verify that a package actually was built exactly how it is described in the PKGBUILD would be reproducible builds. But so far there still are many packages that can not be built that way.

So long story short: What are the lines of defence in place against malware packages in official repositories? Is it really just "trust" or is there something more substantial in place?

Last edited by M-Reimer (2026-08-01 16:11:45)

5hridhyan · 2026-08-01 17:32:04

Is it really just "trust" or is there something more substantial in place?

Humans? No "Human being" can be trusted 100% btw.
Yes. Official repos can be infected. Possible scenarios would be a dev gone rogue, their keys got compromised, build infra got compromised and this list continues, but its far "safer" than the AUR mainly because of the trust model. Not everyone can sign up and push packages to the official repos. One should earn the trust within the existing maintainers and wider community and follow strict packaging guidelines. Have their own keys, and if it got reported of being compromised, then their keys would be revoked and as soon as pacman gets to know about it, it will reject packages to be installed by that signature.
At some point, trust must be anchored somewhere --whether in the developer writing the code, the maintainer packaging it, or the infrastructure hosting it. The official repositories [core] and [extra] aren't "unhackable"; they are simply hardened through multi-layered friction...

Last edited by 5hridhyan (2026-08-01 17:38:27)

seth · 2026-08-01 20:02:54

If we ignore that 'he first "official" package being shipped with malware' could have been xz if it wasn't <project you don't like and could call a malaise>, ie that the upstream risk is abysmally higher:

Is it really just "trust" or is there something more substantial in place?

there still seems to be no build machine which auto-builds PKGBUILDS, created by maintainers

You're sitting in front of it, https://wiki.archlinux.org/title/Arch_build_system - otherwise you'd have to *trust* whoever controls the build server - and the servers integrity (which immediately becomes a high-profile target)
That burden can only be diffused by

reproducible builds. But so far there still are many packages that can not be built that way.

https://wiki.archlinux.org/title/Reprod … elping_out
ie. reproducible builds make it more likely that efforts to spike the binary get eventually caught.

The AUR gets attacked vandalized because it's by it's nature the softest of all soft targets, open to every script-kiddie ever.
But in reality you're already applying an awful lot of trust to many people who give you things for free…

CuriousRubick · 2026-09-29 13:33:54

seth wrote:

If we ignore that 'he first "official" package being shipped with malware' could have been xz if it wasn't <project you don't like and could call a malaise>, ie that the upstream risk is abysmally higher:
Is it really just "trust" or is there something more substantial in place?
there still seems to be no build machine which auto-builds PKGBUILDS, created by maintainers
You're sitting in front of it, https://wiki.archlinux.org/title/Arch_build_system - otherwise you'd have to *trust* whoever controls the build server - and the servers integrity (which immediately becomes a high-profile target)
That burden can only be diffused by
reproducible builds. But so far there still are many packages that can not be built that way.
https://wiki.archlinux.org/title/Reprod … elping_out
ie. reproducible builds make it more likely that efforts to spike the binary get eventually caught.
The AUR gets attacked vandalized because it's by it's nature the softest of all soft targets, open to every script-kiddie ever.
But in reality you're already applying an awful lot of trust to many people who give you things for free…

Interesting. As of my reply, the reproducible status page shows 74%. Is that cause for concern?

How does this compare to other distros such as Fedora, openSUSE and Ubuntu? Are there ways to verify/reproduce their official packages?

cryptearth · 2026-09-29 15:37:31

please avoid full quotes

as XZ was already brought up i dug deeper into an explanation how tge attack worked - and from what i understand: the way it happened could very well happen to arch, both the aur and official repo

why? because the actual attack was to provide a forged tarball that differed from the repo commit it was supposed to be created from
at this point just looking at a PKGBUILD which has an url to a .tar.gz (or whatever) would have look completely normal - all it contained would have been the url and the regular snafu of
./configure
make
make install
at no point this would have caused any suspicion if it weren't for soneone who extensively tested it and notoced that for some reason some ssh handshake took about half a second longer than usual - nothing any automated tool would have ever caught and could likely be dismissed as runtime jitter

so - this very attack could also affect any arch package - no matter repo or aur - and no "check the PKGBUILD!" would have helped here (!)

accordrding to the sources i consulted (no A-not-I were asked - although i don't know if the authors of what i read used it) one (potential) lesson learned from this incident: don't rely on provided pre-packaged tarballs (as it's decades old tradition) but rather fresh clone the git repo from a fixed commit and build from it
ok, fair, but aside from it's quite infeasable to clone the entire kernel repo i see potential ways how this can be abused, too

so, it's pick your poison: trust a potential very big git repo with all the repos history and maybe several copies of large binary blobs - or trust a pre-packaged tarball is actually a cleaned version of some current commit stripped from all of .git and similar

i'm not sure if git or any other versioning protocol allows for "just get me commit X but exclude the rest of this repos history" - this could save GBs of years of history for a project whose actual source size is only a few MBs - but that's about what could be a possible way to go

seth · 2026-09-29 15:53:19

The xz attack came from "within the building" - it was only distro-related because that little prick had to convince downstream to link sshd into libsystemd after upstream (openssh) had told him to get stuffed.

@CuriousRubick
See eg. https://docs.fedoraproject.org/en-US/re … s/#_status
As for "concerns"

seth wrote:

But in reality you're already applying an awful lot of trust to many people who give you things for free…

The trick is to be aware of those situations and correlate them w/ the attack scenario.
Are you a target? For who? Why? What are their pot. gains, what are their costs and losses?
What impact has that on your software selection, your hardening efforts?

A lot of people have put a lot of effort into arch and upstream software - all that will be flushed down the toilet if one gets exposed as malicious - so what's to gain on the other end?

Arch Linux

#1 2026-08-01 16:09:29

How safe is Arch against malware being added to official packages?

#2 2026-08-01 17:32:04

Re: How safe is Arch against malware being added to official packages?

#3 2026-08-01 20:02:54

Re: How safe is Arch against malware being added to official packages?

#4 2026-09-29 13:33:54

Re: How safe is Arch against malware being added to official packages?

#5 2026-09-29 15:37:31

Re: How safe is Arch against malware being added to official packages?

#6 2026-09-29 15:53:19

Re: How safe is Arch against malware being added to official packages?

Board footer