On Jan 15, 2007, at 8:47 PM, Ezra Z. 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.
On 1/17/07, Tom C. [email protected] 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.)
On Mon, 2007-01-15 at 19:59 +0900, Giles B. 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
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
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
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.
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
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
On 1/14/07, Ross B. [email protected] 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’.
It does need to be dealt with.
On 1/14/07, Ola B. [email protected] 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.
On Tue, 2007-01-16 at 17:28 +0900, Ezra Z. wrote:
Yeah I’m fine with waiting on releases to get this fixed myself.
Just wondering is all.
Yup, sorry for the delay. Eric H. and Paul D. had some good
suggestions yesterday for fixing this and I need to get cracking on
those…
Yours,
Tom
On 1/17/07, Steven L. [email protected] 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
On 1/14/07, SonOfLilit [email protected] 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.
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?
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 forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs