Recent searches
Search options
The least surprising thing about the xz vulnerability is that it happened to a widely used project after a maintainer hand-off. We've seen exactly the same thing repeatedly in npm, pypi, browser extensions, and other code marketplaces.
Humans don't last forever. Hand-off is inevitable. And I've long held that because that is true, the size of the group of maintainers is an important security characteristic.
Small projects create big risks.
Sustainability is a security concern.
@gordonmessmer so, like, we agree about the risk you're identifying, but it's kind of ironic to put it like that because the apparent sockpuppets who kinda bullied the original maintainer into doing the hand-off also advanced arguments that it's better for the project to have a larger maintainer team...
@gordonmessmer the thing to really look for in our view is a governance model that involves a small number of people (a huge group is impossible to vet properly!), who know each other well and are aligned on things that go beyond the project itself
@gordonmessmer small, but more than one.
@irenes That makes sense. The thing that seems important to me is that the team is sustainable. And I suspect that one of the important characteristics is diversity, in the sense that the objective is to avoid all of the maintainers (or governance) from retiring at once.
@gordonmessmer that sounds quite likely, as well
@gordonmessmer Maintainer hand-off shouldn't be a thing. A new wannabe maintainer should just create a fork and distributions can choose who they trust. Also changes from the fork can be merged back if they are good. Handing the maintainer permissions to someone new also hands them the complete distribution chain, the trust, the current network. That's too much, especially if nobody even saw the new guys face, just a username, email address...
@gordonmessmer We shouldn't be treating hobby projects as professional service providers. Again and again we have small projects with single maintainers used in critical context all over the world. We should normalize forking instead of change of maintainer. Your critical infrastructure wants to use my hobby project? Cool, fork it then and do all your critical audits on it, then I may (or may not) pull those commits into my hobby project. Or don't depend on my hobby project. That's open-source.
@gordonmessmer There is way too much expectation of ongoing "maintenance" of things that are (or should be) stick-a-fork-in-it *done*.