Secure Package Management

[keanehatescoding]

Imagine an official archlinux maintainer or an omarchy repo maintainer was compromised. Would you be able to realize they are distributing infected packages? Is there a way we could realize this before installing an infected package?
How then?
Introducing ...

Pre-Install Package Auditor

A local, offline-first auditor that inspects a package (and its scripts/metadata) before extraction or installation. It returns Allow, Suspicious, or Block/Quarantine, with clear reasons. It would run before installing any package i.e a preinstall hook

How would it work?

1. Signature / Heuristic Engine

Curated YARA-style rules + heuristics for high-signal patterns: malicious eBPF/DKMS, suspicious post-install scripts (curl | sh, network calls, cron/ld.so writes, setuid abuse), obfuscation markers, crypto-miner strings, anomalous file placement. Context-aware scoring (normal in kernel packages, abnormal elsewhere).

2. Structural / AST Analysis

Parse install scripts (shell, Python, Node…) into ASTs or simple control-flow. Flag dynamic execution (eval/exec/base64 chains), unexpected process/network activity, privilege-escalation patterns, and mismatches with declared dependencies. Optional lightweight binary inspection (strings, imports, sections).

3. AI Review (optional)

Feed flagged artifacts (PKGBUILD, postinst scripts, diffs vs previous version, high-entropy files) to a local or privacy-preserving model. Output structured risk score, findings, and recommended action. Used mainly for ambiguous cases; always show the exact input the model saw. Fully disableable for offline use.

Limitations

Sophisticated/novel malware and heavy obfuscation can still evade static + simple AI checks. Binary-only packages give less visibility than source packages. Prompt injection i.e a PKGBUILD with a hidden field telling the AI to treat this package as safe, but I believe we can reduce this as we improve the system.

Future Goals

Say this program proves to be really good at detecting malicious packages. We can create dedicated runners which would run before a omarchy repo gets an updated package. Additonally we could even add it to npm, gem, pip, nix, rust ecosystem. We can train it on past incidence and even create a bug bounty program where if your able to find a way to bypass the program then you will be rewarded.

I have partially vibe-coded an AST implementation you can check it out here https://github.com/keanehatescoding/aur-manager.
Trusted package managers and mirrors can be compromised. Malicious packages may ship before detection. “It came from the official repo” is not sufficient proof of safety.

[juancrfig]

It sounds like a good idea. AI models are already smart-enough to detect vulnerabilities. Obviously not all, but I think it has already reached pareto.