AURWatch: a static-analysis dashboard and JSON API for AUR PKGBUILDs

Disclosure: I wrote this and I run it as a service, so yes it is self-promotion, but I think it is useful enough to the people here who install from the AUR to be worth a few minutes. https://aurwatch.org/

Three things up front, because they matter more than the feature list:

• It only reads text, it never runs anything. It fetches each PKGBUILD (and any referenced .install scriptlet) and analyzes the source with pattern rules plus, for the ambiguous cases, an LLM. Nothing is executed, sourced, or built, so looking a package up here cannot harm you.
• It cannot prove a package is safe or malicious. A clean result means "no rule fired and nothing else flagged it", which is the expected result for almost every package and tells you very little on its own. It is not a safety guarantee.
• Both layers are fallible. Pattern matching does not stop a determined attacker who obfuscates, hides a URL behind a variable, or fetches the payload at runtime from a clean-looking host, and the LLM is probabilistic, so it produces false positives and can be wrong or talked into a bad verdict. It catches the lazy and the obvious, not the targeted.

So this is a triage and second-opinion aid, not a replacement for reading the PKGBUILD yourself. I know the reflexive answer here is "just read the PKGBUILD", and you should. This is a complement to that, especially if you are still learning to tell a normal PKGBUILD from a malicious one.

What it is

AURWatch is a continuously updated public dashboard plus a JSON API that scans AUR PKGBUILDs for suspicious or dangerous patterns. It pulls the AUR metadata dump, detects which packages changed, fetches only those PKGBUILDs and their .install scriptlets, and runs a rule engine. It covers the whole AUR (100k+ packages as of mid-2026) and re-scans changed packages every 2 hours. It caps itself at 10 concurrent requests, throttles to avoid hammering the AUR, and identifies itself with a custom User-Agent so maintainers can contact or block it.

The dashboard is a searchable table of every package, overall stats, a flagged-over-time chart, and a per-package detail page that highlights the exact offending lines with a plain-language explanation of why each one was flagged. The detail page is the point: do not trust my counts, click through to the actual lines and judge for yourself.

A real find

A brand-new "human-in-the-loop MCP server" package shipped an /etc/sudoers.d drop-in, plus a self-update script, plus a systemd service. The net effect: it would update itself outside pacman, with passwordless sudo, and with no checksum verification on any future update. The rule engine surfaced the install-time patterns; a smaller first-pass model rated it only "low"; a stronger model (Claude Sonnet) escalated the self-update-plus-sudoers combination to high. That case is what led me to add a dedicated rule for sudoers drop-ins, setuid binaries, and self-update mechanisms.

It clears noise as well as raising it. sublime-text-2 and chromium-widevine were rule-flagged for an "untrusted download host", but those are the official vendor hosts, so the LLM pass downgraded them to clean, which matched reality. A votes-prioritized re-review of about 2,200 medium-rated packages cleared roughly 500 such false positives, so it is not trigger-happy. About a dozen piracy or license-circumvention packages (cracked software and game ROMs that do not belong in the AUR) were raised to high in one pass.

How it works

Tier 1: a deterministic rule engine (always on). I try to keep false positives low. A sample of what it flags:

• curl/wget piped into a shell
• eval of a URL
• base64 or compressed payloads that are decoded and executed
• a downloaded file later made executable and run
• npm/pip/cargo/go/etc. installing named external packages at build time (a bare npm install does not flag; unpinned network fetches are a known blind spot, since the rule keys on named installs, not on pinning)
• source=() URLs on hosts outside a trusted allowlist (this heuristic is expected to fire on unknown hosts; the vendor-host example above is exactly the case the LLM pass exists to triage back down)
• bash /dev/tcp redirections (a bash feature, not always malicious, so treated as a soft signal)
• sudoers drop-ins, setuid binaries, and self-update mechanisms that write outside pacman or with elevated privileges (not benign version checks)
• softer signals like "very new and few votes" or "recently orphaned and re-adopted"

Comments and plain-data heredocs are masked before matching, so a curl | sh quoted inside a help string should not false-positive. Popularity is a triage and noise signal, not a trust signal: more than 100 votes downgrades a heuristic finding by one level (popular packages do get compromised), but it never downgrades a clear remote-code-execution finding.

Tier 2: an LLM second opinion for the ambiguous gray zone and flagged packages, which the instance above runs under a strict monthly cost cap. A smaller model does the first pass; a stronger one (Claude Sonnet) handles the harder and HIGH reviews plus a votes-prioritized sweep of medium-rated packages. The verdict is shown as an llm_review entry with the model name, its confidence, and a one-line rationale. It can raise a finding the rules missed and it can lower a rule-only false positive. Lowering a verdict is the riskiest thing in the system (an LLM can wrongly downgrade a real threat just as it wrongly downgrades noise), which is why the rules never let it touch a clear remote-code-execution finding. If a call fails it falls back to the rule-only verdict, and the absence of an llm_review entry makes that visible.

Severity is clean / low / medium / high, with separate flags like "piracy" and "broken".

JSON API

For a scriptable "is this package flagged?" check:

• GET /api/v1/check?pkg=<name> returns {"status":"clean|low|medium|high|unknown","rules":[...],"last_scanned":...}
• GET /api/v1/flagged, GET /api/v1/stats, GET /api/v1/packages
• Interactive docs at /api/docs

unknown means the package is known to AURWatch but not yet scanned, which is distinct from clean. Please do not use this to auto-approve installs: a clean result is not a green light, it only means no rule fired.

Practical bits

• It is a free service that I host and run. There is nothing to install: it is the website plus the JSON API, and using it costs you nothing.
• It is closed source, and I am not planning to open(for now) it. That is a fair thing to hold against a security tool, so the whole design leans on verifiability instead of trust: every flag links to the exact PKGBUILD lines behind it, a clean result is explicitly not a safety claim, and you are meant to confirm anything that matters against the real PKGBUILD yourself.
• Site: https://aurwatch.org/

I would rather hear where this is wrong than where it is right. If you find a false positive, a missed case, a rule that is too aggressive, or a claim above that does not hold up, please tear into it. That feedback is the most useful thing I can get. And again: still read your PKGBUILDs.

I've been building Neutrino, an end-to-end encrypted messenger that runs entirely in the browser, and I'd like to share it here for feedback. It's a solo side project — not commercial — and the design goal is to trust the server as little as technically possible: no account, no phone number, no email, no metadata collection.

What I think is relevant for this sub: the entire client source is auditable, with a SHA-256 hash per file, so you can verify that what runs in your browser matches the source.

- Live instance: https://neutrino-chat.org

- In-browser source view: https://neutrino-chat.org/code

It's still in beta right now, so the code lives only on the site for the moment — once it's stable I'll publish it properly on GitHub under an open-source license.

**Identity is a 12-word seed phrase**

Instead of a login server or user database, identity is a BIP-39 seed phrase. Keys, routing ID, and the encrypted backup are all derived from it. To add a contact you exchange a short one-time rendezvous phrase or ID — no phone-number contact discovery, no server-side address book. Downside: lose the phrase and there's no recovery.

**What the server sees**

It's meant to be a blind relay: it forwards ciphertext by routing ID and nothing else. Zero-retention, no IP logging, access logging disabled at the reverse proxy. Honest about the limits: like any relay it routes frames between routing IDs in real time, so timing and routing IDs are visible to it even though it persists none of it — and a routing ID isn't tied to a real-world identity.

**Crypto choices (deliberately boring, nothing hand-rolled)**

- X3DH + Double Ratchet for forward secrecy / post-compromise security (same design family as Signal)

- SPAKE2 over Ristretto255 for pairing

- ML-KEM-768 (FIPS 203) mixed into the handshake for post-quantum

- AES-256-GCM for message and file encryption

**Other design decisions**

- RAM-only client — all state lives in the tab; close it and it's gone. No localStorage, strict CSP, everything self-hosted (no CDNs, no Google Fonts).

- Traffic padding (dummy packets at random intervals) against traffic analysis.

- Safety numbers for out-of-band MITM verification, disappearing messages, auto-lock, and an encrypted cross-device backup the server can't read.

This is a solo project and it has not been professionally audited, and I'm not a cryptographer — so I'm explicitly not recommending it for anyone with a serious threat model (use Signal for that). I'm sharing it because I'd like people to read the code and poke holes in it.