On 10/08/2026 20:24 UTC-3, JDR wrote: > Automated or crowdsourced scanning of PKGBUILDs will do nothing but give >users a false sense of security and delay releases. > It's not elitist to say that users should be able to read PKGBUILDs. It's >common sense. At most, I'd be partial to a low-effort > automated scan (keyword matching or regex matching, manual review if there's >a significant change in dependencies, etc) mostly > as a way of showing due diligence and limiting liability. ... I agree with the core concern. I've seen enough "security scanners" that output a green checkmark and call it a day, and I think that's worse than nothing. It trains users to stop thinking.I ended up building something for the opposite problem: I was reading every PKGBUILD diff across ~30 AUR packages, and most of them were trivial version bumps. I wanted a structured way to know which diffs actually needed my eyes first, not a replacement for reading them.
What emerged is a local, deterministic regex-based diff analyzer. No network calls to package-declared URLs. No execution. No AI. MIT licensed, no corporate backing, just raw open-source. It runs on your machine after the package is already published, and the default output is literally a list of line-numbered findings with "Review the diff before building" appended to every single result. Source: https://github.com/emiliano-go/trustsight Security model (what it promises and what it doesn't): https://trustsight.emiliano-go.com/security/ I don't think this should be a gate on the AUR, and I don't think it replaces reading PKGBUILDs. It's a triage step for people who were already going to read them, but have too many packages to open every diff blind. Essentially the "low-effort automated scan for due diligence" that I think you're describing as the acceptable ceiling. The AUR's governance problem - maintainer trust, adoption frequency, orphaned packages - is a separate issue that tooling can't fix. I discussed the tokenizer boundaries and the removal of the LLM layer in more detail on the forums, if anyone's curious: https://bbs.archlinux.org/viewtopic.php?id=314372 On Monday, August 10th, 2026 at 8:24 PM, Jonathan Rayne <[email protected]> wrote: > Automated or crowdsourced scanning of PKGBUILDs will do nothing but give > users a false sense of security and delay releases. It's not elitist to say > that users should be able to read PKGBUILDs. It's common sense. A bad > PKGBUILD could break your system even if there was no intentional foul play, > and reviewing them prior to building is best practice. At most, I'd be > partial to a low-effort automated scan (keyword matching or regex matching, > manual review if there's a significant change in dependencies, etc) mostly as > a way of showing due diligence and limiting liability. But using an AI tool > or forcing every PKGBUILD to go through a queue before being made available > isn't just overkill, it's a bad precedent in my opinion. Tightening controls > on new maintainers and changes to the frequency with which they can adopt and > update packages seems like the saner approach. > > -JDR > > On Mon, Aug 10, 2026 at 5:15 PM Maarten de Vries <[email protected]> > wrote: > > > On 8/10/26 22:33, Cynthia Rey wrote: > > > > > > But even if we put aside Socket, I found that Ralf's comment[1] on the > > > "Crowdsourcing security inspection" thread was quite enlightening; I > > > didn't fully agree with the viewpoint on the first read, but thinking > > > about it more made me realise that it's a very accurate statement. One > > > that I believe also applies here. > > > > > > On 10/08/2026 16:00, Ralf Mardorf wrote: > > >> so far, the AUR has worked very well based on the principle of "many > > >> eyes". What you're suggesting has been working exactly that way for a > > >> long time, just without nonsense like a score or gamification. > > >> > > >> The attacks are annoying, but they were detected immediately upon > > >> occurring. As far as detection goes, there’s absolutely no reason to > > >> change anything. > > > > > >> The real problem is the attacks themselves, not that they might go > > >> undetected. > > >> > > >> You’re trying to solve a problem that doesn’t need solving, since it’s > > >> been working reliably for a long time. > > > > > > ~Cynthia > > > > > > [1] > > > https://lists.archlinux.org/archives/list/[email protected]/message/6HCWXEEDOIINTN5VKNZ6M5G73QDNAFPV/ > > > > I would say the point is that the two recent malware campaigns mark the > > end of "has worked very well for a long time". > > > > It has worked very badly for a short time now, and it feels naive to > > assume that the problem will go away without changes to the AUR. > > > > It's nice that people help flag packages, but it's not a structured > > approach. There is still no official list of packages that were > > compromised. There's not even a pkgname+pkgver+pkgrel you *could* put on > > a list, because the commits have been completely deleted and now the > > pkgver+pkgrel can presumably be used again for legit non-infected bumps. > > > > We have no idea what the impact of the campaign actually was, no clue > > how many systems actually got infected, or with what (at least, I > > haven't seen anyone shed light on it). > > > > I don't know about Socket, so I don't have an opinion on them in > > specific. But some form of mandatory malware scanning *before* a > > PKGBUILD is made available to download seems like a very good idea to > > me. Whether it's with a crowd-sourced review queue, or an automated > > scanner, or both, or something else. > > > > -- Maarten
publickey - [email protected] - 0xF759D6D4.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
