Hoe poisoned in Rubyforge

Ruby
21

On Mon, Jan 15, 2007 at 03:38:40AM +0900, Ola B. wrote:

Chris C. 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 […]

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

22

Tom

Hi Tom

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

I’ve got some questions

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

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?

thanks again

Paolo

23

On 1/14/07, SonOfLilit [email protected] 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?

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.

24

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

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.

There’s a fix in place for this now and gems are being deployed as
usual. There were several gems whose spec.full_name settings prevented
them from being deployed; I’ll contact those folks offline.

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.

Questions and comments are welcome,

Yours,

Tom

25

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?

Nope, it just means that you won’t be able to release a gem who’s
spec.full_name is greatly different than the file name.

Yours,

Tom

26

Tom C. wrote:

On Sun, 2007-01-14 at 20:59 +0900, Eric H. wrote:

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.

WTF? The “foo” project is MY project! What do you think you’re doing?!

A clear cut case of foo poisoning.

:stuck_out_tongue:

Regards,

Dan

27

On Sun, Jan 14, 2007, Eric H. wrote:

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 :stuck_out_tongue:

Ben

28

On Jan 15, 2007, at 02:59, Giles B. wrote:

Everybody makes mistakes, and everybody loses their temper. In fact
since losing your temper is a mistake, the second part’s redundant.

On the upside, the whole thing read like a murder mystery.

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? Wouldn’t the best thing be to streamline the system so this
kind of thing can’t happen?

If you’re working on project X that you don’t normally work on, look
for tests in project X and run those. Don’t test by playing with the
live system.

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

I LIT YOUR GEM ON FIRE!

29

“Robert D.” [email protected] writes:

Cheers
Robert

A lot of people wouldn’t have done that. Anyone who was surprised by
the reaction should refer to the archives for this list.

Steve

30

On Sun, 14 Jan 2007 08:44:25 -0000, Ryan D.
[email protected]
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? Just wondering, since
if
it’s the latter others may need to check their gems too, and Tom
Copeland
should probably hear about it.

31

On Jan 14, 2007, at 10:50 AM, Tom C. wrote:

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

Hey Tom-

I was just wondering when you were going to start pushing gems out
again? I released a gem yesterday morning and it still hasn’t
propagated yet.

Thanks-

– Ezra Z.
– Lead Rails Evangelist
– [email protected]
– Engine Y., Serious Rails Hosting
– (866) 518-YARD (9273)

32

_why wrote:

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

33

On Jan 15, 2007, at 11:28 PM, Ryan D. wrote:

willing to wait at this moment considering what happened to hoe so
easily.

Yeah I’m fine with waiting on releases to get this fixed myself.
Just wondering is all.

Cheers-
– Ezra Z.
– Lead Rails Evangelist
– [email protected]
– Engine Y., Serious Rails Hosting
– (866) 518-YARD (9273)

34

On Sun, 14 Jan 2007 11:59:35 -0000, Eric H. [email protected]
wrote:

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

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.

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

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.

Yep, definitely sounds like some combination of the two…

and Tom C. should probably hear about it.

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

Ahh, well, fair enough…

Thanks,

35

There’s a fix in place for this now and gems are being deployed as
usual. There were several gems whose spec.full_name settings
prevented
them from being deployed; I’ll contact those folks offline.

Tom, given that rake’s gem tasks are almost always creating the file
in question, any idea how or why the file name differs from the
specification? In the case of the poisoning it was obviously renamed
before pushed up to rubyforge… but the 20 others? (I’d hate to
think they were all hand packaged–ugh)

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.

Yours,

tom

36

Daniel B. wrote:

WTF? The “foo” project is MY project! What do you think you’re doing?!

A clear cut case of foo poisoning.

:stuck_out_tongue:

Regards,

Dan

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

:slight_smile:

–
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.

37

On Jan 15, 2007, at 7:09 AM, Tom C. wrote:

deploying them, and we’re adding more to catch the situation that
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.

You could always get freaky freaky
(http://code.whytheluckystiff.net/sandbox/).

38

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

I want to apologize …

Just to tell you that I feel very much with you, I am the King of
making
Mistakes like that.
I know how one feels.
You are very brave, hopefully that will be considered in your favor :wink:

Cheers
Robert

39

On Jan 17, 2007, at 6:44 AM, Tom C. wrote:

There’s a fix in place for this now and gems are being deployed as
usual. There were several gems whose spec.full_name settings
prevented
them from being deployed; I’ll contact those folks offline.

Tom, given that rake’s gem tasks are almost always creating the file
in question, any idea how or why the file name differs from the
specification? In the case of the poisoning it was obviously renamed
before pushed up to rubyforge… but the 20 others? (I’d hate to
think they were all hand packaged–ugh)

40

On Thu, 2007-01-18 at 11:05 +0900, Paul D. 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?

This sounds bad. VERY bad.

It is very bad.

Well, maybe “was”, since the problem “SonOfLilit” was talking about has
been fixed.

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

If only people were using it…

Something like that would be good, and I encourage folks to read through
Paul’s posts to rubygems-developers to get an idea of the possibilities
of gem signing.

Yours,

Tom