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,
···
On Sun, 14 Jan 2007 11:59:35 -0000, Eric Hodel <drbrain@segment7.net> 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.
···
On 1/14/07, Gregory Brown <gregory.t.brown@gmail.com> wrote:
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.
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
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
···
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.
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
···
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.
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
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...
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 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
···
--
"The best way to predict the future is to invent it."
- Alan Kay
> 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
···
On Thu, 2007-01-18 at 11:05 +0900, Paul Duncan wrote:
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.
···
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?
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.
···
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.
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?!
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?
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.
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
A lot of people wouldn't have done that. Anyone who was surprised by
the reaction should refer to the archives for this 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.
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
···
On Sun, 2007-01-14 at 13:50 -0500, Tom Copeland wrote:
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.
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
···
On Mon, 2007-01-15 at 19:59 +0900, Giles Bowkett wrote:
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.
···
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?
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.
···
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.
