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

Already on GitHub? Sign in to your account

Add endpoint for claiming gems #424

Closed
qrush opened this Issue May 11, 2012 · 24 comments

Comments

Projects
None yet
Owner

qrush commented May 11, 2012

This is a biggie!

RG 2.0's plan is add a new step when pushing gems, gem claim. The workflow for pushing a new gem will be:

gem claim [gem name]
           ▼
gem push [local .gem file]
           ▼
gem install [gem name]

This fixes two big issues:

  1. Adds a verification step for creating a gem, which will stop "mistake", "oops" pushes of internal gems
  2. Allows developers to "reserve" gem names

The workflow for existing gems doesn't change, it's just gem push like normal. This is for new gems only.

This issue actually will involve several little steps:

  • New Gem::Command for gem claim
  • Endpoint and implementation of this logic (soft requirement now, hard requirement once RG 2.0 is out)
  • A way to contact the author of a claimed gem to get them to release the gem (probably will require another endpoint)

Pinging @sferik @cldwalker @cmeiklejohn for feedback, also heads up to @evanphx @drbrain!

wfarr commented May 11, 2012

👍

cowboyd commented May 11, 2012

Sounds like a good feature. The concern that immediately leaps out at me is gem-squatters.

wfarr commented May 11, 2012

Sounds like a good feature. The concern that immediately leaps out at me is gem-squatters.

Folks can still squat gem names now with pretty much blank gems, and this won't affect any existing gems that have been pushed since they'll be grandfathered into being claimed.

Owner

qrush commented May 11, 2012

Agreed, gem squatting is already a problem and actually costs us more since they're adding to our S3 bill, and it clogs the index.

However, I don't want to discourage it, if you found a good name! I think the point now is to facilitate the process of claiming and bugging an author of a claimed gem that you actually want that namespace.

wfarr commented May 11, 2012

@qrush It would be nice if gem claim returned contact info for the user who claimed the name already if there are no pushed versions.

This would definitely make it easy for folks with a gem ready to push to ask someone who might've already claimed the name but not pushed anything up to cede ownership.

Owner

qrush commented May 11, 2012

Yep, I imagine the output looking like so:

On success:

$ gem claim foo_bar
You've claimed the foo_bar gem. Next step: `gem push`
Check out http://guides.rubygems.org/make-your-own-gem/ if you need more help.

On claim, when that gem has no versions:

$ gem claim foo_bar
Looks like qrush (nick@quaran.to) has already claimed the foo_bar gem.

You can email this user directly to ask them to release it: `gem claim --release foo_bar`
Or, visit this URL: https://rubygems.org/gems/foo_bar/reclaims/new

On claim with an existing gem that has pushed versions:

$ gem claim rails
You can't claim this gem, someone's already pushed to this namespace.

@wfarr I agree. Especially since Github removed user-to-user messaging.

wfarr commented May 11, 2012

@qrush Sample output looks awesome to me. Resounding 👍

cowboyd commented May 11, 2012

@qrush @wfarr Well I'm sold then.

I'm mixed.

On one hand I like this idea and would have definitely saved my ass before.
On the other, the gem squatting issue is something that seems important.

The questions is who should get the gem name first? The person who's thought of the name first, or the person who's actually done some work on the gem first? And in my opinion, that's the latter. We should be promoting the work, rather than the name storming.

I do think squatting will be a big problem for sure though. And not even from people doing it with any form of malicious intent but just people who come up with good names for later dates.

Owner

qrush commented May 11, 2012

Just a reminder here: The bigger problem that creates a support load for us that this solves is mistake pushes.

Squatting is already a problem. This workflow now introduces a way for gem authors to resolve those naming/squatting problems without contacting us at help.rubygems.org.

With output along the lines of your example, and the ability to easily release as well as claim names, I dig this.

Contributor

cldwalker commented May 11, 2012

I'm not sure these two issues need to be solved together. To reduce accidental pushes, we could detect first pushes and add an extra: 'Are you sure you want zoolander?' To reduce support of squatting issues, we could add a way for users to contact each other (as suggested above). Neither of these solutions require gem claim.

The problems I see with gem claim:

  • It's easier for gem squatters to abuse:

    $ cat NAMES.txt | xargs gem claim

Yes, people can already squat but at least they have to go to the trouble to make a valid gemspec. Having users contact each other is great but it won't help if a couple of pranksters decided to slurp up a bunch of names. To remedy this we could have claims that expire after a certain time (30 days?).

  • It may not reduce supporting squatting issues. If somebody wants to squat on a name, it takes the same amount of effort as it did before - a valid gemspec.

wfarr commented May 11, 2012

We could rate limit claim requests by user to solve the mass squatting run.

Sent from my phone. Please excuse the brevity.

Will Farrington

On Friday, May 11, 2012 at 3:39 PM, Gabriel Horner wrote:

I'm not sure these two issues need to be solved together. To reduce accidental pushes, we could detect first pushes and add an extra: 'Are you sure you want zoolander?' To reduce support of squatting issues, we could add a way for users to contact each other (as suggested above). Neither of these solutions require gem claim.

The problems I see with gem claim:

  • It's easier for gem squatters to abuse:

$ cat NAMES.txt | xargs gem claim

Yes, people can already squat but at least they have to go to the trouble to make a valid gemspec. Having users contact each other is great but it won't help if a couple of pranksters decided to slurp up a bunch of names. To remedy this we could have claims that expire after a certain time (30 days?).

  • It may not reduce supporting squatting issues. If somebody wants to squat on a name, it takes the same amount of effort as it did before - a valid gemspec.

Reply to this email directly or view it on GitHub:
#424 (comment)

caius commented May 11, 2012

I think as you can already squat on a gemname (which I must admit, I've done once for a gem I was writing internally with an AWESOME name that I'm going to release publicly once we've hammered it a bit) this feature makes perfect sense. It's not difficult at all to squat currently, bundler gem <name> edit the gemspec, rake build && gem push pkg/*.gem iirc.

And reducing support load is a win for the rubygems team, and squatting is still a problem. Seems like an overall win to me. And I like the sample output @qrush, encourages people to play nicely.

Owner

drbrain commented May 11, 2012

@cldwalker How do you ask "Are you sure you want zoolander?" without adding a name-claiming process somewhere?

If it's all client-side then gem authors must upgrade to take advantage of it, which they may not do.

By adding it server-side we fix the problem of "please remove this gem" by preventing all first-pushes without upgrading RubyGems first

Owner

evanphx commented May 11, 2012

gem claim actually improves the squatting situation because it becomes easy for us to see that a name is being squatted (claimed but no gem pushed). We can then establish a policy for reclaiming those squatted names.

Contributor

cldwalker commented May 11, 2012

@drbrain I didn't realize oops pushes were a big enough problem to force a solution on everyone. If that's the case, then upgrading to a claim process is more user-friendly than "you must use a rubygems client that confirms push". My main concern with gem claim is ease of abuse. Rate limiting, claim expiration or limiting claims per user are all possible solutions.

Contributor

cldwalker commented May 11, 2012

@evanphx It may not improve the situation by much. It's true that we'll have more visibility for claimed gems but it won't prevent users who squat by submitting empty gems. While there may be a decrease of these users with gem claim, we don't know if that decrease will be offset by the new kind of squatting this process introduces - temporary squatting - the time between a claim and for whatever policy to ban them.

Owner

evanphx commented May 11, 2012

@cldwalker That's true but then we're back at the current state of things, so we're no worse. The gem claim feature isn't made to solely solve squatting, that was just a nice side effect. Thusly, we should still have gem claim.

Just a reminder here: The bigger problem that creates a support load for us that this solves is mistake pushes.

Why don't we fix the actual problem of gem yank not actually yanking? When people accidentally push something (usually with IP) to the wrong gem server, they want that file actually removed asap. gem yank only gives the illusion of this. Doesn't help that there's also a twitter account that broadcasts pushes as soon as they happen. Fixing gem yank and putting a 15 minute delay on the tweets would go a long way to making this whole feature request a non-issue.

Just to put this in perspective, the second this feature goes into effect I'll be adding auto-claim to Hoe. I suspect many other gem packaging libraries will do the same. So this bandaid won't really prevent accidental pushes and the original problem still remains.

I know this is old, but I still think that it should be implemented.

@qrush qrush added the health label Nov 28, 2014

Contributor

simi commented Apr 8, 2015

Was this idea rejected?

Owner

qrush commented Jul 7, 2015

It wasn't rejected...more like never got off the ground. Closing since it's been stale for a while.

🍞

@qrush qrush closed this Jul 7, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment