this post was submitted on 16 Jun 2023
12 points (100.0% liked)

Arch Linux

7641 readers
12 users here now

The beloved lightweight distro

founded 4 years ago
MODERATORS
 

Last night while updating my system, I noticed that a random aur package my system depends on was orphaned in the aur. It's some random deep-down dependency of another AUR package, and it's not received any upstream commits in a while. Nice and stable, just needed an owner. I decided to adopt the package before someone else did.

It was kinda scary how simple it is to adopt an orphaned package. Create AUR account... click an email link... Done. If someone wanted to squat the package for malicious purposes, it would be stupidly simple.

I get that this is a problem for all community repos, not just AUR (npm, anyone?), but it's still an unsettling prospect. I feel like it goes unacknowledged some times.

top 14 comments
sorted by: hot top controversial new old
[–] 4ffy@lemmy.ml 8 points 1 year ago (1 children)

This is the main reason that one should learn to read PKGBUILDs. Any AUR helper like Yay or Paru should give the option. Just make sure that the package downloads from an official source and contains only the necessary build and install instructions.

But I agree. Some people treat the AUR as just another repository, when it most definitely is not.

[–] PdeT@feddit.nl 3 points 1 year ago (2 children)

This is something that I still need to learn about. What is a good starting point to learn how to read them?

[–] forgotmylastusername@lemmy.ml 2 points 1 year ago

It's a shell script. Somebody wrote down the shell commands to download, extract, compile from source code. If you can do shell stuff then you're about 1/2 way there. If you've ever manually compiled from source code then you're all the way there pretty much.

It's quite simple since there isn't any other abstraction to learn than what many Linux users already know. Shell commands and compiling stuff.

Probably the one thing that might be foreign is variable and functions of shell scripting.

[–] 4ffy@lemmy.ml 1 points 1 year ago

First, you should be familiar with the basic process of compiling and installing software from source. For C or C++ projects, this can be as simple as ./configure, make, make install for projects that use GNU Autotools, or something like cmake -B build, cd build, make, make install for CMake projects.

I generally split PKGBUILDs into three important parts. There's the metadata at the top then there's the build and package functions. build is where everything up to the make (or equivalent build-the-thing) command goes and package is where the make install bits go.

There's also the prepare and check functions, but those aren't used as often.

As for the actual documentation, the Arch Wiki page for PKGBUILD covers most of the metadata stuff and the page for Creating Packages covers most of the build and package stuff.

[–] Dirk@lemmy.ml 4 points 1 year ago

This is why you always read AUR comments and package file before installing anything from the AUR.

[–] mondoman712@lemmy.ml 2 points 1 year ago

I think that's kind of the point of the AUR. It's much easier to get into the AUR so we have all of these packages available, but you have to be a bit more careful than you would be with official repos.

[–] drwho@beehaw.org 2 points 1 year ago

It's pretty clearly stated on the front page of aur.archlinux.org: "DISCLAIMER: AUR packages are user produced content. Any use of the provided files is at your own risk."

Warnings about AUR packages being potentially dangerous have been around since the days of IRC. Scary, reason to take pause, but also not new.

It's important to actually read what's in the packages. The AUR saves me time installing that I can use up front confirming.

[–] user224@lemmy.sdf.org 1 points 1 year ago

In fact, exactly that has already happened in past.
https://thehackernews.com/2018/07/arch-linux-aur-malware.html

On June 7, a malicious user nicknamed "xeactor" adopted an orphaned package (software without an active maintainer) called "acroread" which functions as a PDF viewer, and modified it to add malicious code.

So definitely check what you're installing.

[–] const_void@lemmy.ml 1 points 1 year ago

This is one of the reasons I don't recommend Arch to people. To easy to get owned if you don't know what you're doing.

[–] TheCraiggers@lemmy.world 1 points 1 year ago (1 children)

It's only scary if you think the AUR is inherently trustworthy. It's not, and every piece of official documentation and various wikis make it abundantly clear it's not. (If you see somewhere that doesn't point it out or edit it so it does.)

The AUR is barely better than pasting J Random Hacker's 'curl http://foo | sudo bash' code you see somewhere to install something. And that's only because at least the AUR makes it easier to inspect what's about to run and what changed.

[–] nomadjoanne@lemmy.world 1 points 1 year ago

Yup. If I want to install something "app-like" and it isn't in the main repos I tend to go with the flatpak over the AUR for that reason.

[–] hallettj@beehaw.org 0 points 1 year ago (1 children)

Hmm, that's a good point. Were you able to take over the existing package? With npm and some other self-publishing repos you can squat a name that hasn't been taken, but an existing package cannot be taken over without the original owner's credentials.

[–] OneCardboardBox@lemmy.sdf.org 1 points 1 year ago* (last edited 1 year ago)

I had full control over the pkgbuild as soon as I uploaded an ssh key to my AUR account. I did end up pushing a small update that fixed a missing download link, but I could just have easily changed the download artifacts. I know that some AUR helper encourage users to check pkgbuild diffs, but I'm sure many (most) people skip that step.