You are not logged in.
Hello Arch community,
I was wondering if anyone can shed some light on the current situation with Arch Security Advisories.
According to this page: https://security.archlinux.org/advisory they stopped being published in June 2025, with some scheduled advisories that never got published. I see in the history that there have been some other long gaps between published advisories in the past, but does anyone know when/if they will resume?
Offline
https://wiki.archlinux.org/title/Arch_Security_Team links to arch-audit issue which indicates the security tracker is currently not working.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Lone_Wolf: while we’re on this topic, may I ask for somebody in contact with schard to ping him about pointing to security.archlinux.org, like that happened in that thread? I have no options other than venues not exactly meant for that purpose, like Wiki talk pages. Thanks in advance.
Offline
The Arch security team currently has four members. Off gitlab activity two are active on average once a month, one twice a month with the last having activity most weeks.
Offline
@mpan I am also reading these forums more or less regularly.
I was unaware of the security tracker being non-functional up until today.
This does not change the action on the post you linked to though, since the solution was already provided in the linked article.
If the security tracker is actually down for a prolonged time, this should at least be mentioned with a big fat warning on its landing page.
People like me, who use it to update themselves on vulnerable packages are otherwise left with a false sense of security of new vulnerabilities not affecting Arch.
Just leaving it sit there not being updated defeats counteracts its purpose.
Inofficial first vice president of the Rust Evangelism Strike Force
Offline
Schard, my comment wasn’t about your action as a moderator, or about pointing to Archie1 the article they linked answers the question. This was after all the basis of my own answer to them. ![]()
My comment was about sending users to security.archlinux.org. In this case I also received it as written in a tone similar to RTFM or LMGTFY. And that’s not useful, if security.archlinux.org is basically dead and checking it brings no answer in almost all cases.
The reason I asked for somebody to poke you is what you outlined here in the second paragraph. Not only it will not help people, but the at this point it may even have the opposite effect.
Offline
2024 onward security.archlinux.org has covered 55 CVEs for comparison Debian has covered 21528 CVEs as of writing or put another way over 99.5% of issues Debian tracked have not been covered by Arch. I agree with schard it does provide a false sense of security and counteracts what I assume it its intended purpose or being an accurate record of vulnerabilities in the distribution and it would probably be better for it to be removed from Arch's homepage.
Offline
Maybe sending an email to Arch-devops would be appropriate? Arch-security mailing list hasn't had any activity since 13 Jun '25.
I'm proposing arch DevOps since I don't know what other people might be contactable.
Offline
I wasn't going to say anything here, since basically every needed has been said already.
But when I went to one of Lone_Wolf's links https://gitlab.archlinux.org/archlinux/ … AxfQ%3D%3D (https://bbs.archlinux.org/viewtopic.php … 8#p2305998), I had an Anubis bot-check using "Difficulty=6" on my poor ancient Haswell which would take forever, but ended up with `Internal Server Error: administrator has misconfigured Anubis. Please contact the administrator and ask them to look for the logs around.`
When I saw that difficulty level, I refreshed the page hoping to get a lower difficulty because it worked once before elsewhere.
After starting this reply, I went to the arch-audit repo (rather than the direct work-item link), with no anubis check, and now see the work item, with no activity from 4 months ago.
https://security.archlinux.org/log shows: `500: Deep Shit 79c19e2f` (whatever that error specifically refers to)
That, along with the 2-month old out-of-date flag dracut, makes me nervous about the rustiness of Arch (especially with how the ARM variant turned out).
EDIT0:
I'm exploring https://nvd.nist.gov/developers, and it looks powerful, but also not all that bad to implement, so I don't know why there's any need for any maintenance.
Basically, you query the CPE for the "Product" (eg libxml2), then you query the CVE for the "Vendor:Product:Version".
While we all can do this individually, it's probably better for every dist to be the queryable data source so the NIST doesn't get flooded.
It doesn't look like you even have to have an API key. Just limit the query rate.
Last edited by vindicator (Today 12:48:13)
Offline
The advisory need to reflect the status of the arch package, not copy a generic list you could generate locally?
Afaiu dracut is an individual case and Anubis causes this in many places so I suspect interference between the aggressive level and some ecma interpreters in the wild causes this.
Arch infrastructure certainly leaves the impression of being understaffed resp facing some fundamental issues wrt the gitlab/sso situation but I've never seen some public statement or call for hands.
Offline
but I've never seen some public statement or call for hands.
But I've seen one! Though this one's specifically for bug wranglers, not infra...
https://lists.archlinux.org/archives/li … W3X6CNS7W/
Although both reflect the team's resource constraints, they're not the same issue.
Last edited by 5hridhyan (Today 14:56:31)
Offline
> The advisory need to reflect the status of the arch package, not copy a generic list you could generate locally?
Not sure what you're saying there, and I am coming up with issues with my thinking.
I originally was figuring Arch could just keep a dupe of NIST source data only for packages maintained by Arch.
The problem there is that not everyone will necessarily maintain the same update level that Arch puts out, so Arch would then need to keep a database that houses every version it puts out for a given package.
For example, if Arch libxml is 2.15.4, and I'm still on 2.10.0 (shame on me), 2.15.4 may not show the advisories that exist on my version.
I also noticed that the CPE may not even have the latest version for a given "Product" (eg "libxml2 2.15.4-1" on Arch, but NIST latest is "Libxml2 2.15.3"), and will return: '{"resultsPerPage":0,"startIndex":0,"totalResults":0,"format":"NVD_CVE","version":"2.0","timestamp":"2026-10-24T14:44:04.506","vulnerabilities":[]}' (same for "products")
Another issue is dealing with the annoyance of version variants. Pacman is showing a bunch of styles implemented, rather than the typical major.minor.revision.
So trying for the latest version, getting the "resultsPerPage:0", then trying again with an earlier version by subtracting a "minor" value is out the window when there are dates or colons (and other styles) involved.
EDIT0: I should probably note that you don't have to even specify the version in "Product", and can just pull the latest version from that JSON.
Last edited by vindicator (Today 15:00:16)
Offline
On occasion arch will cherry-pick upstream patches ahead of the release for a rebuild of that upstream version that already has the cve fixed. This requires some form of curation.
Otherwise what's the point of such database when you just correlate the cave of the upstream version on your disk.
Since rolling releases cannot show a cave list that's relevant to any particular installation that, calculating that locally is arguably more relevant.
Offline