Hoe poisoned in Rubyforge

Ruby
1

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.

–
Eric H. - [email protected] - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!

2

On Jan 14, 2007, at 24:30, Eric H. wrote:

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 H. - [email protected] - http://blog.segment7.net

YOU LIT MY GEM ON FIRE!

3

On 1/14/07, Eric H. [email protected] wrote:

–
Eric H. - [email protected] - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!

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.

4

On 1/14/07, Chris C. [email protected] wrote:

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.

5

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?

This sounds bad. VERY bad.

WTF?

SonOfLilit

6

On Jan 14, 7:42 am, “Chris C.” [email protected] wrote:

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 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.

Chris,

Your public apology and offer to help in fixing any problems it caused
shows a lot of professionalism on your part. Everyone makes mistakes;
most people wouldn’t voluntarily own up to them in front of the whole
community. You have my respect.

–
Regards,

John W.

7

On Sun, 2007-01-14 at 13:20 -0500, Tom C. wrote:

On Mon, 2007-01-15 at 00:56 +0900, SonOfLilit wrote:

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.

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

8

Here’s an example: “fxruby-1.6.2-ruby1.8.5-mswin32.gem”.
Most of the
others are along the same lines… platform-specific renamings and
that kind of thing.

For the record, that one was originally named
“fxruby-1.6.2-mswin32.gem”, and then I renamed it before
uploading it. (It didn’t come out of the Gem builder with that name.)

Yup, I’m not sure about what’s a good way to name these more specific
gems…

Tom

9

On Mon, 2007-01-15 at 00:42 +0900, Chris C. wrote:

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 [email protected]? 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

10

On Jan 14, 2007, at 03:20, Ross B. wrote:

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 C. should probably hear about it.

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

–
Eric H. - [email protected] - http://blog.segment7.net

YOU LIT MY GEM ON FIRE!

11

On 1/14/07, John W. [email protected] wrote:

Chris,

Your public apology and offer to help in fixing any problems it caused
shows a lot of professionalism on your part. Everyone makes mistakes;
most people wouldn’t voluntarily own up to them in front of the whole
community. You have my respect.

I agree with the sentiments and it’s nice for folks to address this,
but let’s not build a reactions thread here. Ryan and Eric’s
rudeness speaks only of Ryan and Eric, and not of the folks who they
are rude too. I do hope most of the folks on the list realize they
only represent two of many Rubyists in the world who still think
MINASWAN is a good idea.

So, I’m just saying, let’s not spend time justifying for them each
time some harsh words are said.

12

First of all I want to thank you and all the people who
worked hard in these days to fix this issue.

Thanks!

What will happen to the gems which were already in the index
and don’t respect the naming convention?

There were about 20 of those; I’ll contact the authors of them
individually.

How the gem update command will work when the gems that don’t
respect the naming convention will be upgraded to newer
version with different names?

Hm, I’m not sure. But there were very few of them, so hopefully it
won’t be too much of a problem.

Yours,

Tom

13

On Mon, 2007-01-15 at 21:42 +0900, Stephan M. wrote:

test suite itself.

executing code in the uploaded gems (if this is the case here - didn’t
follow the thread all the time) might be dangerous itself. An attacker
could place some evil code™ in the unit tests and bork the rubyforge
server.

Yup. Right now we parse the gem file itself, so that shouldn’t happen.
But if we actually execute that code, we might want to do it in a
vserver or some such.

Yours.

Tom

14

On Mon, 2007-01-15 at 19:59 +0900, Giles B. wrote:

If the unit tests Ryan mentioned were automatically triggered by
uploading a gem, couldn’t that operate as a gate preventing this sort
of thing?

That’s an interesting idea. We do run some tests on the gems before
deploying them, and we’re adding more to catch the situation that
happened Saturday night. But perhaps we can add more from the gem unit
test suite itself.

executing code in the uploaded gems (if this is the case here - didn’t
follow the thread all the time) might be dangerous itself. An attacker
could place some evil code™ in the unit tests and bork the rubyforge
server.

Cheers,

Steph.

15

On 1/17/07, Tom C. [email protected] wrote:

Generally, if you have a project called “foo”, you’ll need to name the
gem something like “foo-4.2.gem” for it to be deployed on the RubyForge
gem index. Of course, you can release a file with whatever name you
want on your project; this naming limitation only applies if you want
the gem indexed.

Does this mean that you won’t be able to release multiple gems from the
same
RubyForge project into the index under an umbrella project, like
seattlerb
does?

/Nick

16

On Jan 14, 2007, at 12:30 AM, Eric H. wrote:

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.

17

“Robert D.” [email protected] writes:

have felt very bad!
the reaction should refer to the archives for this list.

Steve

Steve
I meant everybody involved has my respect, not that everybody has done the
same as Chris.
Cheers
Robert

My fault. I was replying to your “well there were but who would not
have been?”. In my opinion a lot of people would not have responded
the way they did, but if you look at the archive you shouldn’t be
surprised.

Steve

18

On Jan 14, 2007, at 12:38 PM, Ola B. wrote:

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

Ryan’s and Eric’s, yes. They immediately assumed the worst and it’s
now clear that was overreacting. It was an honest mistake.

James Edward G. II

19

Chris C. wrote:

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 B. (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.

20

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?

This sounds bad. VERY bad.

It is very bad. This is the exact problem the package signing in
RubyGems was written to address.

If only people were using it…