indirect
commented
2 years ago This is not an RFC, and so it is inappropriate to post here.
Leaving the ecosystem insecure by default is not a viable strategy at this time. If you want to publish gems without using the RubyGems.org MFA requirement, we would recommend using GitHub's package hosting for gems, or setting up a Gemstash of your own that does not require MFA.
Here I will try to make some comments from "the other side" of the argument, that is specifically criticism in regards to reducing or removing functionality from long-term devs in the rubygems ecosystem.
Others could comment on this too, so I would like to ask to keep this issue here open for some time, a few months perhaps, for others to chime in.
In particular https://github.com/rubygems/rfcs/blob/master/text/0007-mfa-rollout.md specifies the phases, and phase 4 is the one that I find most troubling by far.
To avoid people having to jump away from here, let me copy/paste the phase 4 plan:
"Once the rollout of the top 100 most downloaded gems is successfully rolled out, a similar rollout will be done for more gems. The details of this phase will be fleshed out in another RFC."
So, to word this from the other side, it means that long-term devs are now required for mandatory MFA/2FA. If they don't do this, they can not modify their gem anymore. I consider this equivalent to an account attack by the rubygems team, because you deprive of devs the ability to modify their own gems, e. g. if someone wrote the code, you now deny them the ability to modify it anymore - or, more accurately, to push any new updates to this to their own repository. Thus you attempt to force-lock them into MFA. This is unfair, because YOU are not the ones who maintain the code - you actually ADD to the burden of OTHERS who maintain the code. If you guys were to lock them out but at the same time offer to maintain the code that you just removed from them, then this would be less of an issue - it would merely be a hostile account take over. But it is not even that; it is just a lock out.
For those who can use MFA or have no problem with it, this is no issue. For those who, for whatever the reason, don't want to or can not, you actually forbid them from using rubygems.org further IF they want to publish code still. This was what shocked me the most. I recall having used rubyforge and I recall having used rubygems for many, many years before without these issues; suddenly some new accounts come up from nowhere (WHO ARE THESE GUYS?) and the policy is magically changed. Why the sudden policy change? Why such a ruthless policy change that steals gems from accounts of long-term ruby devs? And why is this tied to number of downloads? You actually penalise (!) those who have a certain number of downloads. This is really weird.
Even more interestingly, I can simply remove the old code on any of my own gems, and publish completely new code, under the same name. Is that then still considered the very same gem that has to be MFA protected? I mean, what is the logic behind this, then? Evidently the assumption is that "if the gem name is the same, the underlying code must be the same", but this depends COMPLETELY on the dev who controls the gem. So the assumption by the rubygems.org folks is really weird here. If the code is totally different, it is a different project too, yes? Actually it would be the SAME problem you would potentially WANT to solve by "avoiding account take-over" - but how can you ensure that the dev who maintains the code, isn't doing this exactly? Even without malicious intent? You can not ensure this either. You are basing it on an ASSUMPTION that this is never done by anyone malicious or due to other reasons. What about devs who have not been malicious? What about devs who have not had an account stolen? Why are these suddenly punished and penalised?
If you look at this:
https://github.com/rubygems/rfcs/blob/master/text/0007-mfa-rollout.md
You actually see the attempted strategy revealed:
"The positive of having MFA for all accounts is that we’re setting a higher bar of security if users want to join/stay on the platform."
(Which, by the way, is an ASSUMPTION you do, as my example of exchanging the code shows. YOU CAN NOT ENSURE THIS. YOU ASSUME IT IS THE CASE.)
Meaning this is an invasive policy change. Aka: "if users want to stay on the platform". In other words it is admitted that if they don't comply, they are being removed from rubygems.org and factually perma-banned as-is (since they can not modify the gem anymore). Now, before mandaty MFC comes I'll remove my rubygems.org account anyway, so the outcome is the same - but I feel as if this is a very unjust treatment coming from rubygems.org suddenly against all ruby devs. Why that sudden hostile policy? Why does it so conveniently and suspiciously overlap with github? They plan the same for 2023. That they need +1 year kind of shows how much opposition they expect. Even Google gmail still does not require mandatory M2A on every account. I can still access gmail fine (I stopped using it for other reasons, though - I am heavily against this global mandatory tracking trend or cohort sniffing via FLOC).
Unfortunately the ruby tracker already went that way and perma-banned me:
https://bugs.ruby-lang.org/issues/18800
Daniel pointed out this issue. Hiroshi said that this was done for another reason, e. g. spam. This is more understandable, but still annoying and unfair. However had, being perma-banned from the ruby bugtracker is still different to being perma-banned on rubygems.org. Even on github, by the way, I understood that you lose only the ability to PUBLISH code in 2023, so you could still use an account for issue requests and what not. But it's really weird how there is a strange, very suspicious move to "you can only write working code if you can be MFA identified". This is weird. At which point did computer systems become dependent on MFA?
Anyway. My hope is that those who are currently hijacking the ruby ecosystem reconsider their wicked plans. There are a MILLION ideas how to work around this to some extent, e. g. encourage people to use MFA without banning them, make "gem" itself and bundler work in that way (e. g. include only projects in your download-chain that are MFA guaranteed), use visual cues, use notifications and what not when accounts change (or code changes), add simple and easy reviews, add badges to encourage reviews of code, and so on and so forth. All of this could be done or intensified before the ""if users want to stay on the platform they now must use mandatory MFA". And while we are on the subject: add a disclaimer to rubygems.org that MFA becomes mandatory AT REGISTRATION, rather than ad-hoc change policies in the middle of nowhere.
My hope is that eventually these MFA proponents stop being so tyrannical and stop crippling the ecosystem from their selfish point of view. If a user wants to have only MFA gems, then you can solve this via the command itself:
or via bundler + Gemfile to specify this too. Problem solved.