Hoe poisoned in Rubyforge

[Rob Sanheim]

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

_why for the win.

 

[James Edward Gray II]

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 Gray II

 

[John Wilger]

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.

 

[Gregory Brown]

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.

 

[Giles Bowkett]

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?

 

[Tom Copeland]

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.

Wouldn't the best thing be to streamline the system so this
kind of thing can't happen?

Right on, that's where we want to go.

Yours,

Tom

 

[Stephan Mueller]

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(TM) in the unit tests and bork the rubyforge
server.


Cheers,

Steph.

 

[Tom Copeland]

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(TM) 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

 

[Brad Ediger]

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

 

[Eric Hodel]

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.

 

[Ezra Zygmuntowicz]

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 Zygmuntowicz
-- Lead Rails Evangelist
-- (e-mail address removed)
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)

 

[Ryan Davis]

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.

Basically, until we can get rubygems shored up to the point where
gems can't be poisoned again and the index can be trusted to be
correct/clean. I've got 2-3 gems pending too, but I'm more than
willing to wait at this moment considering what happened to hoe so
easily.

 

[Ezra Zygmuntowicz]

Basically, until we can get rubygems shored up to the point where
gems can't be poisoned again and the index can be trusted to be
correct/clean. I've got 2-3 gems pending too, but I'm more than
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 Zygmuntowicz
-- Lead Rails Evangelist
-- (e-mail address removed)
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)

 

[Tom Copeland]

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

Yup, sorry for the delay. Eric Hodel and Paul Duncan had some good
suggestions yesterday for fixing this and I need to get cracking on
those...

Yours,

Tom

 

[Tom Copeland]

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

 

[Paolo Negri]

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

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

 

[Ryan Davis]

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)

 

[Lyle Johnson]

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

 

[Paul Duncan]

--Lg8eXa+brxrbjAbR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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?
=20
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...

SonOfLilit

--=20
Paul Duncan <[email protected]> pabs in #ruby-lang (OPN IRC)
http://www.pablotron.org/ OpenPGP Key ID: 0x82C29562

--Lg8eXa+brxrbjAbR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFFrtXkzdlT34LClWIRAs0CAKDV+D+XN1eodKS5sh0+GJa7+nCgLgCgxcnR
rHRIMPkKMcYQN0nMKodhvog=
=d8HV
-----END PGP SIGNATURE-----

--Lg8eXa+brxrbjAbR--

 

[Tom Copeland]

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