Re multiple maintainers with release capabilities, each release could include a list of all authorised maintainers key, but only signed by one of them. Changing

Re multiple maintainers with release capabilities, each release could include a list of all authorised maintainers key, but only signed by one of them. Changing the list (or just additions as well as significant removals) would trigger a trust change in the client. Any maintainer can add/remove other maintainers (or maybe use a quorum if enough maintainers to make that workable). Generally I wouldn’t be too happy using a dependency where there are lots of users with access to create official releases. Re npm and transitive dependencies, this isn’t a code signing issue as much as it is a version pinning issue. Specifying latest as the version is a poor approach imo. Also the primary dependency should not be releasing a critical security fix as a breaking change. If it has to be a breaking change then there’s marginal additional effort to having to deal with the transitive dependency too given you’re already having to change things to support the primary dependency. I’m not saying TOFU signatures would be a silver bullet. They, in conjunction with other security measures, best practices, etc, would help a lot though.