TrustSight: automated AUR PKGBUILD review, seeking technical criticism

aegis_eclipse · 2026-08-07 15:17:54

@Seth, I took you objections (and @Lone_Wolf contributions too) and am currently working on the security thesis of the tool. I'll come back to you in a few days with an update.

All bugs mentioned in this thread have been fixed in the next release.

loqs · 2026-08-08 02:17:35

Did you scrape the AUR and feed that scrape to an LLM? If so was the provider you used one with a zero data retention and no training policy and in compliance with GDPR?

aegis_eclipse · 2026-08-09 03:06:32

Scrape? Yes, the published metadata dump plus PKGBUILDs from the git mirror, rate-limited.

LLM? No corpus, no bulk data. Only TrustSight's own output on single packages, while working on how the report renders. That output carries individual maintainer name and email from git commit identity, so yes.

That's not something I accounted for when building the tool. What exactly is the issue you're pointing at, and how do you think TrustSight should handle it? I'm thinking of hashing the maintainer names and emails in the bundled seed, which carries ~36k records.

loqs · 2026-08-09 04:32:54

I was wondering if you had accidentally provided all of AUR to one of more LLM providers. You do not see an issue in doing that? What is the lowest threat level a frontier LLM achieved when attempting to bypass TrustSight while still meeting your definition of threat?

carlosplanchon · 2026-08-09 04:48:52

Hello! o/

I assume a tool like TrustSight can't catch 100% of malicious packages.
But your idea, @loqs, I see it as a good one. Having some form of adversarial testing against a tool like this would be an appropriate way to evaluate its security properties within clearly defined bounds.

I think it could eventually be treated as a separate tool. Idk. "Trustsight adversarial harness" hahah

aegis_eclipse · 2026-08-09 05:51:22

loqs wrote:

I was wondering if you had accidentally provided all of AUR to one of more LLM providers.

No, I didn't. As most patterns are regex based, I just filtered through known infested/bad PKGBUILDS and searched for patterns.

On whether it would be an issue: yes, I think it would. Not primarily as volume, but because the AUR carries maintainer names and emails from git commit identity, and bulk-sending third parties' identifiers to a processor isn't mine to do. That's also why I'm hashing them in the bundled seed (change dropped in next release).

loqs wrote:

What is the lowest threat level a frontier LLM achieved when attempting to bypass TrustSight while still meeting your definition of threat?

By "meeting the definition" I mean a bypass that suppresses a finding while the payload still works, not one that evades a rule by making the PKGBUILD harmless.

As for this, Fable 5 refused the task outright; I didn't pursue a jailbreak. Same for Opus 5. Opus 4.8, though, went on to try and avoid detection, generating 39 different malicious PKGBUILDs, and found one bypass in the differ system, the other 38 failed. Already fixed and shipped in the next release.

Deepseek V4 Pro failed to produce any working bypasses on 31 generated PKGBUILDs.

And then there's Kimi K3. It generated 152 PKGBUILDs, found 9 bypasses (all of them within the tokenizer's non-normalization of partial quoting and array routing). The 9 are in the corpus as failing fixtures until they're closed.

That's 10 out of 222 generated, and about ~6ish million tokens, so not free to try. Kimi K3 found the most, but it also generated the most attempts, so I can't separate capability from volume. The comparison isn't controlled.

The pattern across all 10 bypasses is worth mentioning: nobody beat a rule. Every successful bypass was parser-level, partial quoting, array routing, differ handling. The rules held; the thing that feeds them didn't.

Worth being precise about what that ordering means: Fable 5 and Opus 5 refusing is a safety property of those models, not evidence they couldn't, so a jailbreaked version could still be capable. The capability floor is untested at the top end, so the honest answer to "lowest threat level" is that I've measured which models would, not which could.

Worth saying that this has been a part of the process rather than a one-time exercise. Every bypass found becomes a fixture in the corpus, so the same evasion can't reappear silently. If you or anyone else wants to point a model at it, I'd take the findings, that's a better source of rules than my own imagination, and the failure modes so far have all been in the tokenizer rather than in the rules themselves. You can point them out here or as a github issue. https://github.com/emiliano-go/trustsight/issues

carlosplanchon wrote:

I assume a tool like TrustSight can't catch 100% of malicious packages.

And it's not supposed to. The answer is in the security model: https://trustsight.emiliano-go.com/security/. Trustsight is supposed to detect as much as possible, "possible" being patterns defined in the security model. Malicious tarballs or a compromised codebase are out of scope, a PKGBUILD that fetches a poisoned tarball with the correct checksum is honest by every static measure. No static analysis can see it. That's a property of the problem. TrustSight audits what the recipe says, not what the upstream bytes are.

carlosplanchon wrote:

I think it could eventually be treated as a separate tool. Idk. "Trustsight adversarial harness" hahah

The harness idea is right, and the pieces mostly exist already. Every bypass found becomes a corpus fixture, so there's a growing labeled set of "things that evaded detection and why". Making that runnable by anyone, against any build, is a small step from where it is. If nothing else it turns "an LLM found ten bypasses" from a claim into something reproducible, which is the only version worth stating. The 212 that failed matter as much as the 10 that worked. They're what makes "the rules held" a measurement rather than an assertion.

aegis_eclipse · 2026-08-11 02:48:18

Well, a v0.12.0 is here, and applies most of the things we've discussed in this thread. The core tool is still the same (local, deterministic, regex-based PKGBUILD diff analysis) but everything around it was rebuilt to remove single points of failure and to make the "input, not verdict" claim enforceable.

The security model is now a formal, four-part document with 45 CI-enforced gates that fail the build if any claim stops being true.

What is new (TL;DR): a signed release channel that delivers the novelty seed and IOC baselines over the wire, verified against the pinned Ed25519 key. The seed no longer bundles plaintext maintainer identities; it stores ~36k names and emails as salted SHA-256 hashes and migrates legacy seeds automatically. The IOC federation imports signed, curator-attributed indicators that report as detection, never enter the score, and fail loudly when expired rather than silently dropping.
There are now five first-class coverage gaps; an incomplete analysis can never render as unflagged, and every verdict band is shown with an "(incomplete analysis)" qualifier. Positive evidence like declared checksums or PGP keys is reported at weight zero so it cannot buy points back for an attacker. The engine is about forty percent faster per diff, and the rule set picked up R137 (fetch-then-execute, CRITICAL), R132 (indirect command expansion) and R136 (committed-file execution) alongside an evasion fixture corpus. Three gaps remain open and documented as known false negatives.
The full release notes are on the v0.12.0 release: https://github.com/emiliano-go/trustsig … ag/v0.12.0

The signed seed baseline and its asset hashes are on the baseline-2026-08-10 channel release: https://github.com/emiliano-go/trustsig … 2026-08-10

If you have been running TrustSight and hitting edge cases, false positives, or anything that smells like a coverage gap misfire, I still want to hear about it.

Thanks again to Seth, Lone_Wolf, loqs, Trilby, NuSkool and everyone else for the reviews!

Lone_Wolf · 2026-08-11 10:15:04

Got a validation error with the PKGBUILD
Direct download from https://codeload.github.com/emiliano-go … gs/v0.12.0

$ sha256sum trustsight-0.12.0.tar.gz 
4cff00dbd493c492d06d056e6720ceb5f4e78a6bb0f3caba32af94cc256ee917  trustsight-0.12.0.tar.gz
$

https://github.com/emiliano-go/trustsig … r/PKGBUILD

sha256sums=('43556956c3e00f9ef257bb6b40f97d445a20c4e42b9fbb36ef05ff9f7bd4cc02')

aegis_eclipse · 2026-08-11 12:57:45

Fixed. The stale checksum was from repointing the tag after the PKGBUILD was committed. Also note that I found another issue where gh source archive metadata changes when the tag moves, even if file contents are identical, so v0.12.0 stays at 91a5659 permanently. The fix is on master, not released yet.

Thanks for the report!

Last edited by aegis_eclipse (2026-08-11 15:58:40)

aegis_eclipse · 2026-08-11 15:51:57

I'm gonna focus on polishing the tool before next release. There's also an API almost fully done on a separate branch, which would allow users to run TrustSight inside python scripts. If the tool ever gets to need it, a service/daemon that exposes an non-python API could also be done, probably in a separate repo (?. Insight on that is welcome.

Also, probably later this week I'll send an architecture proposal for review of the test harness that was mentioned before, which will be implemented in a dedicated repository.

Edit:

Small clarification on the API I mentioned: it's a Python library interface (import trustsight). About the daemon, it's a Unix socket wrapper that exposes the same CLI commands for scripting. Same machine, same local database, just QoL for non-python users.

Last edited by aegis_eclipse (2026-08-11 16:06:18)

aegis_eclipse · 2026-08-12 03:15:39

Following up on the bypass discussion and the harness idea, I want to float a concept for community opinion before I spec it out, so I can gather some feedback while I clean the codebase.

The problem: The 10 LLM bypasses found so far were all tokenizer-level (partial quoting, array routing, nameref, command substitution). The rules themselves held; the thing that feeds them didn't. Closing those gaps (R133-R135, the open gaps around array routing, namerefs, and command substitution) requires careful tokenizer work that takes time and risks over-expansion, and, honestly, is complex regex above my current comfort level. The idea: "Crossfire rules", a layer that fires not on the malicious payload, but on the evasion technique used to hide it. The attacker can't win by being clever, because cleverness itself becomes the signal. These would be technique-based, not target-rule-based. One crossfire rule covers the evasion surface for R001, R127, R137, etc. simultaneously.

The simple rules are X001, X002, X005, X007, and X008.

X001 catches encoded payload execution: base64, hex, or octal strings decoded and piped to a shell, which is nearly impossible to construct benignly in a PKGBUILD and maps directly to the Atomic Arch hex-encoded second wave.
X002 catches non-literal executable names in command position, things like ${A[0]}, namerefs, $(printf ...), or partial-quote reconstruction like c"u"rl. The tokenizer already knows how each word was resolved; it just needs to emit that metadata.
X005 catches install scriptlets that write to ~/.bashrc, ~/.zshrc, or fish configs, a pattern seen in the Russian spam campaign and never legitimate.

Edit: per Lone_Wolf's comment, any edits to ~/ are to be flagged.

X007 is the cluster rule: if two or more crossfire techniques appear in the same diff, it fires at CRITICAL severity because co-occurrence is deliberate evasion rather than coding style.
X008 catches BiDi control characters and homoglyph lookalikes in identifiers or URLs, which have no legitimate use in build scripts and map to the TrojanSource attack class. These five are cheap to implement, high-impact, and cover the known bypasses and attack waves.

Then, the ones that carry a risk of false positives: X003, X004 and X006.

X003 catches CLI argument obfuscation: character deletion like --upload-f, option stuffing like bash -lc, separator manipulation, and IP address encoding like 0177.0.0.0x1. This requires a per-tool regex library and carries medium false-positive risk because some variants are legitimate.

X004 catches anti-analysis patterns like TERM=dumb, set +x, and exec 2>/dev/null in build or install contexts; while common in malware, /dev/null redirection is also routine in benign builds, so this needs careful scoping to only fire near other suspicious activity.

X006 catches source URL drift, source= or patches= entries pointing to unexpected domains, URL shorteners, raw IPs, or GitHub repos whose owners do not match the package's stated upstream, which is the CHAOS RAT pattern, but it requires a domain-reputation baseline or owner-matching heuristic that may be too brittle for AUR's decentralized nature. Maybe this could be mitigated by the local baseline/seed that is currently used for novelty, if a source= domain has never appeared in the seed corpus, flag it as drift.

Edit:

Forgot to say, feedback is welcome, and rule suggestions are appreciated!

Last edited by aegis_eclipse (2026-08-12 21:09:22)

Lone_Wolf · 2026-08-12 09:22:01

X005 catches install scriptlets that write to ~/.bashrc, ~/.zshrc, or fish configs, a pattern seen in the Russian spam campaign and never legitimate.

Anything that's written to ~ folders in install scriptlets is a red flag to me.

aegis_eclipse · 2026-08-12 21:11:20

Lone_Wolf wrote:

Anything that's written to ~ folders in install scriptlets is a red flag to me.

Willco, updated the previous message. Ty!

Now, v0.13.0 is out, with the aforementioned python API, and a LOT of hardening.

TL;DR

Nineteen commits since v0.12.1 give TrustSight a supported programmatic interface, put the CLI and that interface on one evaluation layer, bound every hostile input the differ, tokenizer and regex engine can be handed, pin CI actions to immutable SHAs, harden seed archive extraction, and reorganise the rules reference into one page per rule category behind a new RuleCategory taxonomy that the doc gate enforces.

As always, full release body is here: https://github.com/emiliano-go/trustsig … ag/v0.13.0

Lone_Wolf · 2026-08-13 08:31:58

The checksum of the source in https://github.com/emiliano-go/trustsig … r/PKGBUILD is (again) not the same as that of the downloaded tarball.

It appears github CI/CD makes messing up checksums easy. One workaround is to use git to pin the download to a specific commit.

source=("$pkgname-$pkgver.tar.gz::git+$url.git#commit=hash-of-commit")

Running updpkgsums or makepkg -g on the pkgbuild will calculate a checksum for the download and put it in the PKGBUILD .

aegis_eclipse · 2026-08-13 14:24:10

Thanks!

The recorded hash is v0.13.0's, and v0.13.1's tarball is actually 6c19cea4b1a37eaed1d50deb4ee8551535dac084d6352f19242ce23593f7bbbe if you need to build it today.

The cause was our release process rather than GitHub regenerating the archive: the checksum was written by a commit after the tag, and for v0.13.1 that commit never landed. From v0.13.2 and forwards the source is a deterministic tarball built in-repo and attached to the release, so the checksum is known before the tag and ships with the version bump, with no post-tag step left to fail.

Arch Linux

#51 2026-08-07 15:17:54

Re: TrustSight: automated AUR PKGBUILD review, seeking technical criticism

#52 2026-08-08 02:17:35

Re: TrustSight: automated AUR PKGBUILD review, seeking technical criticism

#53 2026-08-09 03:06:32

Re: TrustSight: automated AUR PKGBUILD review, seeking technical criticism

#54 2026-08-09 04:32:54

Re: TrustSight: automated AUR PKGBUILD review, seeking technical criticism

#55 2026-08-09 04:48:52

Re: TrustSight: automated AUR PKGBUILD review, seeking technical criticism

#56 2026-08-09 05:51:22

Re: TrustSight: automated AUR PKGBUILD review, seeking technical criticism

#57 2026-08-11 02:48:18

Re: TrustSight: automated AUR PKGBUILD review, seeking technical criticism

#58 2026-08-11 10:15:04

Re: TrustSight: automated AUR PKGBUILD review, seeking technical criticism

#59 2026-08-11 12:57:45

Re: TrustSight: automated AUR PKGBUILD review, seeking technical criticism

#60 2026-08-11 15:51:57

Re: TrustSight: automated AUR PKGBUILD review, seeking technical criticism

#61 2026-08-12 03:15:39

Re: TrustSight: automated AUR PKGBUILD review, seeking technical criticism

#62 2026-08-12 09:22:01

Re: TrustSight: automated AUR PKGBUILD review, seeking technical criticism

#63 2026-08-12 21:11:20

Re: TrustSight: automated AUR PKGBUILD review, seeking technical criticism

#64 2026-08-13 08:31:58

Re: TrustSight: automated AUR PKGBUILD review, seeking technical criticism

#65 2026-08-13 14:24:10

Re: TrustSight: automated AUR PKGBUILD review, seeking technical criticism

Board footer