[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Hoe poisoned in Rubyforge

Eric Hodel

1/14/2007 8:31:00 AM

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

I LIT YOUR GEM ON FIRE!
40 Answers

Ryan Davis

1/14/2007 8:44:00 AM

0


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.

Eric Hodel

1/14/2007 8:45:00 AM

0

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

and install it by hand:

gem install hoe

To work around the infinite dependency loop.

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

YOU LIT MY GEM ON FIRE!

Ross Bamford

1/14/2007 11:19:00 AM

0

On Sun, 14 Jan 2007 08:44:25 -0000, Ryan Davis <ryand-ruby@zenspider.com>
wrote:

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

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.

--
Ross Bamford - rosco@roscopeco.remove.co.uk

Eric Hodel

1/14/2007 12:00:00 PM

0

On Jan 14, 2007, at 03:20, Ross Bamford wrote:
> On Sun, 14 Jan 2007 08:44:25 -0000, Ryan Davis <ryand-
> ruby@zenspider.com> wrote:
>> 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.
>
> 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.se...

YOU LIT MY GEM ON FIRE!

Ross Bamford

1/14/2007 2:39:00 PM

0

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,
--
Ross Bamford - rosco@roscopeco.remove.co.uk

Gregory Brown

1/14/2007 3:42:00 PM

0

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.

Chris Carter

1/14/2007 3:42:00 PM

0

On 1/14/07, Eric Hodel <drbrain@segment7.net> 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.
>
> --
> Eric Hodel - drbrain@segment7.net - http://blog.se...
>
> 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.

--
Chris Carter
concentrationstudios.com
brynmawrcs.com

Gregory Brown

1/14/2007 3:53:00 PM

0

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.

Gregory Brown

1/14/2007 4:04:00 PM

0

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.

Gregory Brown

1/14/2007 4:23:00 PM

0

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.