Forum: Ruby Hoe poisoned in Rubyforge

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2007-01-19 16:29
(Received via mailing list)
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 Hodel - drbrain@segment7.net - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2007-01-19 16:30
(Received via mailing list)
On Jan 14, 2007, at 24:30, Eric Hodel 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 Hodel - drbrain@segment7.net - http://blog.segment7.net

YOU LIT MY GEM ON FIRE!
96931bfe0c2948f47a98e15ae52e5637?d=identicon&s=25 Chris Carter (cdcarter)
on 2007-01-19 16:30
(Received via mailing list)
On 1/14/07, Eric Hodel <drbrain@segment7.net> wrote:
>
> --
> Eric Hodel - drbrain@segment7.net - 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.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2007-01-19 16:31
(Received via mailing list)
On 1/14/07, Chris Carter <cdcarter@gmail.com> 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.
560c83ff6b6600e39315a1cf75b7c229?d=identicon&s=25 Tom Copeland (Guest)
on 2007-01-19 16:31
(Received via mailing list)
On Mon, 2007-01-15 at 00:42 +0900, Chris Carter 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 tom@infoether.com?  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
7b4707f974af261f71943e1f2046c9ee?d=identicon&s=25 SonOfLilit (Guest)
on 2007-01-19 16:31
(Received via mailing list)
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
10d9ed7ab11115b081bb36f56a7a13bc?d=identicon&s=25 John Wilger (jwilger)
on 2007-01-19 16:31
(Received via mailing list)
On Jan 14, 7:42 am, "Chris Carter" <cdcar...@gmail.com> 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
<snip>
> 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 Wilger
http://johnwilger.com
560c83ff6b6600e39315a1cf75b7c229?d=identicon&s=25 Tom Copeland (Guest)
on 2007-09-25 22:29
(Received via mailing list)
On Sun, 2007-01-14 at 13:20 -0500, Tom Copeland 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
560c83ff6b6600e39315a1cf75b7c229?d=identicon&s=25 Tom Copeland (Guest)
on 2007-09-25 22:29
(Received via mailing list)
> > 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
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2007-09-25 22:30
(Received via mailing list)
On Jan 14, 2007, at 03:20, Ross Bamford 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 Copeland should probably hear about it.

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

--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net

YOU LIT MY GEM ON FIRE!
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2007-09-25 22:30
(Received via mailing list)
On 1/14/07, John Wilger <johnwilger@gmail.com> 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.
560c83ff6b6600e39315a1cf75b7c229?d=identicon&s=25 Tom Copeland (Guest)
on 2007-09-25 22:31
(Received via mailing list)
> 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
526d60de6472502bb570a9df2842b33b?d=identicon&s=25 Nick Sieger (Guest)
on 2007-09-25 22:31
(Received via mailing list)
On 1/17/07, Tom Copeland <tom@infoether.com> 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
560c83ff6b6600e39315a1cf75b7c229?d=identicon&s=25 Tom Copeland (Guest)
on 2007-09-25 22:31
(Received via mailing list)
On Mon, 2007-01-15 at 21:42 +0900, Stephan Mueller 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(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
Fcc5cdf0f0f3e1a3a39c11ed4bf8d5e5?d=identicon&s=25 Stephan Mueller (Guest)
on 2007-09-25 22:32
(Received via mailing list)
* Tom Copeland <tom@infoether.com> [15.01.2007]:

> On Mon, 2007-01-15 at 19:59 +0900, Giles Bowkett 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(TM) in the unit tests and bork the rubyforge
server.


Cheers,

Steph.
Bf1e672f5e54581db4e6d45b7030d286?d=identicon&s=25 Steven Lumos (Guest)
on 2007-09-25 22:33
(Received via mailing list)
"Robert Dober" <robert.dober@gmail.com> 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
5a837592409354297424994e8d62f722?d=identicon&s=25 Ryan Davis (Guest)
on 2007-09-25 22:33
(Received via mailing list)
On Jan 14, 2007, at 12:30 AM, Eric Hodel 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.
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2007-09-25 22:33
(Received via mailing list)
On Jan 14, 2007, at 12:38 PM, Ola Bini 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 Gray II
Ff260830c27224f0e15f37362a6256d0?d=identicon&s=25 Paul Duncan (Guest)
on 2007-09-25 22:33
(Received via mailing list)
* SonOfLilit (sonoflilit@gmail.com) 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.  This is the exact problem the package signing in
RubyGems was written to address.

If only people were using it...
7359ed44852399295c6247dd9719b81b?d=identicon&s=25 Ola Bini (Guest)
on 2007-09-25 22:34
(Received via mailing list)
Chris Carter 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 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.
19fdf8bd123216b5056fb856cf1a5771?d=identicon&s=25 _why (Guest)
on 2007-09-25 22:34
(Received via mailing list)
On Mon, Jan 15, 2007 at 03:38:40AM +0900, Ola Bini wrote:
> Chris Carter 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
10c122532c00465b809dbf9dc35806a7?d=identicon&s=25 Paolo Negri (Guest)
on 2007-09-25 22:36
(Received via mailing list)
> 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
560c83ff6b6600e39315a1cf75b7c229?d=identicon&s=25 Tom Copeland (Guest)
on 2007-09-25 22:36
(Received via mailing list)
On Sun, 2007-01-14 at 13:50 -0500, Tom Copeland 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
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2007-09-25 22:36
(Received via mailing list)
On 1/14/07, SonOfLilit <sonoflilit@gmail.com> 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.
Bf1e672f5e54581db4e6d45b7030d286?d=identicon&s=25 Steven Lumos (Guest)
on 2007-09-25 22:37
(Received via mailing list)
"Robert Dober" <robert.dober@gmail.com> 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
560c83ff6b6600e39315a1cf75b7c229?d=identicon&s=25 Tom Copeland (Guest)
on 2007-09-25 22:37
(Received via mailing list)
> 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
Aee77dba395ece0a04c688b05b07cd63?d=identicon&s=25 Daniel Berger (Guest)
on 2007-09-25 22:38
(Received via mailing list)
Tom Copeland wrote:
> On Sun, 2007-01-14 at 20:59 +0900, Eric Hodel 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.

:-P

Regards,

Dan
90a73d9875462aaa9fab2feffafbffe7?d=identicon&s=25 Ben Bleything (Guest)
on 2007-09-25 22:39
(Received via mailing list)
On Sun, Jan 14, 2007, Eric Hodel 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 :P

Ben
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2007-09-25 22:39
(Received via mailing list)
On Jan 15, 2007, at 02:59, Giles Bowkett 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 Hodel - drbrain@segment7.net - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!
6076c22b65b36f5d75c30bdcfb2fda85?d=identicon&s=25 Ezra Zygmuntowicz (Guest)
on 2007-09-25 22:39
(Received via mailing list)
On Jan 14, 2007, at 10:50 AM, Tom Copeland 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 Zygmuntowicz
-- Lead Rails Evangelist
-- ez@engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)
82e62c756d89bc6fa0a0a2d7f2b1e617?d=identicon&s=25 Ross Bamford (Guest)
on 2007-09-25 22:40
(Received via mailing list)
On Sun, 14 Jan 2007 08:44:25 -0000, Ryan Davis
<ryand-ruby@zenspider.com>
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.
560c83ff6b6600e39315a1cf75b7c229?d=identicon&s=25 Tom Copeland (Guest)
on 2007-09-25 22:41
(Received via mailing list)
> > 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
7359ed44852399295c6247dd9719b81b?d=identicon&s=25 Ola Bini (Guest)
on 2007-09-25 22:42
(Received via mailing list)
_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 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.
6076c22b65b36f5d75c30bdcfb2fda85?d=identicon&s=25 Ezra Zygmuntowicz (Guest)
on 2007-09-25 22:43
(Received via mailing list)
On Jan 15, 2007, at 11:28 PM, Ryan Davis 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 Zygmuntowicz
-- Lead Rails Evangelist
-- ez@engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)
82e62c756d89bc6fa0a0a2d7f2b1e617?d=identicon&s=25 Ross Bamford (Guest)
on 2007-09-25 22:43
(Received via mailing list)
On Sun, 14 Jan 2007 11:59:35 -0000, Eric Hodel <drbrain@segment7.net>
wrote:

> On Jan 14, 2007, at 03:20, Ross Bamford 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 Copeland should probably hear about it.
>
> He's been notified, but he's asleep.
>

Ahh, well, fair enough...

Thanks,
3bb23e7770680ea44a2d79e6d10daaed?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2007-09-25 22:43
(Received via mailing list)
Daniel Berger wrote:
>
> WTF? The "foo" project is MY project! What do you think you're doing?!
>
> A clear cut case of foo poisoning.
>
> :-P
>
> Regards,
>
> Dan
>
Well ... at least it was just "foo" and not "foobar", where "bar" is
defined as "beyond all repair".

:)

--
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.
5a837592409354297424994e8d62f722?d=identicon&s=25 Ryan Davis (Guest)
on 2007-09-25 22:43
(Received via mailing list)
On Jan 15, 2007, at 8:47 PM, Ezra Zygmuntowicz wrote:

>   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.
334805ec86cb3fe1ac2eda776a921fb2?d=identicon&s=25 Brad Ediger (Guest)
on 2007-09-25 22:43
(Received via mailing list)
On Jan 15, 2007, at 7:09 AM, Tom Copeland 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/).
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2007-09-25 22:44
(Received via mailing list)
On 1/14/07, Chris Carter <cdcarter@gmail.com> wrote:
>
> I want to apologize ...
>

<snip>

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


<snip>

Cheers
Robert
5a837592409354297424994e8d62f722?d=identicon&s=25 Ryan Davis (Guest)
on 2007-09-25 22:44
(Received via mailing list)
On Jan 17, 2007, at 6:44 AM, Tom Copeland 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)
560c83ff6b6600e39315a1cf75b7c229?d=identicon&s=25 Tom Copeland (Guest)
on 2007-09-25 22:44
(Received via mailing list)
On Thu, 2007-01-18 at 11:05 +0900, Paul Duncan wrote:
> * SonOfLilit (sonoflilit@gmail.com) 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
560c83ff6b6600e39315a1cf75b7c229?d=identicon&s=25 Tom Copeland (Guest)
on 2007-09-25 22:46
(Received via mailing list)
On Mon, 2007-01-15 at 19:59 +0900, Giles Bowkett 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.

>  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
0276239ca57aee241d4b41379587fa20?d=identicon&s=25 Lyle Johnson (Guest)
on 2007-09-25 22:46
(Received via mailing list)
On 1/17/07, Tom Copeland <tom@infoether.com> wrote:

> 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.)
560c83ff6b6600e39315a1cf75b7c229?d=identicon&s=25 Tom Copeland (Guest)
on 2007-09-25 22:46
(Received via mailing list)
On Sun, 2007-01-14 at 20:59 +0900, Eric Hodel 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.

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
Bb71d4877b2f770208509ea5933eaaac?d=identicon&s=25 Michael Steinfeld (Guest)
on 2007-09-25 22:47
(Received via mailing list)
I agree with John, your honesty and integrity should be noted. Don't pay
attention the squawks, they were just scared people, and some people
talk
with a bullhorn for no other reason other than because they own one.

Mike
560c83ff6b6600e39315a1cf75b7c229?d=identicon&s=25 Tom Copeland (Guest)
on 2007-09-25 22:47
(Received via mailing list)
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.

Yours,

Tom
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2007-09-25 22:49
(Received via mailing list)
On 1/17/07, Steven Lumos <steven@lumos.us> wrote:
> > They assumed much worse than it was but still they have lots of trouble
>
> Steve


Steve
I meant everybody  involved has my respect, not that everybody has done
the
same as Chris.
Cheers
Robert
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2007-09-25 22:49
(Received via mailing list)
I just wanted to say that by admiring Chris' courage I do not agree too
much
that Ryan and Eric were rude - well they were but who would not have
been?
Ok Ryan languages stunk, but he definitely needed to get that out, he
must
have felt very bad!
They assumed much worse than it was but still they have lots of trouble
ahead.
As Chris they have my respect too.

Well everybody has :)

Cheers
Robert
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2007-09-25 22:49
(Received via mailing list)
On 1/14/07, Ross Bamford <rosco@roscopeco.remove.co.uk> wrote:

> 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.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2007-09-25 22:49
(Received via mailing list)
On 1/14/07, Ola Bini <ola.bini@ki.se> wrote:

> 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.
560c83ff6b6600e39315a1cf75b7c229?d=identicon&s=25 Tom Copeland (Guest)
on 2007-09-25 22:49
(Received via mailing list)
On Tue, 2007-01-16 at 17:28 +0900, Ezra Zygmuntowicz wrote:
>   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
Ce8b03e5750097942c58e12b46724312?d=identicon&s=25 Giles Bowkett (Guest)
on 2007-09-25 22:51
(Received via mailing list)
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?
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2007-09-25 22:51
(Received via mailing list)
On 1/14/07, SonOfLilit <sonoflilit@gmail.com> wrote:
> 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.
Df5e7adb20adae6c120b04e7cafb15a0?d=identicon&s=25 Rob Sanheim (rsanheim)
on 2007-09-25 22:52
(Received via mailing list)
On 1/14/07, _why <why@ruby-lang.org> wrote:
>
> _why

_why for the win.
7b4707f974af261f71943e1f2046c9ee?d=identicon&s=25 SonOfLilit (Guest)
on 2007-09-25 22:52
(Received via mailing list)
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.
This topic is locked and can not be replied to.