search

rubygems / rubygems.org

The Ruby community's gem hosting service.
https://rubygems.org
MIT License
2.31k stars 915 forks source link

RFC: Team accounts? #2258

Closed aldesantis closed 2 years ago

aldesantis commented 4 years ago

I'm not sure whether this should be posted as a GitHub issue or in Google Groups. Let me know if I should move it! 🙏

Background: I'm part of the @solidusio core team, and we manage a lot of gems (the ones that make up Solidus core + all the community-maintained extensions).

It would be extremely useful for us to have some sort of built-in organization/team functionality that allows us to assign permissions in bulk rather than having to add core team members to each gem one by one. This would be very similar to how GitHub organizations work: gems belong to an organization, and all members of that organization have access to its gems.

After a cursory look at the GitHub issues and Google Groups, I was surprised to find that this doesn't seem to have been discussed before — or perhaps I'm missing something?

If there's interest around this feature, I could try to work on a spike, but I want to make sure this isn't something that's been discussed and rejected before, or implemented in some other form.

simi commented 4 years ago

Hello, I'm thinking for long time to something similar and related (AFAIK already used in npm) to provide scoped packages. For example activerecord would be able to live in rails namespace. Using npm terminology it would be @rails/activerecord.

:thinking: That should potentially make typo squatting a little harder (or easier).

mriddle commented 3 years ago

+1 I also see value in introducing the concept of organizations/teams to rubygems.org.

mrdaniellewis commented 3 years ago

It would also be useful to avoid the dependency confusion attack recently in the news.

If you own a namespace on rubygems - and can properly protect it with 2fa - you know that namespace is safe (or at least safer) from typeosquatting, or private/public dependency name confusion.

simi commented 3 years ago

@mrdaniellewis you can still typeosquat on namespace name :shrug:

mrdaniellewis commented 3 years ago

But a mistake on the namespace name less likely and more obvious then one on the package name. I've seen at least one person recommand you use namespaced names on npm to help avoid issues like the ones raised here https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

Obviously it wouldn't be a panacea, or even the main reason for doing this.