rfcs

Do the former maintainers have full commit access? Remember, this is what was taken in the middle of a discussion about governance. https://github.com/rubygems/rfcs/pull/61

It's not just one person. Between the initial removal of access, then giving it back after explaining it was a mistake; the people involved started a conversation about governance to clarify/fix things. https://github.com/rubygems/rfcs/pull/61 The conversation terminated because the majority of those people then had their access revoked again. When weighing the facts here; which group or claimant has the most evidence for their claims? The technical folks with lots of commits over many years, or the treasurer of an organisation who says the impetus for this was a "funding deadline" so all access had to be seized?

There is some more context on a post[1] in /r/ruby, including the fact that the maintainers and others had been working on a proposal[2] for a formalized organizational governance structure as recently as yesterday. The latter also adds some context into Mike McQuaid's involvement: the proposal was influenced by the structure put in place by the Homebrew project. [1]: https://old.reddit.com/r/ruby/comments/1nkzszc/ruby_centrals... [2]: https://github.com/rubygems/rfcs/pull/61

> Perhaps accelerated by the vulnerability 3 months ago FWIW this has been in the works since January: https://github.com/rubygems/rfcs/pull/36

I can give a limited answer based on my own day-to-day work. I work in Ruby Dependency Security, which is the team who are most involved in helping out with rubygems.org and RubyGems work. Our biggest effort lately has been about rolling out MFA requirements for owners of top-most-downloaded gems. What I'd like to do afterwards is focus on gem signing using sigstore, which would make it a "one click" experience for authors. We did some work on it earlier this year[0] but chose to focus on MFA as our first big push. We also aim to devote a substantial fraction of our time to chopping wood and carrying water: looking at honeybadger exception reports, etc. In terms of the long run there's a whole bunch that can be done to continuously harden every aspect of the Ruby supply chain. One thing we've been involved in founding is the OpenSSF Secur

That’s correct. If you’re a maintainer of a very popular gem, as of 15th August you’ll no longer be able to e.g. `gem push` if you haven’t enabled MFA on your RubyGems account. You will of course still be able to log in and enable it. More details in the RFC: https://github.com/rubygems/rfcs/blob/master/text/0007-mfa-r...

> < 10% had useful 2FA enabled. I expect this to change. NPM will roll out mandatory MFA for the most-downloaded packages[0] (RubyGems as well[1]). I expect this will rise to a 100% requirement at some point because Github's decision to require MFA by the end of 2023 will massively raise the waterline of folks who have the capability to MFA and experience with MFA. [0] https://github.blog/2021-11-15-githubs-commitment-to-npm-eco... [1] https://github.com/rubygems/rfcs/issues/35

There's a proposal (disclosure: I co-authored it) to introduce a new signing mechanism based on sigstore. By separating the signing identity from the rubygems.org identity, it means that compromising the signing identity doesn't enable you to upload and compromising the rubygems.org identity doesn't enable you to sign. You'd need to compromise both. https://github.com/rubygems/rfcs/pull/37

So adding or removing a maintainer is an event that causes everyone’s package installs to break? In a large enough project that would mean nearly every dependency change would trigger this condition. > Generally I wouldn’t be too happy using a dependency where there are lots of users with access to create official releases. I’m curious, do you use any open source software? Most larger projects have a number of maintainers with release rights. I want to clarify that I’m not against package signing. For example, I think this proposal is well-thought-out and would be a positive change. The key reason this is better IMO is that it introduces a centralized trust mechanism and a certificate transparency log: https://github.com/rubygems/rfcs/pull/37

Related: there is a scoped gems proposal, that would allow to explicitly specify the author, e.g. @tenderlove/nokogiri https://github.com/rubygems/rfcs/pull/40

The RFC trying to introduce sigstore for RubyGems is an interesting look at this in practice: https://github.com/rubygems/rfcs/pull/37

In fairness, Sigstore is a pretty new technology. Existing package managers haven't integrated it yet, though are working towards it. For example, I've been working with colleagues on proposing a design for RubyGems[0]. And as far as I know we're about as far ahead as anyone has gotten. There's an informal group of software repo folks meeting with some assistance from the OpenSSF. WAPM folks, please feel free to hit me up at my work email (in profile). [0] https://github.com/rubygems/rfcs/pull/37