but I did analyze the 12% of packages within the AUR that are currently without an maintainer. And some naive testing - just by parsing the PKGBUILDs and the accessibility of the sources as well as the upstream url - resulted in a list of orphaned packages that could be marked for deletion.
As the number of orphans within the AUR is quite substantial (13010), I’ve automated an source and upstream url accessibility test via claude code (shame on me !) and a local script running on my machine took several hours to categorize all those orphans based upon several criteria. I didn’t automated flagging the packages as out of date, nor did I automate deletion requests. But based upon the analysis results, I’m double checking these results, flagging the packages accordingly. And file deletion requests if appropriate. Which still does take some time. But I’ll continue in doing so within the next days.
So, this is actually my own contribution in an effort to tidy up the AUR.
Nevertheless, I may have to revisit that script that has been generated via claude code to identify potential deletion candidates, as there are only 97 packages which are definitely classified as deletion candidates, almost 1500 packages are in an uncertain state (I didn’t took legacy VCS packages into account) and the majority of packages could be potentially be adopted with minor fixes to the pkgbuilds, if taken over by a new maintainer. But I am definitely not going to adopt several thousand packages.
In the case if someone is interested in joining this effort, post a reply. Coordinating it should be feasible. The only requirement would be having an AUR account already, at least for the actual package deletion requests. Currently the AUR account registration is still suspended and it’s uncertain when the Arch devs are going to allow new account registrations again.
I can confirm the AUR mods are stepping rather carefully at the moment, which I do appreciate. There’s something to be said for keeping a level head when online communities are exploding with over-reactions to an incident.
Your efforts here look like a worthwhile and well considered project @1093i3511
I’d be interested in seeing a list of top adoption candidates.
The current list of results is pretty raw and hasn’t been ranked by any metrics yet.
In short, if the sources resolve and the dependencies are available I didn’t included any further introspection that would aggregate a list of top adoption candidates. As the primary focus has been gathering sufficient evidence for the purpose of submitting deletion requests.
I would be feasible to tackle this at a later date, but it may need a complete reevaluation.
Just to clarify: My audit / availability check resulted of 1500 packages not categorized yet. It’s not clear if their sources are still reachable - it’s a flaw within the analysis and I need to refine the analysis in that regard.
Additionally: An orphaned package that didn’t has seen any updates or use within the last years isn’t really an attractive candidate to take over, in case you’ve got malicious intends.
Until now, my latest deletion request are still pending. And I can’t really tell if they would be accepted or declined.
Sadly I can’t tell when they’re actually going to open AUR account registration again.
Also, for those who didn’t knew it: AUR Cleanup Day should take place this year, 20th of September. But from what I can tell, there are many orphans which survived several AUR Cleanup Days of the past years.
There is also the aur-requests mailing list, where the submitted requests would be discussed. But I haven’t registered for it yet and can’t really tell how active that mailing list is.
Hi List,
the worst of the June 14th attack now seems to be past us (fingers
crossed). Unfortunately I guess that it'll not be the last attack the
AUR will see.
Here's two points:
a) aur-malware-check script
Here's a link to a repo that has been quite popular during the event:
https://github.com/lenucksi/aur-malware-check
It started out as a collection / summary of the scripts distributed
throughout the initial gists and then received contributions from others
for another, fully unrelated "campaign" and the "russian spam" packages
that were discussed on this list later.
I then turned the initial shell scripts into Python with the intent of
being as concise as possible, as standard lib-only as possible and as
reviewable as possible together with the best possible
grounding+connection in the original sources that are connected to a
"campaign". Now it has a format that can take in additional malware
"campaigns" in an easier way if they're sort-of similar to the previous
ones or can be extended easy enough to fit other malware approaches.
The script has been created with human review (multiple people) and
LLM-assistance. So for those who hate the existence and/or the use of
LLMs: Please ignore the script. For the others: Maybe it's something
that could be of use when the next set of nasty people come around. More
constructive human review/improvement welcome of course.
b) Enforcing isolated chroot building of packages (or at least promoting
what already exists)
To my understanding the blast radius of the 14th of June campaign could
have been limited to a good degree by enforcing the building of the
PKGBUILD in a chroot/container/nspawn etc that is properly isolated
against the host system it runs on. Of course, if the resulting package
is infected past the build process and then does its ill work after /
when being installed, this is of no help. I did find the devtools
(https://gitlab.archlinux.org/archlinux/devtools) package, its pkgctl
tool and of course the more recent AUR helpers such as paru have an
optional --chroot parameter.
However none of it is default, advertised properly or promoted as a good
/ best practice even though upon trying those they all worked quite
well, didn't really take excessive amounts of disk space and didn't
really extend the time to build and AUR package that much.
I dug around the devtools package and how it is used today and added a
few tweaks to it that run fine here. Basic point was: See to what degree
the modern Linux capabilities can be used to isolate the build a bit
better than what the current chrooted builds do. Also, isolate what the
AUR builds download in terms of cached packages from the main cache.
Provide an option to clean said cache after build.
Since the Archlinux Gitlab is invite only, I have converted the changes
to patches and attached them here. Maybe they are useful to someone.
Cheers,
I wouldn’t know how to realize that. But I think this is okay and because not knowing about such stuff I switched to Fedora. Maybe this fits better for me …
In case of yay, it’s a feature request that is more than 6 years old already. It has been approved, but the yay developer calls for help with the implementation.
Paru and Aura are pacman wrappers / AUR helpers that would support building within a clean chroot environment.
Guess I could continue with my effort. But I got sidetracked with more “fun” things such as switching from KDE Plasma in favor of Niri / DMS, my day job, sleep and other things that are a bit more interesting than filing deletion requests.
Too bad that the numbers of new orphans within the AUR of the last two weeks outnumbers these accepted deletion request, if I’m not mistaken.
But I’ll definitely try to refine my analysis and work towards that AUR Cleanup Day date on September 20th.
