Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Team accounts? #2258

Closed
aldesantis opened this issue Mar 9, 2020 · 5 comments
Closed

RFC: Team accounts? #2258

aldesantis opened this issue Mar 9, 2020 · 5 comments

Comments

@aldesantis
Copy link

aldesantis commented Mar 9, 2020

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
Copy link
Member

simi commented Mar 9, 2020

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.

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

@mriddle
Copy link

mriddle commented Jan 13, 2021

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

@mrdaniellewis
Copy link

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
Copy link
Member

simi commented Mar 29, 2021

@mrdaniellewis you can still typeosquat on namespace name 🤷

@mrdaniellewis
Copy link

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.

@rubygems rubygems locked and limited conversation to collaborators Dec 2, 2021
@hsbt hsbt closed this as completed Dec 2, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

6 participants