It makes little sense to use web-of-trust to verify the identity of the committer and then accept whatever software they publish. GPG's web of trust makes sense because it's meant for communication, where "being from who it says" is the only form of trust that is wanted.
It makes a lot more sense to use web-of-trust to verify that releases are not malicious directly. This is what crev [1] does and I can't wait to see adoption in more package ecosystems.
Trusting yourcolleague42 who trusts that 'left-pad was made by steve' doesn't prevent steve from publishing a malicious release, even if GitHub can check steve's signatures on his releases and commits.
Trusting yourcolleague42 who trusts that 'left-pad 1.2.3 with hash abc1234fde is safe' removes all of the risk.
I agree with you that we need something different than trusting an entire user and everything that comes from them, and something more like trusting a specific releases.
I think crev is a step in the right direction, but there are some things I don't think they get right which makes it hard to actually be useful in practice. For example, there is no specifics regarding crew understanding files themselves, no easy way of aggregating data, the solution not being scalable for projects using lots of dependencies and some other points.
But rather than just complaining about crev, I've started to build an alternative, that addresses those issues. It's not really ready for showtime yet (it'll be a Show HN once it is :) ), but if this is something people want to help out and collaborate on, I'm happy to share the progress in private for now. If anyone is interested, reach out to me at [email protected] and we can talk more! I'm also currently looking for another full-time/part-time developer to work on the project together with me. Only requirement is some previous experience with Rust, Clojure and ClojureScript, and a burning desire of wanting to fix security in the open source packaging community.
It makes a lot more sense to use web-of-trust to verify that releases are not malicious directly. This is what crev [1] does and I can't wait to see adoption in more package ecosystems.
Trusting yourcolleague42 who trusts that 'left-pad was made by steve' doesn't prevent steve from publishing a malicious release, even if GitHub can check steve's signatures on his releases and commits.
Trusting yourcolleague42 who trusts that 'left-pad 1.2.3 with hash abc1234fde is safe' removes all of the risk.
[1]: https://github.com/crev-dev