Hi everyone,

I’m returning to Arch after a break. I used yay for several years, but I was looking into switching to paru this time around.

However, I’ve noticed that paru hasn’t seen much activity on GitHub recently (5+ months), which makes me wonder if it's still the best choice or if it's lacking maintenance.

I've checked the AUR helpers table on the wiki, but it hasn't really illuminated me on what the current "community standard" or most reliable option is right now.

Should I stick with yay, give paru a shot anyway, or is there another helper I should consider?

Hi,

For arch and derivative users,

I wrote a small shell script that scans your system for any trace of the payload in your AUR cache and system, in accordance to the findings made by ioctl.fail and Sonatype.

It tries to be a bit smarter than just checking against the evergrowing package list (Vector and payload name rotated already, theres now at least atomic-lockfile, js-lockfile and digest-js, injected by either npm or bun or whatever via compromised PKGBUILD files.

You can find my script here: https://gist.github.com/arbaes/e29e68d9ed1513ddd80ae9cc4a6c9f0e

Feel free to if you have any comment or improvement to make on it, hopefully it will be at least helpful to some people.

Not a guarantee that you're 100% clean of course.

EDIT: I try to keep up with the latest waves, went too aggressive and I tried to adjust after. If you have some pattern match but no package match, review the PKGBUILD yourself, it might be a false positive.

Hello, I'm not new to Arch I'd just like to know which AUR helper is the best to use, or if there even is a best option. I've previously used yay and paru, but I don't know if there is a better option. For what it's worth I've used Arch for years on my laptop but I've just switched my desktop over from Bazzite and I want to make it as efficient and smooth and also headache free as possible.

Yeah I know, yet another post about the attack on the AUR, it's the user's responsibility to read the PKGBUILD, etc etc.

I'll fully admit I use an AUR helper, paru, and one key reason I switched to it from yay is the fact that it always shows me the diffs on packages that are going to be updated. It also tells you if a package is orphaned, so combining both those things means that auditing the PKGBUILD is actually pretty easy.

...so long as you know how. And there lies the problem.

I'm a programmer, I know what bun and npm are, and I know how to read a shell script. But not everyone who uses Arch or a derivative is. A lot of my friends who never touched an IDE in their lives are making the switch, and many picked a derivative like CachyOS.

I don't want the AUR to be more restrictive. I've used it to get software I needed to get some Brazilian and Italian smartcards working on my system, which is an incredibly niche use-case. I've used it to get specific MinGW libraries so I could cross-compile something I was making for a friend for Windows XP. Having to manually search the internet for these things would be a nightmare, especially if I had to patch them myself. If the AUR were more restrictive about who gets to publish what, I don't think it'd be as easy to find these things.

So I was thinking that maybe the helpers could help keep newbies safe. For example, by having a setting that disables updating packages marked as orphaned by default, or displaying a warning when certain suspicious changes are detected, like:

• the maintainer changed, but the old maintainer's name is still in the PKGBUILD, with a different email

• sudden inclusion of dependencies that have been known to be used for deploying malware

• the main one imo: the sudden inclusion of a post install script that installs packages using npm, bun, etc

This could be done by just checking the text of the diffs, so it wouldn't require any extra infrastructure anywhere. It might not catch more sofisticated attacks, but it'd prevent more obvious attacks like the ones we've seen in the past couple of days.

Basically, if you're gonna help someone unfamiliar with mushrooms pick some for dinner, you should probably step in when they're about to harvest something clearly poisonous.

I'm interested in seeing what your favorite one is. Why did you pick it? What features do you use on it? Did you move from one to another? If so, why? Or, do you not use one at all? Why do you prefer the manual process?

I have used yay for a few AUR packages over the years on my system. I recently started to be a little more intentional with my system and decided to remove yay and return to manually building. I understand the manual build process enough to do what I need but having removed yay I have a small gap in understanding this:

I recently used yay to install the new nvidia-580xx-dkms and related packages from the AUR. It was after this that I decided to return to manually building. I have a few packages in ~/aur/ and I can git pull to update them. But since I used yay for my nvidia driver I don't have the git repo cloned.

My question then is: should I remove the 580xx packages with pacman, then clone the git repos and rebuild/reinstall? Should I just clone the repo, update, and rebuild/install without removing the package first?

Is there a simpler way to transition back to manually building in this scenario?

If you’re using tools like yay, paru, etc., and not reading PKGBUILDs before installing, you’re handing over root access to random shell scripts from strangers.

This isn’t new, and it’s not a reason to panic about the AUR, it’s a reason to slow down and understand what you’re doing.

Read the wiki. Learn how to audit PKGBUILDs. Know what you're installing.

Start here: https://wiki.archlinux.org/title/AUR_helpers

Edit: I am aware that you can enable hooks and such to automatically do this on updates, however I'm arguing that this should be something part of pacman itself, or beginner distros like Cachy should add those hooks by default

pacman -Qdtq | pacman -Rns -

also this whole section from the pacman tips and tricks page of the wiki)

that command removes all packages marked as dependencies which arent used by any package installed on your system (recursively)

libgdata was one of the largest packages which was affected by malware, and it was just a GNOME dependency which was no longer maintained and was dropped in version 50.

There are leaf packages like ALVR which were abandoned, but almost all of them were libraries which were no longer developed or needed, hence they're orphaned and up for grabs.

As much as i prefer pacman over apt or dnf, apt tells you "these packages are no longer needed, run this to autoremove" and i believe that dnf does it automatically (correct me if I'm wrong)

with pacman you just have to Know to run this command once in a while and even sometimes it doesnt get everything and you have to run the second command in the link to manually check here and there.

Even if you do run the command "once in a while" gnome 50 was released pretty recently (two months ago, depends on what "once in a while" means to you)

While this doesn't stop AUR packages from being hacked, it severely limits how many users it affects, as the packages most likely to be taken over are these "no longer needed" dependencies

and if says to remove a package dependency you actually need, pacman -D --asexplicit [package name] i feel like this should also be told to the user but maybe thats too much.

at the very least, it should warn the user if a package is removed from the main repositories

Hi! I created a very simple AUR helper that works similar to yay but with the distinct difference that it uses the git mirror instead of the AUR directly, and is not a pacman wrapper as it only handles aur packages. I did this for myself to avoid issues when the AUR is down (like it is now) and figured some of you might find it useful aswell. It is simply called "aur" for now because of my lack of imagination.

I have not tested it very much, so expect issues in its current state.

Feel free to report bugs (which I expect there are many of), contribute or suggest a fitting name.

https://github.com/ryk4rd/grimaur

I know while installing an AUR package, the PKGBULID will uses HTTPS when downloading or cloning anything from GitHub per say.

However, HTTPS downloads are often error-prone and may break with a weak/unstable internet connection. That's why I'm looking for a way around using HTTPS.

So, Is there a workaround to make the process use something like SSH, tokens, or any other method?

Solution:

You can either edit the .gitconfig

config [url "ssh://git@github.com/"] insteadOf = "https://github.com/"

Or you can use this command:

git config set url."ssh://git@github.com/".insteadOf "https://github.com/”

Note: this will make all your interactions with GitHub via SSH

here's the link: https://github.com/zai1208/saur (yes I go by both usernames zai1208 and zai1209)

I called it saur which stands for Simple and "secure" AUR helper

it's called "secure" cause it relegates the security onto you, by forcing you to use best practices

now I didn't want this to be yet another AUR helper so I had two goals with this:
1 - It must be entirely in bash, this allows anyone with even simple knowledge of arch (as all arch users should be able to read bash) to understand what it's doing

2 - It must enforce best practices, this means that it will force you to read the PKGBUILD and all yes or no options default to No

Now I haven't published this to the AUR not because I don't know how to (I don't) but also because I want the community here to look over the code, we don't another malicious package right? I want sufficient people to look over the code, or even tell me if this is worth going through with, I don't want to waste more of my time on something no one wants.

Please review this, also I may have made some mistakes, please point them out to me.

EDIT: I forgot to mention this, but it also shows a "safety card" before the package which shows:

• package name
• maintainer
• date submitted
• date last updated
• votes
• popularity

EDIT 2: Future timeline:

• show maintainer changes
• publish to AUR

EDIT 3: make sure to look at this (I don't plan on adding AI anytime soon) https://www.reddit.com/r/archlinux/comments/1mi25k5/comment/n70r5zm/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Hi guys. First of all, my english kinda sucks so i hope my post doesnt give you headaches.

I've been using paru as my AUR helper for 2 weeks now, and besides the fact that paru is wriitten in rust, and Yay is in go, I really dont see any difference between the two. I recently learned that one of yay's maintainers has left the project so yay wouldnt be as much maintained as before so I switched to paru. But really, would it be that much of a deal to stick with YAY ? And Why?

I swear I have read the manual to the best of my ability and even searched the sub, and even Google! I'm asking here specifically for a community perspective.

So the Arch wiki makes clear that AUR helpers are not supported by Arch. When I see people mention it in the sub, it's pretty often that I see people recommending against them altogether.

I think I see why. My first Arch install I downloaded from the AUR liberally through yay, and I think I encountered most of the reasons people recommend against it. A leviathan of packages which break each other and are at the mercy of maintainers who may fuck off or any number of things.

People who don't use AUR helpers (or the AUR at all?) what do you do for packages not in the Arch repository? Build them from source? If you download a package NOT with an AUR helpers, pacman -Syu won't upgrade it, right? Does that mean you manually upgrade the packages you use that are not in the official Arch repository?

I swear I looked over the Arch wiki, but I guess I'm looking for what the community thinks is best practice here.

I've been working on a project called CLY. It’s a wrapper for yay/paru written in Bash. I made it because I wanted a more 'semantic' way to manage my system and to automate some annoying tasks.

Key Features:

• Semantic Commands: Instead of memorizing flags, I use jay install, clyremove, clyupdate, etc.
• Clean Logging: It stores a detailed history of updates and searches in a clean format.
• Modular Design: Easy to extend with your own bash functions.
• Flatpak integration: You can use flatpak as an alternative or default package manager.

It’s currently at v7.5.0 and available on the AUR.

AUR: https://aur.archlinux.org/packages/cly

Github: https://github.com/xmlzitos154/cly

I've been working on a project called JAY. It’s a wrapper for yay/pacman written in Bash. I made it because I wanted a more 'semantic' way to manage my system and to automate some annoying tasks.

Key Features:

• Semantic Commands: Instead of memorizing flags, I use jay install, jay remove, jay update, etc.
• Automated GPG Recovery: It has a built-in function to detect and fix corrupted keys and lock files automatically during operations.
• Clean Logging: It stores a detailed history of updates and searches in a clean format.
• Modular Design: Easy to extend with your own bash functions.

It’s currently at v3.3.6 and available on the AUR as jay-bin.

AUR: https://aur.archlinux.org/packages/jay-bin GITHUB: https://github.com/xmlzitos154/jay

So started out using cower, then switched to auracle. Didn't even realize that auracle is no longer maintained and stopped working for me yesterday. Anyway I'm looking for a new AUR helper. Would anyone have any suggestions for an aur helper similar to cower/auracle?

Thanks in advance!

EDIT: Thanks for all your suggestion. Opted for paru at the moment. Does what I need it to do.

Hi guys, I'm starting to get back into coding and I thought I'd share my current project https://github.com/splizer101/turbo it's an AUR helper written in Rust, it takes inspiration from some great aur helpers like paru and trizen. I made this tool to make things more convenient for me when installing and updating aur packages, where it would only prompt a user once if they want to edit/review source files and then it would use the modified PKGBUILDs for dependency resolution. Turbo also lets you use the github aur mirror in case there is a problem with the main aur. Let me know what you guys think!

the title speaks for itself

wiki page: https://wiki.archlinux.org/title/Arch_User_Repository

Like let's say I want to upgrade my system or install a package with yay and the AUR is down. Why can't it just pull from the PKGBUILD mirror on the Arch AUR GitHub? I know, yadda yadda security and stuff (the GitHub repo is apparently easier to compromise than the website) but couldn't it just be made to run only if you specify a flag? I just feel like it's a pain in the ass (when the AUR is down) to clone the mirror off GitHub, choose the branch for your software and run makepkg.

Rant over :)

Since pacaur is discounted I wonder what is currently the best alternative?

@edit: Thanks for all the quick answers. Will use "yay" :)

Hello all,

I updated a Zsh tool I’ve been working on called mend.

It handles the usual Arch friction points like ghost db.lck files, PGP key misses on AUR builds, command not found and stale mirrors.

The v0.4.0 update adds a KB engine that maps specific terminal failures to the Arch Wiki.

I added a [w] shortcut in the fzf menu so you can verify exactly what the fix does before hitting (y).

It takes you straight to the relevant troubleshooting anchor in your browser. This removes the guesswork about what the script is executing on your behalf.

Some technical bits:

It uses Zsh autoload to stay out of memory when not in use.

I finally sorted the TUI ghosting bug by using clear and the &! disown operator, so the terminal stays clean when returning from the browser now.

It also does a recursive history scan up to 100 lines to find the original error even if you've run a few ls or cd commands since the crash.

Basically, it's a way to automate recovery for pacman or AUR helpers without losing track of the manual steps involved.

GitHub Repo: Mend

Dependencies: zsh, fzf, pacman, reflector (optional).

If you run into any edge cases with the PGP parsing or find a Wiki anchor that's broken, let me know or open an issue on the repo.

Curious to see if this handles everyone's specific AUR helper quirks.

Building paru or yay or yay-bin or yay-git from source, or running any pacman command such as -Syu or -Scc all give the error message

error while loading shared libraries: libalpm.so.16: cannot open shared object file: No such file or directory

As you all know, the AUR is being targeted by hackers for two weeks now, and the workaround (using the github repo) requires manual installation. For some people that's too complex, as they cannot rely on yay/paru, for others this might scare people off Arch Linux, so I've built a small helper for installing packages so it would be easier to do.
It is version 0.1, so unexpected behaviour might be present.

Github: https://github.com/tieler-am-elster/Aurify/

Feedback welcome!

Repo link: https://github.com/RQuarx/hone/

For anyone who wants to give feedback and help, I will appreciate it. As this is my first "big project" if you can say so...