Hoe poisoned in Rubyforge

[Eric Hodel]

Somehow hoe-1.1.7 has become poisoned in the RubyGems index:

$ sudo gem install hoe
Install required dependency zentest? [Yn] ^CERROR: Interrupted

There is no gem by the name of 'zentest', and hoe will likely never
depend on 'ZenTest'.

Until this is fixed you won't be able to install any Gems built with
hoe-1.1.7.

 

[Ryan Davis]

Somehow hoe-1.1.7 has become poisoned in the RubyGems index:
$ sudo gem install hoe
Install required dependency zentest? [Yn] ^CERROR: Interrupted
There is no gem by the name of 'zentest', and hoe will likely never
depend on 'ZenTest'.
Until this is fixed you won't be able to install any Gems built
with hoe-1.1.7.

This is obviously the work of someone extending rubygems to have
developer dependencies. Regardless of intent: you had NO RIGHT to
upload ANYTHING to the gem repository under someone else's name or
project. NONE. EVER. To say that I'm unhappy about this (and you) is
a vast f@cking understatement.

P.S. There is a suite of unit tests built-in to rubygems for exactly
this purpose. You might want to try writing some quality code before
you decide you're equipped enough to start working on rubygems.

 

[Eric Hodel]

Somehow hoe-1.1.7 has become poisoned in the RubyGems index:

$ sudo gem install hoe
Install required dependency zentest? [Yn] ^CERROR: Interrupted

There is no gem by the name of 'zentest', and hoe will likely never
depend on 'ZenTest'.

Until this is fixed you won't be able to install any Gems built
with hoe-1.1.7.

Actually, you can download hoe by hand:

http://rubyforge.org/frs/download.php/16275/hoe-1.1.7.gem

and install it by hand:

gem install hoe

To work around the infinite dependency loop.

 

[Eric Hodel]

On Sun, 14 Jan 2007 08:44:25 -0000, Ryan Davis <ryand-

Somehow hoe-1.1.7 has become poisoned in the RubyGems index:
$ sudo gem install hoe
Install required dependency zentest? [Yn] ^CERROR: Interrupted
There is no gem by the name of 'zentest', and hoe will likely
never depend on 'ZenTest'.
Until this is fixed you won't be able to install any Gems built
with hoe-1.1.7.

This is obviously the work of someone extending rubygems to have
developer dependencies. Regardless of intent: you had NO RIGHT to
upload ANYTHING to the gem repository under someone else's name or
project. NONE. EVER. To say that I'm unhappy about this (and you)
is a vast f@cking understatement.

Is the implication here that someone on seattle.rb uploaded a new
gem, or that someone hacked Rubyforge to do it, or what?

You can upload a gem of any name to any rubyforge project including
gems with name collisions. It appears that somebody uploaded a
modified copy of hoe then deleted it shortly afterward.

Only the gem index has been poisoned, it seems that the bad hoe
didn't get mirrored.

The poisoning indicates it was done by somebody attempting to add
developer dependencies to RubyGems.

Just wondering, since if it's the latter others may need to check
their gems too,

While this upsets me to no end, I'll pin it on incompetence and/or
idoicy.

Whoever did this ignored a perfectly good set of unit tests, testing
tools, and the gem_server command itself to test out what they were
doing.

and Tom Copeland should probably hear about it.

He's been notified, but he's asleep.

 

[Gregory Brown]

Gotcha. I didn't realise that. It's kind of worrying actually. Maybe
something that could be tightened up somehow by the Rubyforge folks?

Hmm... I think this is not entirely a RubyForge problem, but also
something to do with RubyGems, IIRC. I thought that on RubyForge we
had something that said 'gem name already exists'.

<shrugs>

It does need to be dealt with.

 

[Chris Carter]

Somehow hoe-1.1.7 has become poisoned in the RubyGems index:

$ sudo gem install hoe
Install required dependency zentest? [Yn] ^CERROR: Interrupted

There is no gem by the name of 'zentest', and hoe will likely never
depend on 'ZenTest'.

Until this is fixed you won't be able to install any Gems built with
hoe-1.1.7.

I want to apologize to the group on this one. It was cause my my
utter incomptence, and I know I really screwed up here, I was testing
adding dependencies, I thought I had it, and In a rush, I added the
bad Hoe gem to rubyforge under a different name, which, I did wrong,
and I shouldn't have done in the first place. After a while I
realized this could cause problems, so I deleted it, and checked, and
the issue wasn't affecting my machine yet, so I assumed I had caught
it before gems propogated, which I had not. I know this was a big
fu@king mistake, I know I should have handled it better than just
deleting the gem. I am very sorry, and hope that it gets resolved
soon, so people are no longer inconvenienced. If I can do anything to
help this mess, please contact me. I am sorry to you Eric, and to
this community.

 

[Gregory Brown]

I want to apologize to the group on this one. It was cause my my
utter incomptence, and I know I really screwed up here, I was testing
adding dependencies, I thought I had it, and In a rush, I added the
bad Hoe gem to rubyforge under a different name, which, I did wrong,
and I shouldn't have done in the first place.

Please do not use RubyForge for testing without asking Tom first.

 

[Gregory Brown]

So if I have a RubyForge account I can upload a modified gem, of, say,
Rails, with a backdoor, and unknowing ruby users will accidentally install
it and open a backdoor in production rails servers?

I think if security is an issue, you should not download directly from
RubyForge via gems, but set up an audited gem server locally. (Or
download the files and gem install them locally)

Of course, this does not mean that such a problem isn't seriously disruptive.

 

[Gregory Brown]

I too think so, but probably most people don't work with a local audited gem
server, and just install gems from rubyforge - so the rubyforge people carry
this responsibility, whether they want it or not. They are not /obligated/
to act accordingly, but it would be appropriate that they do. IMHO.

Tom is very responsive. This is not entirely a RubyForge issue
though. RubyGems needs to also know how to respond according to
conflicts.

At one point it was using a "*" after whatever your query was, I think
this has been fixed, but there needs to be work both with the service
(RubyForge) and the platform (RubyGems) to solve this problem.

I'm sure things will get taken care of accordingly.

 

[Ben Bleything]

You can upload a gem of any name to any rubyforge project including
gems with name collisions. It appears that somebody uploaded a
modified copy of hoe then deleted it shortly afterward.

This happened quite inadvertently to me this summer, and at the time,
Tom told me that Things had been Changed so that it wasn't possible
anymore. I wonder what happened?

While this upsets me to no end, I'll pin it on incompetence and/or
idoicy.

There's some chance it was an honest mistake, but I doubt it given the
circumstances

Ben

 

[Tom Copeland]

You can upload a gem of any name to any rubyforge project including
gems with name collisions.

That's true. For example, I could upload a gem called "rails-2.0.gem"
to my project "foo" on RubyForge.

However, we built various checks into the gem index builder on RubyForge
to prevent such gems from being deployed. Perhaps there are holes in
these checks, and if so, we'll fix them.

Yours,

Tom

 

[Tom Copeland]

I want to apologize to the group on this one. It was cause my my
utter incomptence, and I know I really screwed up here, I was testing
adding dependencies, I thought I had it, and In a rush, I added the
bad Hoe gem to rubyforge under a different name, which, I did wrong,
and I shouldn't have done in the first place. After a while I
realized this could cause problems, so I deleted it, and checked, and
the issue wasn't affecting my machine yet, so I assumed I had caught
it before gems propogated, which I had not. I know this was a big
fu@king mistake, I know I should have handled it better than just
deleting the gem. I am very sorry, and hope that it gets resolved
soon, so people are no longer inconvenienced. If I can do anything to
help this mess, please contact me. I am sorry to you Eric, and to
this community.

Hi Chris -

Can you please drop me a note offlist at (e-mail address removed)? It seems
the code I wrote to prevent just these sorts of situations may not have
been sufficient. I'd definitely appreciate you help in sorting things
out...

Thanks,

Tom

 

[Tom Copeland]

So if I have a RubyForge account I can upload a modified gem, of, say,
Rails, with a backdoor, and unknowing ruby users will accidentally install
it and open a backdoor in production rails servers?

We built various checks into the gem index builder on RubyForge
to prevent overlapping gems from being deployed. Perhaps there are
holes in these checks, and if so, we'll fix them.

Yours,

Tom

 

[Daniel Berger]

That's true. For example, I could upload a gem called "rails-2.0.gem"
to my project "foo" on RubyForge.

WTF? The "foo" project is MY project! What do you think you're doing?!

A clear cut case of foo poisoning.



Regards,

Dan

 

[Ola Bini]

I want to apologize to the group on this one. It was cause my my
utter incomptence, and I know I really screwed up here, I was testing
adding dependencies, I thought I had it, and In a rush, I added the
bad Hoe gem to rubyforge under a different name, which, I did wrong,
and I shouldn't have done in the first place. After a while I
realized this could cause problems, so I deleted it, and checked, and
the issue wasn't affecting my machine yet, so I assumed I had caught
it before gems propogated, which I had not. I know this was a big
fu@king mistake, I know I should have handled it better than just
deleting the gem. I am very sorry, and hope that it gets resolved
soon, so people are no longer inconvenienced. If I can do anything to
help this mess, please contact me. I am sorry to you Eric, and to
this community.

Just as an aside, you're not the first to do mistakes like this...
Sometime in September I uploaded a gem to RubyForge that was generated
with JRuby. At that point in time there was a flaw in the JRuby YAML
library that regular Ruby (and SYCK) couldn't handle, which resulted in
the complete RubyForge gem-index being broken for a few hours. Quite
embarrassing. (The JRuby issue was fixed very soon after that, of
course, and JRuby is now safe to use for generating gems).

I would like to add that I find Ryans words quite harsh in the context.
We all make mistakes.

--
Ola Bini (http://ola-bini.blogspot.com)
JvYAML, RbYAML, JRuby and Jatha contributor
System Developer, Karolinska Institutet (http://www.ki.se)
OLogix Consulting (http://www.ologix.com)

"Yields falsehood when quined" yields falsehood when quined.

 

[M. Edward (Ed) Borasky]

WTF? The "foo" project is MY project! What do you think you're doing?!

A clear cut case of foo poisoning.



Regards,

Dan

Well ... at least it was just "foo" and not "foobar", where "bar" is
defined as "beyond all repair".

 

[Tom Copeland]

We built various checks into the gem index builder on RubyForge
to prevent overlapping gems from being deployed. Perhaps there are
holes in these checks, and if so, we'll fix them.

Also, it seemed prudent to not deploy any more gems until we get this
sorted out. So I've commented out the cron job that does that.

Yours,

Tom

 

[Gregory Brown]

Just as an aside, you're not the first to do mistakes like this...

yep, Turns out that ruport-lean was getting installed over ruport due
to that "*" rule a while back, so I've made the mistake too.

I've come to the point where any time I want to do something clever,
I've set up test environments both via gem_server and via static file
hosting like RubyForge does.

This way, if something goes wrong, it only effects me. When I get
around to it, I'll write a simple tutorial of how to set up your own
testing environment for this, and maybe talk a little bit to Tom about
getting the environment as close to RubyForge as possible.

 

[_why]

I want to apologize to the group on this one. It was cause my my
utter incomptence, and I know I really screwed up here [...]

Just as an aside, you're not the first to do mistakes like this...
Sometime in September I uploaded a gem to RubyForge that was generated
with JRuby [...]

I broke Ruby 1.8.3. So don't feel too bad!!

_why

 

[Ola Bini]

I want to apologize to the group on this one. It was cause my my
utter incomptence, and I know I really screwed up here [...]

Just as an aside, you're not the first to do mistakes like this...
Sometime in September I uploaded a gem to RubyForge that was generated
with JRuby [...]

I broke Ruby 1.8.3. So don't feel too bad!!

_why

Hehe, that's sweet. I don't feel about it anymore though, but at the
time it felt... icky. But I'm in a good timezone for breaking things
globally. Neither Americans nor Japanese people notice in some hours...

--
Ola Bini (http://ola-bini.blogspot.com)
JvYAML, RbYAML, JRuby and Jatha contributor
System Developer, Karolinska Institutet (http://www.ki.se)
OLogix Consulting (http://www.ologix.com)

"Yields falsehood when quined" yields falsehood when quined.