Comment by harvie

7 days ago

7+ hours into this and still no mention on archlinux.org webpage nor on aur.archlinux.org. Why??? AUR should have been blocked until user takes action to prove he knows about this.

Eg. change AUR API URL slightly so yay/yaourt users need to look up what is going on. New API should have infrastructure for informing users and making sure they've read the message before proceeding. Especially when they're not even sure that all malware was found.

Also there should be database of revoked/compromised AUR commits and there should be mechanism to warn user if they had it installed.

For good or for bad, this warning is ALWAYS present for AUR.

It's right there in the name, and it's clearly announced in all the wiki materials that AUR is user repos, and trust shouldn't be given blindly.

It's literally in a giant red box right up front: https://wiki.archlinux.org/title/Arch_User_Repository

There are lots of things on AUR that I absolutely won't install, and I don't really think spamming the mailing list with all of them is the best policy.

And while I don't exactly hate the idea of warning users who installed a malicious package... it turns out that's not a particularly feasible thing to implement, because AUR doesn't have the kind of install tracking that's present in the commercial tools... ex - how exactly are they supposed to know who installed a package? AUR is basically just a phonebook of package locations, and they don't require any login/auth info.

So the warning comes from tooling the user can run if they're paying attention, and they ask you to pay attention (ex - https://gist.github.com/Kidev/59bf9f5fb53ab5eee99f19a6a2fc39...)

No it shouldn't. You don't break everyone's workflow just because some people refuse to take basic security advise seriously.

> New API should have infrastructure for informing users and making sure they've read the message before proceeding.

How would that even work? AUR packages are just git repos, everything that AUR helpers are doing or not doing is not under the control of the arch maintainers.

  • > How would that even work?

    Are you seriously asking how would sharing short text notes over internet work?

    If you need to be 100% git-centric, you can have git repo for messages. Client will then remember last commit displayed to user and refuse to continue unless latest message was displayed.

    BTW some AUR clients displayed ArchLinux RSS feed before... Too sad the issue is not even mentioned in the RSS feed...

    • There's no shortage in ideas of how to make the AUR easier to moderate. A "quarantine button", an invite system, a request system for adoption similiar to how orphan requests work, code review attestations similiar to cargo-crev, pacing controls similiar to those in discourse.

      There is a shortage however of people skilled enough to implement them (with available time to do so).

      What we also don't have a shortage of is angry people in comment sections.

      9 replies →

    • You seem confused about how the AUR works. There is no "client" like you're talking about that can show the user anything.

      There are AUR helpers, but these are completely unaffiliated with arch and the people running the AUR. The canonical, recommended way of installing arch packages is cloning a git repo, reading through the sources and then building it with makepkg. There is no client there that could show the user anything.

      2 replies →

  • Even people who do read the content of every AUR package they install could use a helpful heads up and some detail in the new threat they should be looking for.

    If a package is compromised, I think most people would prefer their workflow be broken than risk installing that package.

I think a notice on the front page of the AUR would make sense here. IMHO, a blurb on the Arch homepage with a link to a notice on the AUR page would also help.

If you don't want to list all known effected packages, at least recommend the official position that anyone using a AUR package should be reading every file of every package they use.

IMO if numbers on Socket.dev can be trusted, then impact seems rather small (luckily). It also makes sense — I know some packages from the affected list, they're heavily outdated and their upstreams aren't maintained anymore.

Other than this — I don't know how many there are affected people in total, but AUR team probably has an exact number. I am also sure, they're doing their best to handle it accordingly to the impact.

Arch shipped a broken fontconfig package 10 days ago. The broken version is still the one offered.

It is a bit disappointing to not see any mention anywhere official.

I know its all volunteer work and extremely not fun at the moment, but it feels weird to not even have some sticky-no-reply on the AUR sub forum with a list of compromised packages. You have to instead try and scrape them up from around threads like here or reddit.