On 5/27/26 8:09 PM, kpcyrd wrote:
I think a reputation system for PKGBUILDs would be highly effective.
Currently only known-bad findings are reported, but known-good findings
are not recorded anywhere.
You could define a set of individuals you consider trustworthy and
capable reviewers, then only accept PKGBUILDs onto your system that have
positive reviews from N of those people.
This kind of system already exists in the Rust ecosystem:
https://github.com/crev-dev/cargo-crev
There's also a toy project that parses the install hook into an AST and
flags things you should probably look into, but it's fairly noisy
because it flags every unrecognized command as suspicious:
https://github.com/kpcyrd/smelly-hooks
It would've flagged and pointed out the npm install in browsh-bin, yet
you should probably not rely on this for security since "we didn't
forget any shell scripting edge-case" is likely not something you want
to gamble your computer integrity on.
Those are good ideas,
I do respect your position on providing full-name and location. I
understand that can be an issue, not because the person has anything to
hide, but because that information may be used by others or authorities
for improper purposes.
I like the reputation idea and I also like some type of broader
peer-review before push privileges are earned. The catch is the
mechanism has to be responsive enough not to impede a legitimate
maintainer from picking up packages while still providing the
opportunity for existing maintainers (or mods) to raise concerns about a
particular application or adoption.
One good thought experiment would be to take the two cases on this
list from today and yesterday and game-out what type protection would
have helped in those cases?
Maybe some type of logic that would hold commits until reviewed for
packages that have changed maintainership or the like. I don't know how
that would fit in the system, but that would at least give a change for
a review of new commits by new maintainers until a community (or
moderator) "sign-off" can occur.
That would also help take some of the work off the moderators if it
could be implemented. Have the community triage/scan commits for new
maintainers for X commits and either flag for moderator review or
sign-off if all clear.
Thank you for your feedback!
--
David C. Rankin, J.D.,P.E.
