Jguer
Improved transparency
Is your feature request related to a problem? Please describe.
Recent malware scares led me to notice this. My habit is to usually check the AUR page. I noticed many dodgy names in the last few days, but wouldn't know they were new if I were using yay.
Describe the solution you'd like
- Search 'google-chrome'
- See this:
1 aur/google-chrome 138.0.7204.183-1 (+2291 10.86)
The popular web browser by Google (Stable Channel)
- Submitted: 2010-05-25 20:25 (UTC) Updated: 2025-07-29 21:37 (UTC)
- https://aur.archlinux.org/packages/google-chrome
This because: all the 'bad packages' discovered were brand new.
Sometimes packages are problematic because they weren't updated for an extremely long time.
There's no substitute for a clickable link that takes you to the AUR page.
Describe alternatives you've considered
I looked at other AUR helpers, pamac/paru are just as 'bad'.
People say you MUST be able to 'vet' your own, however (look at chrome) the pkgbuilds can be extremely tough to analyse.
Seeing popularity is good - votes not so much of a guarantee (perhaps the uploaders of malware will have a dozen friends ready to get some votes registered).
I agree, the recent malware scares should move the needle on what "minimal display is"
https://github.com/Jguer/yay/pull/2330 has been gathering dust for a while as well to see if people upvoted it or the over issue, but I think would be a good inclusion. I think it would be a good idea to make this the default setting and keep an option for a minimal display. Even though I personally don’t like having so many different views, it would be helpful for others who don't like change.
I’ve been working on a feature that might go in a similar direction. It flags when packages changed maintainers since the last install/update, so you get a warning before proceeding. I think it's really important since a lot of using the AUR comes down to trusting maintainers. Users should really get notified of an important like this change before letting an update go through.
Looks like this:
I built this by maintaining an offline database similar to how vcs packages are tracked. It's easily extensible for other attributes like upstreamurl for example. If there is interest, I’d be happy to open a PR for this.
I came here to file a similar issue; my recommendation would be to print a warning if:
- the package is brand-new and uploaded by a brand-new user account
- and/or the package has very few upvotes
- and/or the package has very few downloads
- and/or the package has recently changed maintainers (good catch, @tam1m)
If the package meets these conditions, yay should print an "are you sure?" message along with a recommendation to inspect the PKGBUILD with yay -Gp packagename. Of course, the user should be able to skip this warning with a command line flag or editing a config file.
On the subject of tracking downloads, I don't know if the AUR has a built-in utility for monitoring how many downloads a package receives. If so, perhaps yay can maintain an internal database for how many people downloaded an AUR package using yay itself
@givensuman The problem with adding a new command like "yay transparency" is that the people who need it are not gonna use it. The reason the recent malware scares are so dangerous is because people blindly use the AUR like it's a normal package repo. And I KNOW Arch Linux recommends you always inspect the PKGBUILD, but what percentage of users actually do that? Even assuming that Arch users do their due diligence, what about the other Arch-family distros that explicitly aim to be more noob-friendly?
In order for such a thing to be effective, the warning needs to show up ON DOWNLOAD and be the default behavior. I know the Arch community likes to dismiss inexperienced noobs, but as Linux grows in popularity this will be necessary.
There is no shame in idiot-proofing.
Would it make sense to try and calculate an estimate "safety rating" based on the information we have on the RPC and display it on the listing.
Once a user selects a package to install (and its deps), have a new intermediate menu before PKGBUILD review that shows information that can help the user to make their opinion and give them a first opportunity to cancel.
ex non binding:
1 aur/google-chrome 138.0.7204.183-1 (+2291 10.86) (safe estimate: 10/10)
> 1
aur/google-chrome
Submitted: xxx
Updated: xxx
Comments: xxx
*Warning*: this package has a bash script attached, review this file
(...)
Continue to review (Y/n)?
Objective would be to keep the search minimal (and as well there's not that much info during the RPC phase) and then have more advanced heuristics once the PKGBUILD repo is cloned
Would it make sense to try and calculate an estimate "safety rating" based on the information we have on the RPC and display it on the listing.
I've been thinking about this too, but I don't think that would achieve much to be honest. It might even give people a false sense of safety and keep them from inspecting the files at all.
Most of the stats like votes and downloads don't hold much value. First, you can fake them if you really wanted to and second, a package isn't really any more safe to install, just because it has a couple of downloads/votes. The same is true for comments and their presence or lack thereof.
Regarding things like warning about attached scripts. This also doesn't say much. Sure, you can hint at that, but, as a potiential attacker, if I wanted to circumvent that, I'd just inline the script into the PKGBUILD directly. Nothing prevents me from fetching a script (using curl or whatever) from somewhere or just creating it with a heredoc or something. Thus the lack of this kind of warning would again indicate safety while actually not saying anything useful about the PKGBUILD at all. In my example, my trustscore might go up, when in reailty it should have gone down.
I think there is just no meaningful way to create such a trustscore for yay. If anything, it would make more sense for the AUR itself to provide something like that. Maybe based on the maintainer reputation, their number of packages, maybe introducing something like a "verfied maintainer" status. But I don’t think that’s likely to happen, since it would require actual human resources.
Overall, I don't think a trustscore is the way to go here. Truth is, users have to inspect stuff when installing from the AUR. There is no way around it other than setting up some kind of review system.
That said, I still think there is value in putting out some warnings for specific situations.
- change of maintainers
- new files that weren’t in the repo before (not sure about that one)
- changes in the source URL (different upstream repository or similar)
These could be beneficial because, and correct me if I’m wrong here, many users might inspect a PGKBUILD before installing it the first time, but might not do so often (or at all really) on later updates. That's is true for me aswell, tbh. People sadly get lazy.
Objective would be to keep the search minimal (and as well there's not that much info during the RPC phase) and then have more advanced heuristics once the PKGBUILD repo is cloned
With this, I agree. All this extra info is just cluttering the search results.
Could also include a regex that detects any "curl a URL and run it" lines in the PKGBUILD and print a warning
Could also include a regex that detects any "curl a URL and run it" lines in the PKGBUILD and print a warning
There are dozens of ways to do the same thing, though. You can also hide things like that from your regex very easily. Instead of writing something like curl https://example.org/doevilthings.sh, just use variables/concatenation or whatever other shell feature to obfuscate it a bit and the regex wouldn’t match anything anymore. You’d have to catch infinite variations of this for it to be useful.
And even if you somehow got rid of remote fetching code (which you really can't with simple tools like regex), you'd still be left with the problem of just inlining the entire thing into the PKGBUILD itself. Not only are there legitimate usecases for both of these options, but by not showing a warning in only some cases, users might falsely assume that everything is safe.
That's the core problem. Doing this well would require a whole complex system for code analysis and heuristics.
Again, that's of course just my opinion, but that would lead to a very counterproductive false sense of security. Either you can count on yay to tell you what's going on or you can't. If yay is showing warnings for this at all, the natural conclusion is "no warning = safe", which is dangerous.
What if this problem was dealt with on the AUR end? Like I know many file hosting services have automated malware checkers that catch known malware payloads. Maybe before an AUR upload is made public, a test machine installs the package in a containerized environment, then scans that container for known malware payloads. Wouldn't do much against new and unknown malware, but it would be a step.
I’ve been working on a feature that might go in a similar direction. It flags when packages changed maintainers since the last install/update, so you get a warning before proceeding. I think it's really important since a lot of using the AUR comes down to trusting maintainers. Users should really get notified of an important like this change before letting an update go through.
I think this is a great idea and I'd like to have that feature. Notifying only for changes such as maintainer or upstream changes is unobtrusive in the sense that in most cases there won't be a notification. But if there is a notification it catches a user's attention to something that is relevant to look at.
I'm not sure if this is the best place to bring this up but I would also really like to see a minAge option. So in addition to more transparency I can set a config and auto skip installing any AUR package updates that were released less than n days ago. Usually bad packages get detected fairly quickly so this would provide another layer of protection. Pnpm a NPM package manager also recently introduced this feature to protect against NPM malware.
skip installing any AUR package updates that were released less than X days ago
isn't that what Manjaro does? update packages with a time delay lag behind the real Arch repos?