4 ms·

An update from Ruby Central: Strengthening the Stewardship of RubyGems and Bundler https://rubycentral.org/news/strengthening-the-stewardship-of-rubygems-and-b

An update from Ruby Central: Strengthening the Stewardship of RubyGems and Bundler https://rubycentral.org/news/strengthening-the-stewardship-of-rubygems-and-bundler/ https://rubycentral.org/news/strengthening-the-stewardship-o...

sussmannbaka 1y ago
that’s a lot of words to write “we did a hostile takeover”
michaelem 1y ago
So uh… “compliance reasons”? That sounds rather concerning.
loloquwowndueo 1y ago
Totally reads like post-facto CYA. they could have communicated this to the maintainers internally beforehand instead of blindsiding them.
- downrightmike 1y ago
  The NPM breach was an email that stated the dev needed to update their MFA by the next day in order to keep their access. If you're arguing that is what ruby central should have done, that's a social engineering attack.
  - loloquwowndueo 1y ago
    It’s entirely possible to distinguish between legit internal communication and a phishing email. (It gets harder and harder every day but ultimately still possible)
  - mrinterweb 1y ago
    How would a heads up email look like a phishing email? Blindsiding the maintainers like this is just cruel.
yxhuvud 1y ago
It might have been a good idea to do that communication BEFORE creating all that drama.
jmuguy 1y ago
So essentially they randomly cut off a bunch of long time maintainers for some vague legal and/or security reasons. If there was real reason to do that in a hurry, that's what we need to see, not a corporate PR message.
- awilson5454 1y ago
  100%. I assumed this was inspired by the supply chain attack, but what a horrible way to address this. Reverting it back before revoking it a second time is even more bizarre. Severely mixed messages from leadership, perhaps?
- gedy 1y ago
  It’s not clear to me - did they entirely cut them off, or did they reduce their role as admin of the GitHub org? If so, I'm not defending it, and I could understand why someone would feel insulted by that - but also get why an org doesn't want too many with elevated privileges.
  - favorited 1y ago
    According to the author's PR where she removed herself as a maintainer, she lost commit access. https://github.com/rubygems/rubygems/pull/8987 https://github.com/rubygems/rubygems/pull/8987
raesene9 1y ago
If they're trying to strengthen security, this feels like an odd way to go about it. Making unplanned unexpected changes to GitHub ownership and removing people with lots of experience and institutional knowledge with little notice (based on the original story) and presumably no great hand-over, feels risky and not a great way to improve people's trust in their governance.
bradgessler 1y ago
It reads like lawyers and auditors took over RubyCentral.
- julik 1y ago
  * Get appointed as paid managers of a non-profit * Get advice from legal * Legal suggests removing long-term maintainers without liability contract the same way people get fired: immediately and instantly, and screw the consequences. "Open-source? Never heard of it. Protect your entity legally" * Instantly follow the advice of the lawyers to the letter. Well done, well done.
  - observationist 1y ago
    Aim it right at my foot? Are you sure?! Well, ok, I'm not a lawyer, but... ok, fine, let's do it!
- blibble 1y ago
  it's the professional management class at it again see: mozilla, nominet (recovered, thankfully)
  - observationist 1y ago
    Mozilla is toast. It basically exists as a tax writeoff for Google at this point, and serves no recognizable purpose beyond that, and maybe nostalgia. How MBAs aren't synonymous with leeches by this point is the most amazing ongoing PR campaign in history. They do nothing but suck and suck and suck, and they keep sucking, and they will never stop sucking until their host dies, and then they just move on.
    - immibis 1y ago
      Widespread recognition of what you said about MBAs is synonymous with class consciousness, which won't happen.
DannyPage 1y ago
> We want to express our deep gratitude to the many cohorts of maintainers who have contributed to Bundler and RubyGems over the past two decades. Ruby tooling would not be what it is today without their dedication and leadership. Their work laid much of the foundation we are building on today, and we are committed to carrying that legacy forward with the same spirit of *openness and collaboration* - The bolded part doesn’t track with locking out the entire team without notice or explanation. - “Thanks for the hard work, the adults will take it from here” rarely works out.
thomascountz 1y ago
I think the fear from Ruby Central might have been that, had they communicated openly, a maintainer/community member with admin access could do their own hostile take-over, and that that would expose Ruby Central to some legal liability, if not a complete loss of control. I'm not in a position where I'd have to make a decision like this, and I don't have all the information, but I like to think that if I had made a decision like this, I'd show some more respect in the aftermath. Something more akin to: "That was really awful, I'm sorry. We were suddenly faced with the severity of our legal exposure and had to immediately lock everything down. It's not a reflection of trust or anything, it was legally what had to be done. Now that we've taken stock and are now squared away, we have to make a more explicit controls framework, and we hope we can make it up to you, make this right, and have you lead as a maintainer again." ...Then again, maybe this wasn't about legal exposure. Or maybe it was and former contributors/maintainers are getting apologetic emails right now...
- loloquwowndueo 1y ago
  1. You lock everyone out of the org for whichever valid but idiotic reason. 2. The instant you do, you send them all an email explaining the situation. That’s how you do it in those cases. You don’t blindside them and then wait for them to react, restore their access back (which totally negated and nullified the “I wanted to preempt a takeover attempt” argument) and continue to skulk around instead of being open about it.
  - thomascountz 1y ago
    You're completely right. In a generous interpretation, having so little communication over such a long period is where this went wrong. In any case, having your highly-tenured team dissolve and feeling like things were "hostile," is an indicator that you'll need to do better. Then again, who knows what the goal actually was? Maybe this went perfectly to plan. Given there was nothing approaching an acknowledgement of regret or apology in the press release, maybe this went exactly to plan.
    - ryandrake 1y ago
corytheboyd 1y ago
Aren’t supply chain attacks caused by package maintainer accounts being compromised? I suppose too many people with keys to the package repository itself is also liability, but those accounts being compromised just hasn’t been what is happening.
- krmbzds 1y ago
  [flagged]
  - woodruffw 1y ago
    Your last sentence reads like a weird swipe: as best I can tell, there's no cultural war dimension to this whatsoever?
    - krmbzds 1y ago
      [flagged]
      - the_hangman 1y ago
        It's been a while but if memory serves me correctly the controversy at that time was actually about him unilaterally deciding that people at basecamp shouldn't be talking about politics in off-topic slack channels after people started trying to organize support for something he didn't agree with. IIRC something like 1/3 of the company quit at that time
        zorpner 1y ago
        Specifically, it was in a meeting called by Jason Fried to address people who were concerned about the ongoing existence of an internal list of "funny customer names" (which by all accounts was extremely racist), in which Ryan Singer (who had reportedly previously posted a fair bit of politically right-wing content on internal forums -- those were all deleted when the "no politics at work" policy was rolled out) repeatedly asserted that white supremacy/privilege did not exist (he then resigned). In the aftermath, DHH dug through old chat logs to find a time in the past when one of the people complaining about the list participated in a discussion about same without complaint, and posted it in a way that was visible to everyone saying that their prior participation meant that their current complaint was invalid. Then they rolled out the no-politics-at-work policy in this post dated April 26 2021 -- I would encourage anyone interested in the specifics to read through the various versions and edits of this post made in the week following, all without noting that it was being actively changed: https://world.hey.com/jason/changes-at-basecamp-7f32afc5 https://world.hey.com/jason/changes-at-basecamp-7f32afc5
krmbzds 1y ago
> We thank the maintainers and respect their legacy. After removing them without explanation, cutting them off projects they have maintained over a decade and ignoring them when they asked for restoration or dialogue. I feel sad for the maintainers. This is not how they deserve to be treated.
TehCorwiz 1y ago
> Moving forward, only engineers employed or contracted by Ruby Central will hold administrative permissions to the RubyGems.org service. Several of the people removed are employees or contractors of Ruby Central. This doesn't pass the smell test. Not to mention it's post-facto in that they did all of this before notifying anyone.
- byroot 1y ago
  > Several of the people removed are employees or contractors of Ruby Central. Who? > Not to mention it's post-facto in that they did all of this before notifying anyone. Isn't that pretty much the number one rule when restricting accesses? First remove accesses, then communicate?
  - TehCorwiz 1y ago
    At least Ellen Dash. The author of the pdf the post links to.
    - byroot 1y ago
      They haven't been contracted by Ruby Central since May by their own account: https://bsky.app/profile/duckinator.bsky.social/post/3lz7lechlzk2b https://bsky.app/profile/duckinator.bsky.social/post/3lz7lec... The other people I know who had their accesses removed have resigned from RC a while ago, and the one I still see with access on https://rubygems.org/gems/bundler https://rubygems.org/gems/bundler are people I know are currently employed or contractors. As far as I can tell, this part of the Ruby Central statement seems to check out. Now you can of course debate whether commit rights should be limited to employees, but have have no indication that they lied here.
tarellel 1y ago
This is just RubyCenteral trying to get ahead of the news and save face before they end up looking like complete @$$ bags.

sussmannbaka 1y ago

that’s a lot of words to write “we did a hostile takeover”

michaelem 1y ago

So uh… “compliance reasons”? That sounds rather concerning.

loloquwowndueo 1y ago

Totally reads like post-facto CYA. they could have communicated this to the maintainers internally beforehand instead of blindsiding them.

downrightmike 1y ago
The NPM breach was an email that stated the dev needed to update their MFA by the next day in order to keep their access. If you're arguing that is what ruby central should have done, that's a social engineering attack.
- loloquwowndueo 1y ago
  It’s entirely possible to distinguish between legit internal communication and a phishing email. (It gets harder and harder every day but ultimately still possible)
- mrinterweb 1y ago
  How would a heads up email look like a phishing email? Blindsiding the maintainers like this is just cruel.

yxhuvud 1y ago

It might have been a good idea to do that communication BEFORE creating all that drama.

jmuguy 1y ago

So essentially they randomly cut off a bunch of long time maintainers for some vague legal and/or security reasons. If there was real reason to do that in a hurry, that's what we need to see, not a corporate PR message.

awilson5454 1y ago
100%. I assumed this was inspired by the supply chain attack, but what a horrible way to address this. Reverting it back before revoking it a second time is even more bizarre. Severely mixed messages from leadership, perhaps?
gedy 1y ago
It’s not clear to me - did they entirely cut them off, or did they reduce their role as admin of the GitHub org? If so, I'm not defending it, and I could understand why someone would feel insulted by that - but also get why an org doesn't want too many with elevated privileges.
- favorited 1y ago
  According to the author's PR where she removed herself as a maintainer, she lost commit access. https://github.com/rubygems/rubygems/pull/8987 https://github.com/rubygems/rubygems/pull/8987

raesene9 1y ago

If they're trying to strengthen security, this feels like an odd way to go about it. Making unplanned unexpected changes to GitHub ownership and removing people with lots of experience and institutional knowledge with little notice (based on the original story) and presumably no great hand-over, feels risky and not a great way to improve people's trust in their governance.

bradgessler 1y ago

It reads like lawyers and auditors took over RubyCentral.

julik 1y ago
* Get appointed as paid managers of a non-profit * Get advice from legal * Legal suggests removing long-term maintainers without liability contract the same way people get fired: immediately and instantly, and screw the consequences. "Open-source? Never heard of it. Protect your entity legally" * Instantly follow the advice of the lawyers to the letter. Well done, well done.
- observationist 1y ago
  Aim it right at my foot? Are you sure?! Well, ok, I'm not a lawyer, but... ok, fine, let's do it!
blibble 1y ago
it's the professional management class at it again see: mozilla, nominet (recovered, thankfully)
- observationist 1y ago
  Mozilla is toast. It basically exists as a tax writeoff for Google at this point, and serves no recognizable purpose beyond that, and maybe nostalgia. How MBAs aren't synonymous with leeches by this point is the most amazing ongoing PR campaign in history. They do nothing but suck and suck and suck, and they keep sucking, and they will never stop sucking until their host dies, and then they just move on.
  - immibis 1y ago
    Widespread recognition of what you said about MBAs is synonymous with class consciousness, which won't happen.

DannyPage 1y ago

> We want to express our deep gratitude to the many cohorts of maintainers who have contributed to Bundler and RubyGems over the past two decades. Ruby tooling would not be what it is today without their dedication and leadership. Their work laid much of the foundation we are building on today, and we are committed to carrying that legacy forward with the same spirit of *openness and collaboration* - The bolded part doesn’t track with locking out the entire team without notice or explanation. - “Thanks for the hard work, the adults will take it from here” rarely works out.

thomascountz 1y ago

I think the fear from Ruby Central might have been that, had they communicated openly, a maintainer/community member with admin access could do their own hostile take-over, and that that would expose Ruby Central to some legal liability, if not a complete loss of control. I'm not in a position where I'd have to make a decision like this, and I don't have all the information, but I like to think that if I had made a decision like this, I'd show some more respect in the aftermath. Something more akin to: "That was really awful, I'm sorry. We were suddenly faced with the severity of our legal exposure and had to immediately lock everything down. It's not a reflection of trust or anything, it was legally what had to be done. Now that we've taken stock and are now squared away, we have to make a more explicit controls framework, and we hope we can make it up to you, make this right, and have you lead as a maintainer again." ...Then again, maybe this wasn't about legal exposure. Or maybe it was and former contributors/maintainers are getting apologetic emails right now...

loloquwowndueo 1y ago
1. You lock everyone out of the org for whichever valid but idiotic reason. 2. The instant you do, you send them all an email explaining the situation. That’s how you do it in those cases. You don’t blindside them and then wait for them to react, restore their access back (which totally negated and nullified the “I wanted to preempt a takeover attempt” argument) and continue to skulk around instead of being open about it.
- thomascountz 1y ago
  You're completely right. In a generous interpretation, having so little communication over such a long period is where this went wrong. In any case, having your highly-tenured team dissolve and feeling like things were "hostile," is an indicator that you'll need to do better. Then again, who knows what the goal actually was? Maybe this went perfectly to plan. Given there was nothing approaching an acknowledgement of regret or apology in the press release, maybe this went exactly to plan.
  - ryandrake 1y ago

corytheboyd 1y ago

Aren’t supply chain attacks caused by package maintainer accounts being compromised? I suppose too many people with keys to the package repository itself is also liability, but those accounts being compromised just hasn’t been what is happening.

krmbzds 1y ago
[flagged]
- woodruffw 1y ago
  Your last sentence reads like a weird swipe: as best I can tell, there's no cultural war dimension to this whatsoever?
  - krmbzds 1y ago
    [flagged]
    - the_hangman 1y ago
      It's been a while but if memory serves me correctly the controversy at that time was actually about him unilaterally deciding that people at basecamp shouldn't be talking about politics in off-topic slack channels after people started trying to organize support for something he didn't agree with. IIRC something like 1/3 of the company quit at that time
      - zorpner 1y ago
        Specifically, it was in a meeting called by Jason Fried to address people who were concerned about the ongoing existence of an internal list of "funny customer names" (which by all accounts was extremely racist), in which Ryan Singer (who had reportedly previously posted a fair bit of politically right-wing content on internal forums -- those were all deleted when the "no politics at work" policy was rolled out) repeatedly asserted that white supremacy/privilege did not exist (he then resigned). In the aftermath, DHH dug through old chat logs to find a time in the past when one of the people complaining about the list participated in a discussion about same without complaint, and posted it in a way that was visible to everyone saying that their prior participation meant that their current complaint was invalid. Then they rolled out the no-politics-at-work policy in this post dated April 26 2021 -- I would encourage anyone interested in the specifics to read through the various versions and edits of this post made in the week following, all without noting that it was being actively changed: https://world.hey.com/jason/changes-at-basecamp-7f32afc5 https://world.hey.com/jason/changes-at-basecamp-7f32afc5

krmbzds 1y ago

> We thank the maintainers and respect their legacy. After removing them without explanation, cutting them off projects they have maintained over a decade and ignoring them when they asked for restoration or dialogue. I feel sad for the maintainers. This is not how they deserve to be treated.

TehCorwiz 1y ago

> Moving forward, only engineers employed or contracted by Ruby Central will hold administrative permissions to the RubyGems.org service. Several of the people removed are employees or contractors of Ruby Central. This doesn't pass the smell test. Not to mention it's post-facto in that they did all of this before notifying anyone.

byroot 1y ago
> Several of the people removed are employees or contractors of Ruby Central. Who? > Not to mention it's post-facto in that they did all of this before notifying anyone. Isn't that pretty much the number one rule when restricting accesses? First remove accesses, then communicate?
- TehCorwiz 1y ago
  At least Ellen Dash. The author of the pdf the post links to.
  - byroot 1y ago
    They haven't been contracted by Ruby Central since May by their own account: https://bsky.app/profile/duckinator.bsky.social/post/3lz7lechlzk2b https://bsky.app/profile/duckinator.bsky.social/post/3lz7lec... The other people I know who had their accesses removed have resigned from RC a while ago, and the one I still see with access on https://rubygems.org/gems/bundler https://rubygems.org/gems/bundler are people I know are currently employed or contractors. As far as I can tell, this part of the Ruby Central statement seems to check out. Now you can of course debate whether commit rights should be limited to employees, but have have no indication that they lied here.

tarellel 1y ago

This is just RubyCenteral trying to get ahead of the news and save face before they end up looking like complete @$$ bags.