TrustSight diffs the new PKGBUILD against the one you have, runs a published rule set over the change, and reports what it read and what it could not.
Fully open source under MIT. The report points at where to look; it does not replace reading the PKGBUILD.
A review, as it prints
Whenever an installed AUR package has a newer version available, TrustSight clones the repository, diffs the new PKGBUILD against the one you have, and runs a published set of rules over the change. The output is a report: what changed, which rules fired, and what the analysis could not see. The report does not replace reading the diff: every finding names the line or URL it fired on, so you know exactly where to look, and you do the looking.
Everything runs locally. Nothing is executed (no PKGBUILD, no extracted command) and nothing is installed or modified. The report is deterministic: the same diff, the same configuration, and the same database produce the same verdict, so re-running a review gives the same answer. Verdicts are template-based plain English, e.g. Version bump. modified PKGBUILD. Signals: checksum set to SKIP; novel dependency 'pyfoo' added in depends.
Every finding is traceable to a diff line, a URL, or a novelty record, and anything the run could not examine is stated in the report.
An UNFLAGGED verdict means no published rule matched what was examined. It does not mean the package is safe, that the ruleset is complete, or that anything was executed.
TrustSight does not authorize an update. You do.
Errors, truncated diffs, and unexamined content are part of the report, never hidden by default.
A review is not a grep over the diff. It reads the diff, the files committed beside it, the maintainer and git history behind it, what the recipe declares upstream, and the AUR dependencies it pulls in. Then it matches published rules to that evidence and reports both what it read and what it could not.
What changed, and what sits beside it.
Who wrote it, where it comes from, what it drags in.
Published rules against the evidence actually read.
Evidence first, then what the run could not see.
At cycle endThe watcher correlates across packages (G001–G010) and reports campaign neighbourhoods; the optional L9 build lane inspects the built package, off by default.
Default output from trustsight review for two outdated packages. The first is a routine version bump with updated checksums; the second is a change worth a look before you build it, and it carries a representative finding from the core rule families, so each kind of signal appears exactly as a real report shows it. The dependency example shows the mini-cards nested in the output. Without flags the report shows the findings and the verdict, no score column.
trustsight review. A clean verdict means no known signal fired, not that the package is safe.The rules are pattern-based and published in full, so the precise statement of what the tool catches is the rules reference. The short version, from the README:
| Attack / risk | How TrustSight catches it |
|---|---|
Piped shell scripts (curl | bash, base64 | sh) | Scans every new or changed line for command-subprocess pipelines (R001); about 100% recall on known cases. |
Obfuscated commands (encoded strings, environment subversion like LD_PRELOAD) | Resolves variables and decodes known obfuscation patterns; flags build-environment tampering (H025, H036). |
| Checksum disabled or removed | Compares the old and new sha256sums / md5sums arrays (H001, H002). |
Source URL typosquatting (githab.com for github.com) | Character-level edit distance against known forge domains (the confusable-domain pipeline). A prior, not a rule. |
Package-name typosquatting (libuvc resembling libuv) | Edit-distance comparison against more popular packages in the seed database (H029). |
| Source URL swapped without a version bump | Tracks source URL changes that do not come with a new version (C003). |
| Novel, never-before-seen URLs or maintainers | Compares against the signed release seed: 185,902 known source URLs, 36,912 hashed maintainer identities and 215,504 dependency names, in the novelty tier. |
| Known-bad indicators | Matches package URLs and strings against signed, federated IOC baselines; reported in the IOC tier, outside the heuristic score. |
| Unicode bidi override attacks (invisible characters that change how text displays) | Detects directionality overrides and homoglyph codepoints in PKGBUILD content (R013, FATAL). |
| Reviewer-directed instruction templates in package metadata | Flags common reviewer-manipulation templates as a high-severity tripwire (R012); a match requires review, not an inference about author intent. |
| GPG verification removed | Detects when validpgpkeys was populated and is now empty (H024). |
| Untrusted maintainer takeover | A maintainer change to someone never seen before (H026). |
| A stale package suddenly revived | A package with no updates for over a year suddenly gets one (H022). |
| Accelerated release cadence | Three or more commits in the last 24 hours (H028, informational). |
Sabotage payloads (fork bombs, rm -rf /, disk wiping, permission sabotage, service disruption, coin miners, log wiping) | Command-position matching separates build-sandbox housekeeping (rm -rf "$srcdir/x") from system damage (S001-S008). |
| Orphan hijacking (adopted from orphan, then rewritten with no upstream change) | The maintainer field against its last recorded state, plus a recipe-only-change signature and the composition with an unpinned build fetch (H086-H087-H088). |
Build steps that fetch unpinned code (npm install in a build function) | Not scored. Reported as the unpinned_build_deps coverage gap and as W002, because what the build will run is not in the analysed text and no checksum covers it. |
| A risky AUR dependency (novel, typosquatted, or hijacked) | Walks AUR dependencies to a configurable depth (default: direct ones; --depth to go further) and analyses each as a package in its own right: novel (D001), typosquatted (D002), network-using makedepends (D003), and provides hijacks (D004). |
Every finding is reported with the rule that fired and the line or URL it matched, so nothing on this page has to be taken on faith. The full catalogue (pattern, severity, and measured fire rate for each rule) is in the rules reference.
Every result reduces to one of four tiers, which says what kind of information a signal is. Nothing subtracts: no signal ever lowers a score.
| Tier | What it is | Example | Weight |
|---|---|---|---|
| A: Structural | Direct structural facts from the diff. | curl | bash (R001); checksum set to SKIP (R004) | The strongest evidence |
| B: Priors / Context | Source-bucket classification of every new URL. | an unknown domain adds weight | Moderate: a prior, not proof |
| C: History / Novelty | First-seen history for URLs and maintainers, maturity-gated. | URL first seen globally; maintainer first seen | Scales with observation history |
| D: Verification | What the recipe declares: checksums, PGP keys, pins. | P001-P008 | 0: reported, never scored |
| Reported, not scored | Analysis boundaries: bytes the package will run that this run could not read. | W001-W012 | 0: always shown |
A declared checksum or PGP key costs an attacker nothing to claim, so tier D is reported at weight zero, for you to check against the file. TrustSight does not verify these claims; it reports that the recipe makes them.
Separate from the tier, every rule also carries an evidence layer, L1 to L8, naming the kind of evidence a finding is. A layer is not a stage an attacker passed through: a finding at L4 does not mean the package cleared L1 to L3, and a layer that stayed silent is not a clean bill of health. The report keeps two facts separate for every layer, whether it fired and whether the change was read in full, so a finding never hides that its layer was also unread.
| Layer | The question its evidence answers | Rule families |
|---|---|---|
L1 Structural coherence | Does the change hang together as an honest edit? | C, M |
L2 Readability | Was anything hidden from the reader? | W, refusal rules X026/X027 |
L3 Payload signature | Does it do a known-bad thing? | R, S |
L4 Evasion shape | Was it written to defeat reading? | X, E |
L5 Behavioral suspicion | Does the package’s story make sense? | H |
L6 Ecosystem memory | Has the ecosystem seen this before? | D, T |
L7 Known indicators | Is it on the list? | I |
L8 Campaign correlation | Do other packages tell the same story? | G |
A layer label names the check that produced a finding, never how far an attacker got. The optional L9 build lane inspects the built package rather than the diff, so it is not one of the eight and it is off by default.
Against the locked 3,739-diff benign corpus, 72.3% of benign diffs score 0. Benign diffs reach a 95th percentile of 30; the CRITICAL-class corpus has a 5th percentile of 60. The 20-point threshold is not the benign p95; it sits at the 92.9th percentile, so about 7% of benign diffs land above it. What matters is that the two distributions do not overlap.
The separation is enforced, not described. CI re-measures both distributions against the shipped configuration on every push and fails the build if benign p95 is no longer below malicious p5. A change that narrows the gap is rejected.
Testing. The test suite covers 6,828 tests across 172 files. CI enforces separate security and calibration gate suites on every push and pull request. Among them: CRITICAL recall stays at 100% (every labelled malicious sample must fire the rules it is labelled for); the separation gate requires benign p95 to stay below malicious p5; and any scoring rule that fires on more than 30% of the benign corpus is demoted to INFO, because a rule that fires on a third of ordinary updates is not a signal. The rules are checked against their documentation on every test run, so a documented pattern cannot drift from the one that runs.
Isolation. The tokenizer that resolves shell variables is the one place a crafted PKGBUILD can amplify (a chain of b=$a$a assignments doubles per level), so it runs in a separate, resource-capped process: no inherited descriptors, a hard memory ceiling, and a wall-clock timeout. The analysis process reads the result as data and never parses that text itself. If the child cannot answer, the package is reported as not vetted rather than analysed without it, so a failed parser can never read as a clean diff.
Configuration. The rules live in ~/.config/trustsight/rules.toml and are loaded at runtime, so you can change a severity, disable a rule, or add your own pattern. config.toml controls review behaviour:
# ~/.config/trustsight/config.toml
[depth]
levels = 1 # 0 off, 1 direct deps, n levels, -1 all
[rules]
experimental = false # rules whose fire rate is not yet measured
[seed]
auto_import = true # fetch the signed novelty seed on first run
A PKGBUILD is a recipe, not a meal. A signed, version-bumped PKGBUILD whose checksum matches a backdoored tarball is invisible to this tool. The reasons are structural, and they are documented rather than hidden:
Malicious upstream tarballs. TrustSight audits the PKGBUILD, not the binaries it downloads. A clean build file can point to a compromised tarball.
Deliberately unremarkable attacks. With no commands added, no URLs changed, and no checksums disabled, there is no diff signal. The rules detect patterns associated with compromise, not compromise itself.
Dependencies past the configured depth. Past --depth, and past the hard ceilings on an exhaustive walk, the closure is unread, and the report says so with a deps_not_scanned coverage gap.
Runtime behaviour. Nothing is executed, sandboxed or otherwise, because executing a PKGBUILD would let hostile input detect the review and change its behaviour. Static analysis by design.
Zero-day structural attacks. The rules are pattern-based. A novel attack that leaves no matching pattern will not fire.
Every shipped rule (its pattern, its severity, and its measured fire rate) is published in the rules reference. Rules are grouped into 13 namespaces; the categories under each namespace are the kinds of claims its rules make.
140 pattern rules read the diff and the variable-resolved command text. Each is a published pattern with a severity from INFO to FATAL, and a FATAL finding pins the verdict to 100: a bidi-override attack cannot be weighted away. The rules group by the kind of claim they make, from fetch and execution and integrity through obfuscation, deception, temporal context, composition, and indicators, and every match is reported with the line or URL it fired on.
Thirty-two context rules reason about the diff as a whole rather than any single line, comparing the old and new states of the same field: a source URL that changed without a version bump, a checksum list that shrank, metadata that contradicts itself, unread content moved under a stable version. Where the pattern rules ask what a line does, the structural rules ask whether the change is internally consistent, across integrity, install and persistence, fetch, composition, staging, metadata, and deception.
Four rules treat the dependency graph as first-class evidence. A review walks a package's AUR dependencies, direct ones by default and deeper with --depth, analysing each as a package in its own right: has it been seen before, does its name resemble a more popular package, does it fetch over the network during build, does it hijack a provides others rely on. Novelty is judged against the same signed seed the URL rules use.
Eight rules look for payloads aimed at the operator's machine rather than at getting something out of it: resource exhaustion, deletion, permission sabotage, service disruption, and resource theft. What unites them is that the machine running the build is the target. Each rule is written against a distinction, not a command: rm -rf inside the sandbox is housekeeping, rm -rf / is an attack, and a mention is not an invocation.
The evasion technique, not the payload it hides. Every other family fires on what a diff does; these fire on how it was written. Partial quoting, array routing, command substitution and other tokenizer-defeating shapes assemble an executable name no pattern ever sees, so a word the tokenizer could not reduce to a literal is itself the signal. One rule covers the evasion surface of every payload rule at once, and a defeated tokenizer produces a CRITICAL finding rather than silence.
Six meta rules reason over the finding set and the instrument itself rather than the diff: a declared practice contradicted by structure, a weak signal that spans several layers, or a composition no single family owns, plus three tool-health checks (a co-fire that should have appeared, a licensor absent on a licensed shape, a campaign class re-armed too often). The tool-health findings carry weight 0 and never join a package’s finding set, so a detector-health note cannot move a verdict.
Three entropy rules treat the statistics of the added text as evidence: its compression ratio, the fraction that is encoded alphabet, and identifier entropy. They mark a change that sits outside the normal distribution; suspicion, never a verdict, with thresholds calibrated on the benign corpus.
Five temporal rules track the identity behind the recipe rather than its content: a signing key never seen before, a maintainer domain first seen now, a key rotated, AUR metadata that runs ahead of the git tip (commits were pushed and later stripped), and a packager absent from the retained commit history. They say how new the thing behind the update is, independent of what the diff changed; the packager check is weight 0 and corroborates rather than scores.
Ten correlation rules look across packages in a window rather than inside one: a host, a literal, an adopter, or an upstream dependency shared by several recent analyses, a maintainer publishing name-clones of popular packages, a first-seen account adopting many dormant packages, a watchlisted subject, a package in an active campaign’s neighbourhood, and a plurality of first-seen hosts across strangers. They run at cycle end, never per package, so a campaign that is invisible in any single diff becomes visible in the set. Only the shared-signal rules score; the neighbourhood, watchlist and host-census findings are reported at weight 0.
Eight artifact rules inspect the built package, not the diff. The optional L9 build lane reads the produced manifest to catch a setuid file, an undeclared unit, a library outside depends, or an embedded eBPF object. Reported outside the static score, and off by default.
Ten upstream rules read only what a recipe declares about upstream, never fetching it. Six manifest rules cover the dependency manifests committed beside the recipe: a manifest added or removed, a dependency delta, a new remote source, a redirected resolver, a dependency-surface jump, and a manifest changed without its lockfile. Four release-integrity rules are fed by a signed upstream baseline: a git-history credential sweep, a new CI surface committed into the AUR repository, and a source the public cannot inspect. Read from the repository tree and the diff; upstream content is never fetched.
What the recipe declares, not what the analysis found. These findings read the claims a PKGBUILD makes about itself: checksums declared for every non-VCS source, validpgpkeys present, signatures sourced, sources pinned to a commit hash or tag, downloads over HTTPS, or a branch/unpinned ref tracked. Every one is INFO and checkable by the reader against the file itself. They are reported, never credited: a signal an attacker can assert for free must not move a score.
Not a claim about the recipe but about the analysis: something the package will run that this run could not read. A build script that executes a file not declared in source=(), a patch not committed to the repo, a manifest generated at build time, a dependency resolved from a registry, a declared upstream this run was not allowed to fetch, or a terminal render that had to cap its finding list. Each is reported so the reader knows the boundary of what was examined; none contributes to the score.
Counts are per the generated rules index; the 22 category pages are closed, so every rule has exactly one page. trustsight lint-rules checks the shipped rules against their documentation on every test run. The rule files themselves are part of the open source repository: read a pattern, change a severity, or rebuild the tool, and nothing hides behind a binary.
aur.archlinux.org/trustsight.git does not exist; build from the PKGBUILD in the repository, which is MIT licensed and fully open source. The PKGBUILD runs the test suite during build, and makepkg -si pulls the dependencies in as proper pacman packages.pacman.Novelty detection needs a baseline of what is normal in the AUR. On an empty database every URL looks first-seen and every maintainer looks new, which turns the novelty signal into noise. So the tool ships a seed of prior knowledge built from the AUR git mirror: 185,902 normalised source URLs, 215,504 dependency names and salted hashes of 36,912 maintainer identities. It is published as a signed release asset rather than shipped inside the package, because the AUR is exactly the channel under review. The first time you run trustsight review, the tool downloads the seed and imports it only after its ed25519 signature verifies against a key pinned in the package. Offline, the attempt is skipped and the run starts cold: the honest fallback for a tool that refuses unverified data.
Installing now is what makes the seed useful. Every review you run records observations in your local database, and novelty signals scale with that history: the maturity factor is observation_count / 50, so a package reaches full novelty weight after about 50 analyses. The seed supplies the bootstrap: it recognises about 86% of the source URLs in a package’s most recent update, and your own runs take over as soon as they outnumber it. Install today, review the next update, and by the time a real anomaly shows up the tool has already seen what normal looks like for your package set.
No. TrustSight is a second pair of eyes, not a substitute for reading the diff. Every finding points at the line or URL it fired on, so the report tells you where to look, and you still do the looking. The tool’s own principle is that the report is input to a decision, not the decision: it does not authorize an update, you do.
The tool never runs the PKGBUILD, never executes extracted commands, and never installs or modifies anything it reviews; it reads diffs and runs pattern rules over the text. The package itself is MIT licensed and open source, and the PKGBUILD in the repository runs the test suite during build. Reviewing a package is not the same as trusting it, and the same applies to the reviewer.
It means the score stayed at or below 20: no published rule matched the evidence that was examined. It does not mean the package is safe, that the ruleset is complete, or that anything was executed. Absence of signals is a statement about detection, not about the update.
Executing a recipe written by the party under review would let hostile input detect the review and change its behaviour. Static analysis is a deliberate boundary: the tool reads what the diff says, not what a sandbox would run. Runtime behaviour is listed as a structural limitation, not an accident.
About 7% of benign diffs score above the threshold. The tool reports evidence first and the score on request, so a flag is a reason to look, not a verdict to accept. Open the report, check which rules fired and where, and decide from the diff. That is the intended workflow, not a false-positive problem.
The first run imports a signed seed of 185,902 normalised source URLs, 36,912 hashed maintainer identities and 215,504 dependency names, verified against a key pinned in the package. Novelty signals are maturity-gated: they scale with your own observation count (observation_count / 50), so a cold database contributes nothing and your own reviews take over as history accumulates.
The analysis is local. The only two declared network hosts are aur.archlinux.org (the RPC, the metadata dump, the git clone, and cgit) and the GitHub releases channel, used only for verified baseline assets such as the seed and the IOC lists, on explicit commands or first-run auto-import. The tool never connects to a host named by the package under review.
makepkg builds a package’s depends on your machine in the same run, so a dependency is part of what actually executes. A default review analyses direct AUR dependencies and summarises them; trustsight review --deps reviews each as a package in its own right, and --depth n walks deeper. The walk is bounded, and a closure cut short is reported, never hidden.
No. TrustSight is a review tool, not an execution gate. It produces evidence about a diff and a verdict in plain English; you decide whether to build and install. Nothing the tool does blocks makepkg, and nothing it says is permission.
The default output is findings, the change summary, and the verdict, because a number invites a decision the tool is not entitled to make. The score exists, is deterministic, and is available with --score (and in JSON with --score or --risk). The evidence is the product; the score is a summary of it.
It says so. Coverage gaps such as deps_not_scanned (dependencies past the configured depth) and unpinned_build_deps (build steps that fetch unpinned code) are part of the report, and an analysis with a coverage gap is never issued as UNFLAGGED. A report that hid what it could not look at would be indistinguishable from one that was switched off.