How about a split, so releases can be uploaded by API key, but only published by someone using MFA?

Why would a CI/CD need to permissions modify and commit code to a repo?

Say your CI pipeline runs automated tests, builds the gem and pushes to Rubygems, it needs permissions to push to Rubygems.

So if an attacker compromises the API key used by that pipeline, they get the rights to push to Rubygems.

Actually publishing new versions seems like something that happens infrequently enough that it would be fine to require a manual auth to complete it. Given the potential risks it seems prudent.

I'd expect that very much depends on the software in question. As one example that I'm aware of, gvisor from Google delivers nightly builds. So they're building and pushing every single day.

It'd depend on the individual software library and of course as a consumer of many libraries you generally will have limited or no visibility of the practices of all your dependencies.

I don't think nightly builds are the same thing as releases - you can have CI publish a build but to create a versioned public release it should require manual auth.

That's a view of course (although in the case of gVisor they don't actually do versioned build just nightlies) but here's a question.

As a consumer of software libraries, have you ever looked into the security practices of the library author before choosing whether to use it or not?

This is becoming increasingly impractical for certain ecosystems as packages depend on packages, which depend on packages, etc. It's less of a problem with the bundler ecosystem, where larger packages with relatively few dependencies is more standard, but in the JS world installing a package means that you're likely installing tens or hundreds of sub-dependencies.

I did review two small libs I was pulling that had very few users (and froze the version) But that's just the thing - I will never be in a position to do that for more than a few libs - that's why the best I can do is rely on source enforcing good practices and community audits.

Every single day doesn't sound too often to have someone press a physical button.

Absolutely agree. One-click deploys are nice, but in some circumstances not worth the cost. The manual component can also be polished to the point where it's not that arduous (think github login with 2FA and clicking the "merge" button).

The argument for automated releases is always that it is quite easy to do silly mistakes like forgetting a build step while doing manual releases. This also happened to high profile npm packages in the past and people complained that there was no automation.

I think they are suggesting a mostly automated build process and then a manual entering of a the second factor OTP at the deploy stage. The entering of the 2FA isn't something that will be hard to easy to mess up and you still receive the benefits of automated builds for the most part.

I doesn't seem hard to imagine a CI pipeline that sends an email/sms for validation and waits an affirmative answer before continuing. I have no idea how to receive texts on a server, but sending and receiving emails is super easy.

Yes, I agree, it's not only rubygems, npm had the same problem not so long ago and it is a general issue in all repos.

One thing that would be inconvenient but would protect against that would be to have the api work as usual, but need to use MFA and login to the website to approve a new release (and have information there listing the ip and time of upload). That would only make sense for heavily used gems like this one but it seems that it would stop most issues?

It would help for sure, I'd guess the problem would be , will the maintainers of all these libraries be happy with the overhead that this would introduce.

A less invasive control might be to notify all owners when a new version is pushed, so they would be aware of a risk, if they weren't expecting a new release. Not perfect, but something.