On 6/13/26 1:13 PM, Claudia Pellegrino wrote:
Hi David,
In the AUR case, any source scanning would have to be added as part of
the makepkg process, and compute required would just be part of the
build process if something like that is even doable.
Fyi, there’s some experimental work in progress (private, not endorsed
by Arch developers) to add pluggable, user-controlled upstream source
auditing to makepkg. [1] [2]
Regards
Claudia
[1]: https://gitlab.archlinux.org/auerhuhn/libmakepkg-srcaudit/-/blob/
main/README.md
[2]: https://gitlab.archlinux.org/auerhuhn/libmakepkg-hexora/-/blob/
main/README.md
Thank You Claudia!,
Are there other drop-in scanners planned in addition to hexora? The
Readme says it scans upstream python, but what about the nodejs/npm files?
While the PKGBUILD changes can indicate the presence of a
post-install install/bun file, is there a need to do similar scanning on
what npm pulls down in the legitimate case? Seems both npm and pypi are
frequent-flyers in the upstream package poisoning category. If hexora
looks at upstream python, is it worth doing something similar for npm?
Granted, with a FORTRAN, C, C++ background, I don't understand the
internals of the npm world, but I do see npm at the top of the
leader-board for supply-chain compromises. If the post-install
modifications pull in poisoned npm files, could a similar drop in there
catch it?
Side-track/Reason
My curiosity on that issue extends to the mongosh package I
co-maintain that currently relies heavily on upstream nodejs/npm and
pulls in some 14,000 javascript sources. That's just the way the package
works, assembling/borrowing bits of functionality from ~30 npm modules
rather than actually coding the shell itself.
While that package is legitimate, it would be comforting to have some
makepkg hook scan the myriad of js files it pulls in through npm
independent of the AUR attack issue. Currently, the files are
non-obfuscated/well-formatted, but there is no way to ensure one of them
wasn't an upstream target during the build process.
That's a separate issue, but it dovetails with the current libmakepkg
plug-in approach. (save the idea for later if nothing else)
Best of luck to you all. You are doing great!
--
David C. Rankin, J.D.,P.E.
