Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AURpocalypse now: a look at the recent AUR attacks

lwn.net

Post reply on HN
Print view View original

31–40 of 104 posts

Re: AURpocalypse now: a look at the recent AUR attacks

#31

Post by akerl_ »

AquaWeasel wrote: post #19

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, sinc…

> 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?

Re: AURpocalypse now: a look at the recent AUR attacks

#32

Post by thewebguyd »

skjfjnflw wrote: post #29
zbentley wrote: post #21

Earlier quoted context omitted.

> 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 know…

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.

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).

Re: AURpocalypse now: a look at the recent AUR attacks

#33

Post by akerl_ »

skjfjnflw wrote: post #29
zbentley wrote: post #21

Earlier quoted context omitted.

> 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 know…

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.

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.

Re: AURpocalypse now: a look at the recent AUR attacks

#34

Post by jjmarr »

AshamedCaptain wrote: post #5

I'll note that OpenSuse also has Packman which a shitton of people enable (for codecs), has also 'one namespace only' an looser policies than the main distro. I do not think this something you can escape by switching distro.

I use Gentoo. You have to specifically install "overlays" and every package maintainer would make their own overlay. You can't easily take over an overlay without the original person's permission.

That being said, still one namespace. Once you add an overlay it can replace any package it wants.

It's also Gentoo so too hard for most people to figure out.

Re: AURpocalypse now: a look at the recent AUR attacks

#35

Post by skydhash »

thewebguyd wrote: post #32
skjfjnflw wrote: post #29

Earlier quoted context omitted.

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.

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. S…

I like the Alpine model where they have a set of packages they maintain via the core team and everything else is in "testing".

Re: AURpocalypse now: a look at the recent AUR attacks

#36

Post by skydhash »

akerl_ wrote: post #33
skjfjnflw wrote: post #29

Earlier quoted context omitted.

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.

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.

> 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.

Re: AURpocalypse now: a look at the recent AUR attacks

#37

Post by armada651 »

akerl_ wrote: post #33
skjfjnflw wrote: post #29

Earlier quoted context omitted.

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.

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.

> 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.

Re: AURpocalypse now: a look at the recent AUR attacks

#38

Post by dSebastien »

nickjj wrote: post #16

In case anyone missed it, the latest version of yay (v13+) supports being able to skip recently added packages through its new Lua extension system https://jguer.github.io/yay/lua.html#upgrade-selection-hooks . You can control the threshold since it's just user configuration now. A bunch of common yay commands also return back the last updated time of a package thanks to https://github.com/Jguer/yay/pull/2846 .

Hope Omarchy will make that a default:)

Re: AURpocalypse now: a look at the recent AUR attacks

#39

Post by kdeldycke »

nickjj wrote: post #16

In case anyone missed it, the latest version of yay (v13+) supports being able to skip recently added packages through its new Lua extension system https://jguer.github.io/yay/lua.html#upgrade-selection-hooks . You can control the threshold since it's just user configuration now. A bunch of common yay commands also return back the last updated time of a package thanks to https://github.com/Jguer/yay/pull/2846 .

The thing is that hook is not enough: `UpgradeSelect` only applies to `yay -Syu` so it only filters the upgrade list.

Nothing protect you from a `yay -S foo` install and its dependencies. So this is not a guarantee or enforcement of a minimum release-age.

Actually writing this reply I went ahead and pointed that out in an issue at: https://github.com/Jguer/yay/issues/2883

Re: AURpocalypse now: a look at the recent AUR attacks

#40

Post by jchw »

The AUR really has been known to be low-hanging fruit for bad actors, which makes it somewhat surprising it took this long for it to be taken advantage of.

I have many opinions regarding this situation, but it mostly doesn't matter. AUR staff and AUR helper developers will figure out what they want to do, hopefully they will find a good approach.

But what I personally take away from this is simply that it has become worth it to target desktop Linux with malware. Or at least, moreso than previously. It is perhaps a good sign in some ways that the desktop is starting to be taken more seriously.

The bad news, of course, is that the Linux desktop is a bit of a train wreck in terms of security hygeine. It's getting better, and Linux does have the advantage of having some powerful primitives to exploit, but the desktop suites come from a totally different world, and I fully expect we'll also see more malware propagated through KDE's New Stuff integration (which goes through Pling.)

Post reply on HN