Hall of Fame -- Real-world impact of using aurscan in the wild

[HaleTom]

I'm slowly working through my backlog of my held-back AUR updates, and aurscan has highlighted some good results!

I've passed them to the PKGBUILD maintainers:

• oh-my-pi
• openchamber
• tmuxai-bin
• factory-cli-bin
• python-llm

What do you think about keeping this issue open as a "Hall of Fame" for the AUR improvements that have come about due to this tool?

[manticore-projects]

  scanning oh-my-pi (6 files) ...

[  OK  ] oh-my-pi  confidence 78%
         This PKGBUILD builds oh-my-pi from a tagged upstream git source using bun and rustup, which is normal for this type of project. The 'bun install --frozen-lockfile' invocation is a legitimate build step for a JavaScript/TypeScript project, not an unrelated package manager call, and there are no signs of credential theft, remote payload execution, or suspicious exfiltration.
         [warning] PKGBUILD: The primary git source uses SKIP for its checksum, which is normal for VCS sources in AUR (git clone is pinned by tag, not hash). However, tag-based pinning is weaker than commit-hash pinning since tags can be force-pushed. The two patch files do have proper checksums.
             > sha256sums=('SKIP'
         [info] PKGBUILD: This is a legitimate build step for the oh-my-pi TypeScript project itself (not an unrelated package install). The --frozen-lockfile flag prevents unexpected dependency changes. This is standard practice for JS/TS projects and is not the Atomic Arch campaign pattern (which installs unrelated npm/bun packages in post-install hooks).
             > bun install --frozen-lockfile
         [info] PKGBUILD: The build conditionally installs a Rust toolchain via rustup at build time, which is somewhat unusual but not malicious — it installs the toolchain specified in the upstream project's rust-toolchain.toml.
             > rustup toolchain install "${_toolchain}"
         [info] tree-sitter-haskell-new-repo.patch: Redirects a Cargo dependency from crates.io to a GitHub git source with a specific commit hash. The target repo (tree-sitter-grammars org) is a legitimate maintained fork. The commit is pinned by hash, reducing risk.
             > source = "git+https://github.com/tree-sitter-grammars/tree-sitter-haskell?branch=master#98aedbd
         [info] PKGBUILD: Executes the freshly-built binary during package() to generate shell completions. This runs in fakeroot context and only writes into pkgdir/srcdir, which is acceptable behavior.
             > _install_completions "${pkgdir}/usr/bin/omp"
         ↳ tokens: 5,457 in / 698 out · $0.0268

scanner usage: 1 call(s) · tokens: 5,457 in / 698 out · $0.0268
All scanned packages look clean.  (heuristic scan — not a guarantee)

Please help me out, what is the problem here?

[manticore-projects]

Eventually I will scan all AUR packages at my own cost although I wonder if the yields in a tax reduction.

[HaleTom]

Please help me out, what is the problem here?

Please see #54.

[manticore-projects]

==> Making package: minify 2.24.14-1 (Sun 26 Jul 2026 06:54:29 AM +07)
==> Retrieving sources...
  -> Found v2.24.14.tar.gz
==> WARNING: Skipping verification of source file PGP signatures.
==> Validating source files with sha256sums...
    v2.24.14.tar.gz ... Passed
  scanning minify (2 files) ...
SUSPICIOUS minify (confidence 55%)
  The package() function sources a bash_completion file from the build directory using 'source cmd/minify/bash_completion', which executes the contents of that file in the current shell context during packaging. While likely benign, sourcing arbitrary file content from an untrusted tarball during the package step is unusual and potentially dangerous if the upstream bash_completion file contains malicious shell code.
  [warning] PKGBUILD: The 'source' command inside package() executes the bash_completion script in the current shell. This is unnecessary for installation (the file is already copied via install -Dm644) and means any malicious code embedded in that file by upstream would execute during packaging. A legitimate maintainer would never need to source a completion file during packaging.
!! Build blocked: 1 package(s) flagged SUSPICIOUS.

After reporting this to the maintainer, he fixed it nicely and improved the PKGBUILD.

[manticore-projects]

scanning openconnect-sso (3 files) ...
SUSPICIOUS openconnect-sso (confidence 72%)
  The source tarball is fetched from a personal fork (PrestonHager/openconnect-sso) rather than the canonical upstream (vlaci/openconnect-sso) stated in the url= field, which is a significant provenance mismatch and matches the pattern of the July 2025 CHAOS RAT campaign where legitimate-looking packages substituted a personal/unrelated repo as the source.
  [critical] PKGBUILD: The source tarball is downloaded from 'PrestonHager/openconnect-sso', a personal fork, while the package's own url= field points to 'vlaci/openconnect-sso' (the real upstream). This mismatch — canonical URL vs. actual download location — is the hallmark of supply-chain substitution attacks. A legitimate maintainer would fetch from the canonical upstream, not a third-party fork.
  [critical] .SRCINFO: Confirms the source discrepancy: the .SRCINFO also records the PrestonHager fork as the download source, meaning this is not a copy-paste error but an intentional substitution of a non-canonical source.
  [warning] .SRCINFO: sudo is listed as a runtime dependency. While openconnect-sso does use sudo to invoke openconnect with elevated privileges (legitimate for this tool), it is worth confirming the fetched tarball does not misuse sudo in install scripts or post-install hooks. On its own this is expected for this package, but combined with the source mismatch it warrants scrutiny.
!! Build blocked: 1 package(s) flagged SUSPICIOUS.