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 > >
