Prevent deletion of ineligible gems with validations.

[martinemde]

No description provided.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.09%. Comparing base (61e5bc7) to head (4b13882).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #4631   +/-   ##
=======================================
  Coverage   97.09%   97.09%           
=======================================
  Files         392      392           
  Lines        8254     8270   +16     
=======================================
+ Hits         8014     8030   +16     
  Misses        240      240           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[simi]

Good to delete controller check now?

[rubyFeedback]

The primary problem I see here is that rubygems.org takes away control from gem authors, without rubygems.org itself providing (and maintaining) these gems on their own. So, one "workaround" for this, even though it is not a very good one, is account deletion; and then subsequent re-publishing of the code on e. g. github, gitlab or anywhere else where it may be hosted then.

Different gem authors handle their own gems differently, of course. Some never delete their old gems, such as hexapdf's author:

https://rubygems.org/gems/hexapdf/versions

Others sometimes delete old gems, for different reasons - see Andy's glimmer project:

https://rubygems.org/gems/glimmer/versions

From about 120 versions or so, Andy deleted only six releases.

And then others only want to maintain one version officially, which means older versions
get frequently removed. The latter was precisely my workflow before I abandoned
rubygems.org due to that new awkward change. It also visually annoys me when I have
old gems I can no longer remove; although, of course, the primary problem was that
rubygems.org would try to force gem authors to be associated with old code they
no longer wish to maintain.

I am not necessarily saying that rubygems.org has no valid opinion here, mind you. You
guys put the user in the center of this change, I assume. I can understand that. I also
understand the issue of left-pad and the disruption that ensued.

However had, what this change factually means is that control is shifted away from gem
authors towards rubygems.org (and, in general of any platform that does so), but then you
guys don't even offer YOURSELF to host these gems. You simply stole a gem author's ability
to have full control over his or her gems / code here. I find that simply inacceptable.

Correct me if I am wrong, but on other code hosting platforms such as Microsoft's github, we
can remove old code. Bundler also supports downloading from github directly, if I understood
it correctly - see guides such as this one here:

https://bundler.io/guides/git.html

(Technically we can say that all versions on github.com are always logged due to how git itself
works, but I believe people could, even if this is super-rare, remove all .git content too on
their OWN github repository, thus only having one version available in a repository. Only few
will do so, probably, but that basically means that people hosting their code at github.com
have more control than what rubygems.org now allows gem authors. Of course Microsoft
itself may also interfere sometimes, such as the xz utils backdoors, where even issue
discussions were taken down, at the least for some time, so I am not saying other code
hosting platforms are perfect either, mind you.)

The 30 days limitation is also an awkward limitation. What is the rationale for that? With
the new changes, for instance, Andy could not remove the other old gems he yanked
before. Why not? I don't get it. Why are his actions suddenly invalidated? Actually, IF
you guys follow your own policy consistently, YOU'D HAVE TO REVERT ALL YANKED
GEMS - so why aren't you doing so then? I find that inacceptable that you guys suddenly
interfere with gem authors like that. Also there wasn't any discussion about this - at
the least in ruby core, we have a discussion session, usually once per month, and
matz comments, thinks - and makes a decision. At rubygems.org, there is no real
discussion; with pull requests that's even worse, as not everyone even sees them, yet
alone sees there are discussions about it, before suddenly new restrictions come in
willy-nilly.

The best solution would have been to not handicap gem authors with such changes
in the first place, of course. Assuming this is the way how the new overlords who
control rubygems.org want to continue to run, I believe the second best option would
be to still allow gem authors full control OVER THEIR OWN CODE, but you can take
away these gems and host them on your own, while adding a disclaimer to each
gem taken away that way that YOU guys now maintain them, and the original gem
author should NOT be contacted by email, since they no longer have any control
over their own code. That way gem authors can still do what they want, and you guys
can maintain the gems that you took away from them - win-win scenario. I assume this
is also unlikely to happen, because you guys don't have the time and motivation to do
so, so you basically just leech off of gem authors here with that ad-hoc change - or
similar ad-hoc changes in the future. (Forking is fine, as I assume that almost every
gem hosted on rubygems.org has a permissive licence, so this is not the issue at all.
The issue is WHO controls a gem - the gem author, or the rubygems.org team.
Personally I think the gem author controls their own gem and you guys should
not steal control away from gems like that. Note that I refer her to non-malicious
gem authors; I have no problem when gems are removed from malicious accounts,
of course, but pray tell and explain to me how this is the case with that random
"after 30 days, you lose the ability to remove your own code from rubygems.org"
change. I fail to see the logic behind that - and, again, if you want to protect
the USERS, then YOU should host the gem as-is once it was deleted by the gem
author! That way you can still prevent a left-pad scenario, but the further
maintenance burden is on rubygems.org, rather than the original gem author,
which is currently not the case with that policy change, since you try to force
gem authors to be affiliated with old, potentially buggy and outdated code
they wanted to remove.)

Naturally I understand that the policy is aimed towards giving gem USERS more
control. I always said that I am fine with that, but not when this comes to the
disadvantage of gem authors. I hugely dislike this new policy and I'd love if
rubygems.org would become less opinionated in general - you seem to favour
primarily the gem USERS while disregarding the gem AUTHORS nowadays.

These strange policy changes started to happen in the last few years; in the
years before they did not exist, so something strange changed here. I also
disagree that every ecosystem needs to copy/paste from one another
suddenly.

Another problem I have is that these changes seem to come from (semi?)
random people, some of whom I never saw in the ruby ecosystem, and I also
suspect that some of those do not maintain gems on their own, which makes this
even stranger. It would be better if people making these strange decisions
at the least have maintained gems on their own for a few years, and also
ideally several gems with a +100.000 download count. I think that group would
then understand concerns of gem authors a little bit better, in particular after
they received emails (or complaints) about problems pertaining to these gems.
You also should consider that maintaining open source code does not come
for free by gem authors either - they are usually not paid for that gem, so
by adding the barrier here, you also increase the cost of maintaining such
gems. That was also one reason why I decided to abandon rubygems.org -
I honestly do not have the time or inclination to keep up with random policy
changes that handicap and interfere with my workflow now. I remember some
guy in the python ecosystem who cited a similar problem when he stopped
publishing on pypi after 2FA became mandatory. I can absolutely relate to
that, too - it takes away a LOT of my time (which, to be fair, was also my
fault as I hosted too many gems in the past, so if I'd ever return to rubygems.org
one day, I'd also cut down on the gems, e. g. only maintain those gems that
are sufficiently useful and also used by other people; although right now I am
enjoying my "time off", so who knows whether I'll reconsider rubygems.org
again in the future. It may happen, but time constraints are also one reason
why it may not happen - as I keep on getting older and older, I need to look
where I invest my time, as that is a very finite resource).

By the way, one thing I also realised ... if people host on github, and bundler
allows installation via github, then you guys actually can not control the
code on github, right? So, if you can not do so, it creates an interesting
problem, as you would arbitrarily limited gem authors via rubygems.org,
whereas via github people can bypass such restrictions. So that makes
this restriction really strange - you can control rubygems.org of course,
but not github (if bundler supports that). I refer here to non-malicious
use, mind you. But, even left-pad was not really malicious - it was just
stupid, and indicative of javascript being such a poorly "designed" programming
language.

Irrespective of the above, differences of opinion, I believe we should propose
to matz and the ruby core team a proper "ownership" model. I do not mean
"you can not change a class or module anymore", but some additional meta-data
information of classes and modules. That way, for instance, we could have
something like this:

module Configuration
end

And this, in theory, can exist multiple times. So, one is created by user Joe, the
other is created by user Fred. We then have meta-data information available
such as:

Configuration.owner? # just as a demo-example

And it would return :Joe or :Fred depending on who created the module initially.
This could also be described in a simple way, such as via .gemspec file ideally.
Or a slightly extended .gemspec file.

People can still merge such modules together, such as "module Configuration",
if they want to - this is fine, but we could also allow more control for people, to create
same-named module or classes (before it is merged); and resolution of these conflicts
can be made possible via gem itself, from the commandline too. (The exact details of
this have to be specified down, of course, but gem itself could have that functionality,
and rubygems.org could also show multiple projects with the same name once that
is supported. I believe github.com makes this possible too, e. g. people can occupy
the same "namespace", whereas on rubygems.org, we can only have e. g. one "colors"
project, thus the namespace is reserved - and occupied. I think this is not a great
situation.)

Unfortunately ruby core requires authenticator apps these days to make suggestions,
but perhaps someone else can think about how to have a proper "ownership" model
that does not destroy ruby's ability to change classes or modules dynamically, but instead
can be used as a means of specifying "ownership" of code initially - a bit like refinements
work, by the way.

(Ruby core can also have such ownership, e. g. the core stdlib and bundled gems
ruby core distributes, can be marked as being owned by :core - or something like
that. And if overwritten or so, we can include that information as well, so that
all classes and modules have an OPTIONAL entry of meta-data that keeps track
of all such changes; hence why I think this is partially tied to refinements. This may be
a bit difficult to understand at first, but I believe in the long run we need more control
here, so that we can resolve problems of same-named or, in general, conflicts and
ownership control.)

Last but not least, I also think ruby core should help oversee rubygems.org in "spirit".
I am not referring to infrastructure-related aspects - that part is fine, to ensure
rubygems.org itself functions. But I mean ad-hoc changes that place limitations on
gem authors suddenly - it feels very un-ruby to me right now (also including the
"you need an authenticator app to make suggestions to ruby core these days" -
I understand Hiroshi's comment about preventing spam, but even then I still
do not believe spam should restrict communication; oldschool emails did not
have that restriction either, and we survived that era just fine). I don't have a good
suggestion in this regard, also because syncing ruby core with rubygems.org
means more time investment, so I understand that this isn't as trivial, but to me
it feels awkward if rubygems.org adds stricter and stricter controls and restrictions
when ruby itself is dynamic and fairly free (which is also a reason that, while I think
ruby needs an ownership model, I am NOT suggesting that people should ever
lose the ability to change "namespaces"; I am here referring to ADDITIONAL
information; and then, once that is existing, we can think of SOME projects who
want more fine-tuned control, to get that fine-tuned control.)

[martinemde]

I believe you that this has inconvenienced you. Even though you disregard me as if I'm some "random" person, I hear where you're coming from and respect your input. We plan to implement ways for authors to disavow ownership of gem versions or mark them deprecated, partly because of your feedback.

The fact is that we're dealing with other issues and we're making these policies to address larger risks. You decided to delete your account within 24 hours of the policy being enacted and ultimately decided to attack many of the people involved. I would have appreciated a more measured approach but you are free to leave (and you helped us discover that we had not enacted policies around account deletion, thanks)

Rubygems.org has the right to retain and distribute work that is licensed to us for distribution. If you do not wish to participate in the community in the way is constructive for everyone, then you may host your code elsewhere.

I understand your feedback despite your insults. If you choose to come back we will make your gems available to you again if you wish. We plan to allow version and gem deprecation with messages to address your and other's concerns, however we were faced with other threats that made it necessary for us to make this change immediately and then take feedback afterwards.

Ultimately, I'm sorry that this struck a nerve for you and I wish we could have done this in a way that hurt no one. It just happens that you're also the very highest user of yank on all of rubygems.org by a wide margin. If anyone was going to be impacted, it's you. I'm sorry for that and we will continue to work to make rubygems better for everyone.