Despite that official Arch repos weren't affected in this attack, I would not recommend using Arch (or any rolling release distro) for anything that requires security. (Imagine if the xz backdoor targeted Arch...)

An Arch maintainer that I personally know once admitted that he rarely review upstream changes when bumping package versions. He only does that when the build breaks.

I can't blame him for what he did, since it's not reasonable to ask package maintainers to spend all their time on those stuff, especially in this "Age of AI" where more and more software are being aggressively refactored (or rather rewritten) and added more features.

What we can do is choosing a stable distro (like Debian) where packages are more thoroughly reviewed, and apply security practices (such as TOTP, sandboxing browsers and video players, etc.) even though they cause inconvenience.

▲

Ferret7446 9 hours ago | parent | next [-]

I don't think Arch maintainers are responsible for auditing upstream. They package the upstream only.

▲

matheusmoreira 2 hours ago | parent | prev | next [-]

Alarming. The whole point of official repositories is they're trusted, since they are maintained by trusted people. If one can't trust maintainers to be responsible, then the official repositories are no different than the AUR.

▲

zbentley 9 hours ago | parent | prev | next [-]

> An Arch maintainer that I personally know once admitted that he rarely review upstream changes when bumping package versions.

Cool story bro. Assuming that's common, I have trouble understanding why Arch (non-AUR) is any more at risk than Debian--besides the latter being more popular and having more users/incidental testers, which is a real benefit if that's your goal, but has its own drawbacks (like older and known-vulnerable packages lingering for longer before updated releases are made available).

> it's not reasonable to ask package maintainers to spend all their time on those stuff, especially in this "Age of AI"

Aren't Debian and friends similarly at risk of this as well, then?

> security practices (such as TOTP, sandboxing browsers and video players, etc.)

I'm not sure if those are more or less prevalent on Arch; I know that many IDEs and GUI programs I've installed on Arch ran by default in Flatpaks or similar, and Debian/Ubuntu like Snaps, but I'm honestly not familiar with whether those ecosystems have significant and/or equivalent penetration in different distros.

▲

skjfjnflw 8 hours ago | parent [-]

Debian freezes the package versions on release of each Debian version and then cherry picks critical fixes for the rest of the Debian version's lifecycle. So even if they never review the code (and I don't expect them to), they're less likely to release malware before it's discovered by others.

▲

thewebguyd 7 hours ago | parent | next [-]

That model is getting increasingly difficult and labor intensive, unfortunately. More and more upstream are abandoning the old school security advisories. Not many are isolating CVEs or security fixes into distinct patches, the fixes come with a version bump and often accompany new features or other bug fixes.

There's also plenty projects that silently fix security bugs without issuing a CVE or even labelling them. So now the maintainer of that packages has to monitor the commit logs, figure out if a particular bug fix has security implications and then backport it to the older version which is becoming harder and harder over time.

Unless you have a massive team or a big enough army of volunteers, the LTS model is becoming less and less viable over time, you are often safer on rolling release or close to it (something like Fedora's pace is good).

	▲	skydhash 5 hours ago \| parent [-]
		I like the Alpine model where they have a set of packages they maintain via the core team and everything else is in "testing".

▲

akerl_ 7 hours ago | parent | prev [-]

You get a lower risk of them pulling in a bleeding edge vulnerability, but a higher risk that you'll get stuck with an old bug waiting for the maintainer to pull in a patch. Then there's the risk that in their attempt to cherry pick, they don't actually mitigate the issue (or introduce more issues based on how they diverge from upstream).

There's no silver bullets here.

	▲	armada651 4 hours ago \| parent \| next [-]
		> There's no silver bullets here. Because it's a trade-off, just like stability is, they're both software bugs in the end so mitigating them has similar pros and cons.
	▲	skydhash 5 hours ago \| parent \| prev [-]
		> but a higher risk that you'll get stuck with an old bug waiting for the maintainer to pull in a patch. Then there's the risk that in their attempt to cherry pick, they don't actually mitigate the issue Which is why the whole process is open sourced and you can get easily the source version of a package, edit it and rebuild it.

▲

akerl_ 7 hours ago | parent | prev [-]

> where packages are more thoroughly reviewed

Where are you drawing your conviction that non-rolling-release distro maintainers are doing a more thorough review of upstream changes?

> such as TOTP

What?