A cleaner/health check reporting app

General system Community contributions
1

Hey, I made a script that generates the report with system state snapshot and identified issues. That report could be then automatically fed to an AI agent like goose, for easier trouble shooting. If there are existing terminal scripts or ready to go solutions please advise :slight_smile:

2

Hello @Gbur79 , welcome to purple space :enos_flag: !

3

Grok Generated Feedback for the audit-script author

Context: Reviewed the script’s Arch security output (the “High / Medium / Low” package list plus arch-audit=WARN high_risk=4) against the official Arch Security Tracker and upstream fix versions. System under test was a fully updated rolling Arch-based install (checkupdates reported 0 pending updates). No host-specific inventory is included here.

What the script gets right

  • Pulling checkupdates, mirror age, Arch news, and arch-audit is a reasonable health snapshot.
  • The four High names (djvulibre, libxml2, linux-lts, pam) do correspond to real CVEs that the tracker still marks open.
  • The VirtualBox VNC news item is a real packaging/manual-intervention note, not a CVE. Reporting affected=NO when the package is absent or already handled is correct.

What is misleading

The High/Medium labels are treated as live risk on the installed system. On a current rolling install they are mostly tracker bookkeeping, not unpatched High holes.

arch-audit consumes https://security.archlinux.org/. When an advisory has an Affected version and no Fixed version, every later package is flagged forever. The Arch tracker often never fills in Fixed even after upstream and the Arch package have moved past the fix. The script inherits that and then presents it as “High risk!”

That produces false urgency: high_risk=4 on a box with zero pending repo updates.

Package-by-package (High)

Script claim Tracker / upstream Why the High label is wrong on a current system
djvulibre — ACE, High CVE-2025-53367. Tracker: Affected 3.5.28-6, Fixed blank, still “Vulnerable”. Patched upstream in 3.5.29. Current extra package is 3.5.30.1-1.
libxml2 — DoS, High CVE-2025-49794/495/496 + CVE-2025-6170. Tracker: Affected 2.14.4-1, Fixed blank. Fixed in 2.14.5 / 2.13.9 / 2.15.0 depending on branch. Current core package is 2.15.4-1.
linux-lts — multiple / info disc, High Open groups are 5.15-era 2022–2023 issues (AVG-2701, AVG-2834, AVG-2683). AVG-2834 even lists Fixed 6.2-1. Current linux-lts in core is 6.18.x. Stale kernel tracking, not a 2026 LTS High.
pam — arbitrary FS access, High CVE-2025-6020 (pam_namespace symlink/race). Tracker: Affected 1.7.0-2, Fixed blank. Affects ≤ 1.7.0. Fixed upstream in 1.7.1 (2025-06-17). Current core package is 1.7.2-2. Also only exploitable if pam_namespace is actually used; default Arch/EOS PAM stacks typically do not.

Medium / Low — same pattern

Examples the script labeled Medium that are old “Affected set, Fixed never filled in” rows:

  • cpio CVE-2021-38185 — current package is 2.15.x; fix landed in 2.14.
  • openvpn CVE-2021-3773 — 2.5.x-era; current is 2.7.x.
  • openssl mixes CVE-2022-2068 (c_rehash on OpenSSL 1.1.1) with a later Low issue. Current is OpenSSL 3.6.x; the 1.1.1 command-execution wording is not that package.
  • wget CVE-2021-31879, perl CVE-2020-16156 / CVE-2021-36770 — years old; current packages are far past the listed Affected versions.
  • Image/audio parsers (libtiff, openjpeg2, giflib, libheif, sox, lib32-libsndfile) — often never closed on the tracker; residual risk is “crafted file,” not a standing High.
  • systemd CVE-2025-4598 — local, conditional; Medium on paper, not equivalent to the High four.

Low (kexec-tools, lua51, nasm) is fine as Low if shown at all.

Suggested changes to the tool

  1. Do not treat “Vulnerable + no Fixed version” as High on the installed box. That state usually means “tracker incomplete,” not “unpatched.”
  2. Compare installed version to upstream/fixed versions, not only to the tracker’s Affected field. If installed > last Affected and current repo version is already newer than Affected, classify as stale / likely fixed unless the tracker still lists that current version as affected.
  3. Expose arch-audit -u (only issues with a recorded fix in repos) as the default “actionable” list. Keep the full dump as “tracker open, may be stale.”
  4. Split severity:
    • Actionable: repo has a newer fixed package (checkupdates or arch-audit -u).
    • Tracker-open, no fix recorded: informational, do not increment high_risk.
    • Exploitability: Remote vs local, default-config vs optional module (e.g. pam_namespace), needs crafted file vs network service.
  5. For linux / linux-lts / linux-zen, ignore open AVG groups whose Affected series is an older LTS line than the installed ABI (e.g. 5.15 advisories against 6.18).
  6. Don’t map OpenSSL 1.1.1 CVEs onto openssl 3.x without a version check.
  7. Arch news manual-intervention items should stay separate from CVE risk (the script already does this reasonably).
  8. Official-repo arch-audit does not cover AUR. If the tool is meant as a real host audit, say so, or add a foreign-package (pacman -Qm) caveat. AUR was the higher-impact Arch-ecosystem problem in 2026; this output does not speak to it.

One-line summary for the author

The High count is a faithful dump of stale security.archlinux.org rows, not a faithful statement of risk on a fully updated rolling system. Filter by “fix available in repos” and by whether the installed version is still in the Affected range, or the tool will keep crying High on packages that were patched upstream a year ago.

4

Please don’t post LLM generated outputs without labeling them as such.

This is still a conventional forum in which it is expected that a person has composed his own findings and documented his findings, in case someone has used LLM based tooling to check someone’s work, I personally would expect to clearly label it as such with a reference to the frontier model that has been used.

5

I will do so. Thanks for the heads up.

6

hmm should go to the rules set in one way or the other. ?

But anyway.. what would be about using LLM as assistant to translate or help getting info?

In case its fully non reviewed content one should consider not posting it at all.

7

Just to clarify, this is only my personal opinion.

Won’t hurt I guess. But its also a matter of administrative / moderation effort.

The use of translation tools is nothing I would prohibit at all. Usually these are 1:1 translations, not generative content.

And let’s not dissect every potential use case, such as posting AI generated memes or such… which is tolerable.

8

So there is different stuff that comes to reports category.
And lots of AI text go into this category.

What is reports? Lets say its some amount of specific information on some subject. That may be intrested to be read in full only in some really specific cases.

Reports sometimes attach to conversation. Usually as a link, spoiler or pastebin. Because, othervice they just flooding conversation.

So same with AI tool results.
They should be somehow be hidden as spoiler or link or something.
And most shurely got described first like
“This is report AI gave after I promted analize on this subject”.

So people can understand what this information even is.

More simple, if you not the author of text you posting, you need to specify who is, or how it was generated in case of numbers and such.

There is obviosly cases when it is not necessery.

But if you posting 1000+ wall of text, the basic decency is to specify it source if you not actually wrote it.

I hope this makes sense?

In short, I dont think there need to be special rules for AI, just basic rules of specifying source of report.

But given lots of ppl not knowing what reports is, may some explanation or mention needed.

Like most of time its basic decency. Like do not answer to other people by copypasting stuff.

9

would be a theme for a different topic :wink:

10

Yeah. May be a good idea to pop it out to separete thread. :+1:

11

Thank you, the script was updated as suggested.

12

Did you get permission to use the EOS name? I mean I can see people seeing this as and official EOS package when it is not.

This is something every user on Arch/Endeavour needs to know how to do manually before using a program such as this.

how is this different from other audit systems like archcanary?

13

That was my first thought.

The GitHub page is full of EndeavourOS references. It makes it appear that this is an official EndeavourOS application.

z
z1008×588 69.2 KB

14

Yeah really shady if you ask me.

15

If they want to continue to develop this app, the name should be changed to something far more generic. Call it System Cleaner, or something similar. And maybe in the description clarify that the app is for Arch and Arch-based distros.

16

I thought it was official, or at least had the blessings of the development team. If that’s not the case, then yeah, it should be named more generically. Having said that, there might be no malicious intent here, just someone who developed and uses it on EndeavourOS and didn’t consider the implications of the name.

17

Unless he was specifically instructed by an EOS developer to create this tool, he MUST change the name.
This name for a tool is very confusing

18

That is probably the case, IMHO. So, I hope they will take this constructive criticism to heart and change the name.

19

Same here, I also thought it was official.

20

That is why I asked. It just seems strange to me that everyone decides that we should be the guinea pigs for their projects. I for one am getting tired of Developers coming in and spamming their projects when they offer nothing to the community. I think those types of things should be reserved with proven memberships.