This is great news! I like how the article cites evidence that MFA is disproportionately effective against account takeover.<p>If the rubygems devs are looking for other highly effective wins against supply chain attacks: I think the next thing is deeper support for lockfiles. Although Ruby has Gemfile.lock, it's not a true lockfile in the same way that package managers in the javascript/go/python ecosystems are. Specifically, locking versions is optional, there's no locking by hash (Github issue: <a href="https://github.com/rubygems/rubygems/issues/3379" rel="nofollow">https://github.com/rubygems/rubygems/issues/3379</a>), and there's no capability to lock local or source-only dependencies by hash. By comparison: go modules, pipenv, npm, yarn, nuget, composer, and gradle already support locking by hash.
I applaud the move in the right direction, but please add support for webauthn. OTPs are really inconvenient in comparison.<p>It looks like maybe it's been in flight for a while? <a href="https://github.com/rubygems/rubygems.org/pull/2108" rel="nofollow">https://github.com/rubygems/rubygems.org/pull/2108</a>
I really wish more package managers added support for OIDC based authentication+authorization for package publishing. PyPi has an ongoing PR for this: <a href="https://github.com/pypa/warehouse/issues/10970" rel="nofollow">https://github.com/pypa/warehouse/issues/10970</a> with some really great UX. You specify a repository name on GitHub and GitHub actions there get publishing rights automatically.<p>While 2FA is good, having a purpose limited JIT token for publishing packages is what will actually reduce risk. Otherwise, as it stands - PATs leaked from one project can be used across any of your other packages on all package managers.
As part of a team of maintainers of a popular (declining) gem, shame they don't make a mention of the extremely valid "gem is owned by a team, and anyone may push" model. I regret that the MFA token for many gems such as this may end-up in 1Password or similar, shared, along side the other credentials, rather than on a separate device or similar.
Throwing the black hat on for a moment surely I would just move towards the subdependencies of these popular gems (which realistically is where you would be targeting anyways I imagine) and can fairly reliably expect that my malicious changes get picked up upstream in due course.<p>Am I missing something here?
Anyone know what happens to the people who won't activate MFA within the time-period? I'm guessing they'll be unable to publish, but still be able to login to their account to setup MFA, even after MFA started to become mandatory?
Does MFA exists to force people to have/carry all the time smart phones or there's a way to use it without a phone? I mean in practice for repositories like npm or rubygems?
How about cryptographically signed packages as the next step? It boggles my mind that most popular package managers like npm, pip and cargo don't have verification of package authenticity before installing built in.