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
···
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.
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?
Steve
I meant everybody involved has my respect, not that everybody has done the
same as Chris.
Cheers
Robert
···
On 1/17/07, Steven Lumos <steven@lumos.us> wrote:
"Robert Dober" <robert.dober@gmail.com> writes:
> 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.
Steve
--
"The best way to predict the future is to invent it."
- Alan Kay
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)
···
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.
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.
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.
> 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?
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.
> 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.
> 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.
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.
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
···
On Mon, 2007-01-15 at 21:42 +0900, Stephan Mueller wrote:
* 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.
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 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.
On Mon, 2007-01-15 at 21:42 +0900, Stephan Mueller wrote:
* 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.
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.
> 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...
