From tilman at code-monkey.de  Wed Aug  9 12:56:08 2006
From: tilman at code-monkey.de (Tilman Sauerbeck)
Date: Wed, 9 Aug 2006 18:56:08 +0200
Subject: [Rubygems-developers] RubyGems 0.9.0 introduces bug for
	installing source Gems
In-Reply-To: <20060709175258.GA29076@code-monkey.de>
References: <d4cf71b00607051350n52ae90baw2edc404585810bdd@mail.gmail.com>
	<20060709085935.GA4674@code-monkey.de>
	<d4cf71b00607090647n504f4fecw523e734d3c46791@mail.gmail.com>
	<20060709175258.GA29076@code-monkey.de>
Message-ID: <20060809165607.GB14422@code-monkey.de>

Tilman Sauerbeck [2006-07-09 19:53]:
> Lyle Johnson [2006-07-09 08:47]:
> > On 7/9/06, Tilman Sauerbeck <tilman at code-monkey.de> wrote:
> > 
> > > Blame me.
> > 
> > I wasn't looking to assign blame. ;)
> > 
> > I just wanted to get it out there so that the problem can be addressed
> > in the next release of RubyGems. The stuff related to source gems
> > doesn't seem to get exercised as much as the stuff for "pure Ruby"
> > gems, and so problems like this one are easy to overlook.
> 
> Damn! I posted my final extension-stuff patch for Rubygems in
> 20050925081121.GA5808 at code-monkey.de, but it seems that Chad applied a
> patch that I posted earlier.
> I assumed he committed the right one, but didn't verify :(
> 
> Here's a patch that contains the bits that have been missed back then.
> I also backed out the "clean" chunk for ExtConfBuilder.
> I only tested it briefly, I haven't looked at this code in months and
> I'm not sure it's 100% correct.
> 
> See the mail I referenced above for comments on these changes.

Does nobody think this issue is important enough to actually do
something about it (like, applying a patch and rolling 0.9.1)!?
:(

Regards,
Tilman

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20060809/88f09fa6/attachment.bin 

From jim at weirichhouse.org  Thu Aug 10 14:27:42 2006
From: jim at weirichhouse.org (Jim Weirich)
Date: Thu, 10 Aug 2006 14:27:42 -0400
Subject: [Rubygems-developers] RubyGems 0.9.0 introduces bug
 for	installing source Gems
In-Reply-To: <20060809165607.GB14422@code-monkey.de>
References: <d4cf71b00607051350n52ae90baw2edc404585810bdd@mail.gmail.com>	<20060709085935.GA4674@code-monkey.de>	<d4cf71b00607090647n504f4fecw523e734d3c46791@mail.gmail.com>	<20060709175258.GA29076@code-monkey.de>
	<20060809165607.GB14422@code-monkey.de>
Message-ID: <44DB7A9E.5060007@weirichhouse.org>

Tilman Sauerbeck wrote:
> Does nobody think this issue is important enough to actually do
> something about it (like, applying a patch and rolling 0.9.1)!?

Sorry, sometimes I need a swift kick to get things rolling.

Ok, here's what I did.

The RubyGems repository is now converted from CVS to SubVersion.  So use 
svn to pull out head.

Here are the current changes:

(1) index_gem_repository has an untested workaround for the non-ASCII 
issue in gem fields.  I'm sending a copy of the workaround to Tom to see 
if it fixes the problems they are having on RubyForge.

(2) I've included Tilman's patch to the ext lib building.  Tilman, would 
you please check to make sure it is ok.  Thanks.

(3) In package.rb, I've changed the zlib stream workaround to include 
version 1.2.1 of zlib, since at least on person has encountered the 
problem on 1.2.1.  Does anyone know if this is the problem that the 
Rails folks were having with one of their gems in this past security 
release?

Thanks for your patience.

-- Jim Weirich

From jim at weirichhouse.org  Thu Aug 10 15:52:50 2006
From: jim at weirichhouse.org (Jim Weirich)
Date: Thu, 10 Aug 2006 15:52:50 -0400
Subject: [Rubygems-developers] RubyGems 0.9.0 introduces bug
 for	installing source Gems
In-Reply-To: <44DB7A9E.5060007@weirichhouse.org>
References: <d4cf71b00607051350n52ae90baw2edc404585810bdd@mail.gmail.com>	<20060709085935.GA4674@code-monkey.de>	<d4cf71b00607090647n504f4fecw523e734d3c46791@mail.gmail.com>	<20060709175258.GA29076@code-monkey.de>	<20060809165607.GB14422@code-monkey.de>
	<44DB7A9E.5060007@weirichhouse.org>
Message-ID: <44DB8E92.6010301@weirichhouse.org>

Jim Weirich wrote:
...
> (3) In package.rb, I've changed the zlib stream workaround to include 
> version 1.2.1 of zlib, since at least on person has encountered the 
> problem on 1.2.1.  Does anyone know if this is the problem that the 
> Rails folks were having with one of their gems in this past security 
> release?
...

Seriously, two minutes after I sent this email, who but DHH pops up in 
IM and points out this problem.  He confirms this was the problem they 
saw with their rails gem.

-- Jim Weirich

From tilman at code-monkey.de  Fri Aug 11 12:53:23 2006
From: tilman at code-monkey.de (Tilman Sauerbeck)
Date: Fri, 11 Aug 2006 18:53:23 +0200
Subject: [Rubygems-developers] RubyGems 0.9.0 introduces bug
	for	installing source Gems
In-Reply-To: <44DB7A9E.5060007@weirichhouse.org>
References: <d4cf71b00607051350n52ae90baw2edc404585810bdd@mail.gmail.com>
	<20060709085935.GA4674@code-monkey.de>
	<d4cf71b00607090647n504f4fecw523e734d3c46791@mail.gmail.com>
	<20060709175258.GA29076@code-monkey.de>
	<20060809165607.GB14422@code-monkey.de>
	<44DB7A9E.5060007@weirichhouse.org>
Message-ID: <20060811165322.GA11826@code-monkey.de>

Jim Weirich [2006-08-10 14:27]:
> Tilman Sauerbeck wrote:
> > Does nobody think this issue is important enough to actually do
> > something about it (like, applying a patch and rolling 0.9.1)!?
> 
> [...]
>
> (2) I've included Tilman's patch to the ext lib building.  Tilman, would 
> you please check to make sure it is ok.  Thanks.

I tested the ExtConf builder with the imlib2-ruby gem, and it's okay.
My Rake-based gem builds fine, too.

I didn't exercise the new Configure builder, but as it's mostly based on
the ExtConf one (or the other way round, too lazy to check right now) I
assume it will work, too.

For the next rubygems release after this one, I'd like to be able to
remove object files from the gem directory. Also, some gems might have
two copies of the shared object around right now (one in the build
directory, one in the destination directory).
But that doesn't need to be fixed in this release IMO.

Regards,
Tilman

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20060811/116c22df/attachment.bin 

From ahlist at gmail.com  Tue Aug 22 00:07:14 2006
From: ahlist at gmail.com (hbeaumont hbeaumont)
Date: Tue, 22 Aug 2006 00:07:14 -0400
Subject: [Rubygems-developers] replicating gem installs
Message-ID: <bc5becf60608212107h58e89c3fl3485c068a375bd8f@mail.gmail.com>

Hi,

Please point me to the correct list if this is off-topic.

I need to replicate my installed gems across several machines. I am
trying to find the best way to do this.

I had considered rsyncing /usr/local/lib/ruby

but many gems also install things into /usr/local/bin/ etc.

Is there a good way to do this?

I had considered a simple scripts of each install:

/bin/bash

gem install foo
gem install bar

etc.

but I really need something that will let me know 100% for sure that
everything is the same.

Is there an easy way to have a gem report what files it installed?

I suppose in the end I could open each gem setup files and find all
the install lines.

I just wanted to check the list first to see if there is a better or
standard way to do this.

Thanks.

From rubygems at freeze.org  Wed Aug 23 09:18:47 2006
From: rubygems at freeze.org (Jim Freeze)
Date: Wed, 23 Aug 2006 08:18:47 -0500
Subject: [Rubygems-developers] replicating gem installs
In-Reply-To: <bc5becf60608212107h58e89c3fl3485c068a375bd8f@mail.gmail.com>
References: <bc5becf60608212107h58e89c3fl3485c068a375bd8f@mail.gmail.com>
Message-ID: <D87DD72E-3C05-4415-AB86-388694A076E4@freeze.org>

Hi

I have the same need at work, but with the added requirement that the  
machines
are on different platforms (Linux, Sun and HP).

We use synchronicity to deploy files throughout the company.  
Synchronicity is
a version management system and replicator combined. I started out  
using this
method, but the pain is in managment of the gems and all their files  
which can
be somewhat scattered.

We haven't had a problem (that I know of) with gems putting files in / 
usr/local since
we install with the '-i' flag, but gems have the major downfall of  
putting explicit path
to ruby on the shebang line. This means I have to edit every gem that  
gets installed
that has an executable.

I am currently tinkering with the idea that instead of having  
Synchronicity manage
the gems, let rubygems manage the gems. So my method would entail  
maintaining
a list of gems and their versions. Then each location would install  
gems from the list
and, if needed, installed on multiple platforms. This way, each site  
can choose where
to put all these third party gems and I don't have to manage the  
headache of keeping
the revision control system cleaned up.

The only inhibitor to launching this scheme is the machine specific  
shebang path.
I guess I need to just find the time and submit a patch.

Jim

On Aug 21, 2006, at 11:07 PM, hbeaumont hbeaumont wrote:

> Hi,
>
> Please point me to the correct list if this is off-topic.
>
> I need to replicate my installed gems across several machines. I am
> trying to find the best way to do this.
>
> I had considered rsyncing /usr/local/lib/ruby
>
> but many gems also install things into /usr/local/bin/ etc.
>
> Is there a good way to do this?
>
> I had considered a simple scripts of each install:
>
> /bin/bash
>
> gem install foo
> gem install bar
>
> etc.
>
> but I really need something that will let me know 100% for sure that
> everything is the same.
>
> Is there an easy way to have a gem report what files it installed?
>
> I suppose in the end I could open each gem setup files and find all
> the install lines.
>
> I just wanted to check the list first to see if there is a better or
> standard way to do this.
>
> Thanks.
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers

Jim Freeze



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20060823/a4d6a9ae/attachment.html 

From jim at weirichhouse.org  Wed Aug 23 09:27:31 2006
From: jim at weirichhouse.org (Jim Weirich)
Date: Wed, 23 Aug 2006 09:27:31 -0400
Subject: [Rubygems-developers] replicating gem installs
In-Reply-To: <D87DD72E-3C05-4415-AB86-388694A076E4@freeze.org>
References: <bc5becf60608212107h58e89c3fl3485c068a375bd8f@mail.gmail.com>
	<D87DD72E-3C05-4415-AB86-388694A076E4@freeze.org>
Message-ID: <44EC57C3.7070407@weirichhouse.org>

Jim Freeze wrote:
> The only inhibitor to launching this scheme is the machine specific 
> shebang path.
> I guess I need to just find the time and submit a patch.

We would welcome such a patch.  IIRC, the shebang stuff is fairly 
localized, so it wouldn't be hard.

Off the top of my head, I think I would like to keep the current 
behavior by default and enable the new behavior with a command line 
switch, but that is open for discussion.

-- Jim Weirich

From anthonyeden at gmail.com  Wed Aug 23 09:33:48 2006
From: anthonyeden at gmail.com (Anthony Eden)
Date: Wed, 23 Aug 2006 09:33:48 -0400
Subject: [Rubygems-developers] replicating gem installs
In-Reply-To: <D87DD72E-3C05-4415-AB86-388694A076E4@freeze.org>
References: <bc5becf60608212107h58e89c3fl3485c068a375bd8f@mail.gmail.com>
	<D87DD72E-3C05-4415-AB86-388694A076E4@freeze.org>
Message-ID: <bd41ed320608230633t4cae4dadn56438087232a4cd8@mail.gmail.com>

Just out of curiosity, why not use /usr/bin/env ruby or just put a symbolic
link on different machines. If they are all variations of unix either of
these approaches should work, no?

Now, if you throw Windows into the mix it is a bit more of a pain, but
doesn't Gems handle the windows/unix path variations already?

Sincerely,
Anthony Eden

On 8/23/06, Jim Freeze <rubygems at freeze.org> wrote:
>
> Hi
> I have the same need at work, but with the added requirement that the
> machines
> are on different platforms (Linux, Sun and HP).
>
> We use synchronicity to deploy files throughout the company. Synchronicity
> is
> a version management system and replicator combined. I started out using
> this
> method, but the pain is in managment of the gems and all their files which
> can
> be somewhat scattered.
>
> We haven't had a problem (that I know of) with gems putting files in
> /usr/local since
> we install with the '-i' flag, but gems have the major downfall of putting
> explicit path
> to ruby on the shebang line. This means I have to edit every gem that gets
> installed
> that has an executable.
>
> I am currently tinkering with the idea that instead of having
> Synchronicity manage
> the gems, let rubygems manage the gems. So my method would entail
> maintaining
> a list of gems and their versions. Then each location would install gems
> from the list
> and, if needed, installed on multiple platforms. This way, each site can
> choose where
> to put all these third party gems and I don't have to manage the headache
> of keeping
> the revision control system cleaned up.
>
> The only inhibitor to launching this scheme is the machine specific
> shebang path.
> I guess I need to just find the time and submit a patch.
>
> Jim
>
> On Aug 21, 2006, at 11:07 PM, hbeaumont hbeaumont wrote:
>
> Hi,
>
> Please point me to the correct list if this is off-topic.
>
> I need to replicate my installed gems across several machines. I am
> trying to find the best way to do this.
>
> I had considered rsyncing /usr/local/lib/ruby
>
> but many gems also install things into /usr/local/bin/ etc.
>
> Is there a good way to do this?
>
> I had considered a simple scripts of each install:
>
> /bin/bash
>
> gem install foo
> gem install bar
>
> etc.
>
> but I really need something that will let me know 100% for sure that
> everything is the same.
>
> Is there an easy way to have a gem report what files it installed?
>
> I suppose in the end I could open each gem setup files and find all
> the install lines.
>
> I just wanted to check the list first to see if there is a better or
> standard way to do this.
>
> Thanks.
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers
>
>
> Jim Freeze
>
>
>
>
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers
>
>


-- 
Camber Corporation Asia-Pacific Office
Email: aeden at camber.com
Cell: 808 782-5046
Current Location: Washington DC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20060823/46b52116/attachment.html 

From rubygems at freeze.org  Wed Aug 23 11:30:05 2006
From: rubygems at freeze.org (Jim Freeze)
Date: Wed, 23 Aug 2006 10:30:05 -0500
Subject: [Rubygems-developers] replicating gem installs
In-Reply-To: <bd41ed320608230633t4cae4dadn56438087232a4cd8@mail.gmail.com>
References: <bc5becf60608212107h58e89c3fl3485c068a375bd8f@mail.gmail.com>
	<D87DD72E-3C05-4415-AB86-388694A076E4@freeze.org>
	<bd41ed320608230633t4cae4dadn56438087232a4cd8@mail.gmail.com>
Message-ID: <5cd596d60608230830u3dfae215xec250767c23c1be@mail.gmail.com>

On 8/23/06, Anthony Eden <anthonyeden at gmail.com> wrote:
> Just out of curiosity, why not use /usr/bin/env ruby or just put a symbolic
> link on different machines. If they are all variations of unix either of
> these approaches should work, no?

I have seen gems which use flags on the shebang, which env
cannot understand on some platforms.

The symbolic link won't work for my particular purposes since
the gems are installed on a shared network drive.

I would propose that we have a command line option that
would change the shebang to '#!/usr/bin/env ruby', and
an option that let one set specifically the shebang.


-- 
Jim Freeze

From rubygems at freeze.org  Wed Aug 23 11:31:57 2006
From: rubygems at freeze.org (Jim Freeze)
Date: Wed, 23 Aug 2006 10:31:57 -0500
Subject: [Rubygems-developers] replicating gem installs
In-Reply-To: <44EC57C3.7070407@weirichhouse.org>
References: <bc5becf60608212107h58e89c3fl3485c068a375bd8f@mail.gmail.com>
	<D87DD72E-3C05-4415-AB86-388694A076E4@freeze.org>
	<44EC57C3.7070407@weirichhouse.org>
Message-ID: <5cd596d60608230831o62796629k45b0f5ded4f9f765@mail.gmail.com>

On 8/23/06, Jim Weirich <jim at weirichhouse.org> wrote:
> Jim Freeze wrote:
> > The only inhibitor to launching this scheme is the machine specific
> > shebang path.
> > I guess I need to just find the time and submit a patch.
>
> We would welcome such a patch.  IIRC, the shebang stuff is fairly
> localized, so it wouldn't be hard.
>
> Off the top of my head, I think I would like to keep the current
> behavior by default and enable the new behavior with a command line
> switch, but that is open for discussion.

Last time I looked at this, it appeared that the code I was looking
at was never executed. So I was not able to implement a patch.

I'll take another look. Where do I get the latest version of rugems
to patch against?


>
> -- Jim Weirich
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers
>


-- 
Jim Freeze

From jim.weirich at gmail.com  Wed Aug 23 11:35:01 2006
From: jim.weirich at gmail.com (Jim Weirich)
Date: Wed, 23 Aug 2006 11:35:01 -0400
Subject: [Rubygems-developers] replicating gem installs
In-Reply-To: <5cd596d60608230831o62796629k45b0f5ded4f9f765@mail.gmail.com>
References: <bc5becf60608212107h58e89c3fl3485c068a375bd8f@mail.gmail.com>
	<D87DD72E-3C05-4415-AB86-388694A076E4@freeze.org>
	<44EC57C3.7070407@weirichhouse.org>
	<5cd596d60608230831o62796629k45b0f5ded4f9f765@mail.gmail.com>
Message-ID: <d4dd9080608230835u5a55f5cdkb6bab4727af89266@mail.gmail.com>

On 8/23/06, Jim Freeze <rubygems at freeze.org> wrote:> I'll take another look.
Where do I get the latest version of rugems

> to patch against?



RubyForge SVN repository.

-- 
-- 
-- Jim Weirich    jim at weirichhouse.org     http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20060823/aeabb828/attachment.html 

From drbrain at segment7.net  Wed Aug 23 17:23:14 2006
From: drbrain at segment7.net (Eric Hodel)
Date: Wed, 23 Aug 2006 14:23:14 -0700
Subject: [Rubygems-developers] replicating gem installs
In-Reply-To: <bd41ed320608230633t4cae4dadn56438087232a4cd8@mail.gmail.com>
References: <bc5becf60608212107h58e89c3fl3485c068a375bd8f@mail.gmail.com>
	<D87DD72E-3C05-4415-AB86-388694A076E4@freeze.org>
	<bd41ed320608230633t4cae4dadn56438087232a4cd8@mail.gmail.com>
Message-ID: <CE8D3382-4FFD-4317-BB52-D2F03107FCA4@segment7.net>

On Aug 23, 2006, at 6:33 AM, Anthony Eden wrote:

> Just out of curiosity, why not use /usr/bin/env ruby or just put a  
> symbolic link on different machines. If they are all variations of  
> unix either of these approaches should work, no?

This won't work, cron does not set $PATH.

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

A: Yes
Q: Is top-posting bad?
  ? Derek Milhous Zumsteg



From ahlist at gmail.com  Wed Aug 23 20:34:40 2006
From: ahlist at gmail.com (hbeaumont hbeaumont)
Date: Wed, 23 Aug 2006 20:34:40 -0400
Subject: [Rubygems-developers] replicating gem installs
In-Reply-To: <CE8D3382-4FFD-4317-BB52-D2F03107FCA4@segment7.net>
References: <bc5becf60608212107h58e89c3fl3485c068a375bd8f@mail.gmail.com>
	<D87DD72E-3C05-4415-AB86-388694A076E4@freeze.org>
	<bd41ed320608230633t4cae4dadn56438087232a4cd8@mail.gmail.com>
	<CE8D3382-4FFD-4317-BB52-D2F03107FCA4@segment7.net>
Message-ID: <bc5becf60608231734m9bde27bk102b185e9c50abf9@mail.gmail.com>

On 8/23/06, Eric Hodel <drbrain at segment7.net> wrote:
> On Aug 23, 2006, at 6:33 AM, Anthony Eden wrote:
>
> > Just out of curiosity, why not use /usr/bin/env ruby or just put a
> > symbolic link on different machines. If they are all variations of
> > unix either of these approaches should work, no?
>
> This won't work, cron does not set $PATH.

speaking of which - does anyone know offhand how to make it set the
path for a whole server?

I know I can set it in the acutal crontab script but I would love to
be able to set a default for all crontabs. I get daily questions from
users whose crontab doesn't work because they aren't using the full
path.

From kirvesrinta at gmail.com  Wed Aug 23 23:00:42 2006
From: kirvesrinta at gmail.com (Marko Viitanen)
Date: Wed, 23 Aug 2006 21:00:42 -0600
Subject: [Rubygems-developers] Ruby on Rails trouble
Message-ID: <624fb4650608232000v65d2e8car58245d1a3360e43d@mail.gmail.com>

I decided to try Ruby and it has not been easy or simple. I am having
trouble with rubygems, installing rails.

After downloading and installing ruby, I downloaded
rubygems-0.9.0.zip<http://rubyforge.org/frs/download.php/11290/rubygems-0.9.0.zip>from
http://rubyforge.org/frs/?group_id=126. Unzipped it and ran
ruby setup.rb

then I tried

gem install rails --include-dependencies

It just hangs

I added the --debug flag, and saw that it was trying to use .gemsrc. now
where was that in the "getting started" instructions?

I made on up following a sample I found online.

Still didn't work. This time it is complaining about another file:
Exception `LoadError' at
c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27 - no such file
to load -- sources

I have no idea where that should be.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20060823/15b0206a/attachment.html 

From ryand-ruby at zenspider.com  Thu Aug 24 02:27:23 2006
From: ryand-ruby at zenspider.com (Ryan Davis)
Date: Wed, 23 Aug 2006 23:27:23 -0700
Subject: [Rubygems-developers] replicating gem installs
In-Reply-To: <bc5becf60608231734m9bde27bk102b185e9c50abf9@mail.gmail.com>
References: <bc5becf60608212107h58e89c3fl3485c068a375bd8f@mail.gmail.com>
	<D87DD72E-3C05-4415-AB86-388694A076E4@freeze.org>
	<bd41ed320608230633t4cae4dadn56438087232a4cd8@mail.gmail.com>
	<CE8D3382-4FFD-4317-BB52-D2F03107FCA4@segment7.net>
	<bc5becf60608231734m9bde27bk102b185e9c50abf9@mail.gmail.com>
Message-ID: <0233D83A-A740-4913-8E07-9BA5294BF656@zenspider.com>


On Aug 23, 2006, at 5:34 PM, hbeaumont hbeaumont wrote:

> speaking of which - does anyone know offhand how to make it set the
> path for a whole server?
>
> I know I can set it in the acutal crontab script but I would love to
> be able to set a default for all crontabs. I get daily questions from
> users whose crontab doesn't work because they aren't using the full
> path.

/etc/profile maybe? really depends on the shell...

I'd guess that you'd piss off as many people as you pleased by  
messing with the global paths. :/


From ryand-ruby at zenspider.com  Thu Aug 24 02:24:14 2006
From: ryand-ruby at zenspider.com (Ryan Davis)
Date: Wed, 23 Aug 2006 23:24:14 -0700
Subject: [Rubygems-developers] Ruby on Rails trouble
In-Reply-To: <624fb4650608232000v65d2e8car58245d1a3360e43d@mail.gmail.com>
References: <624fb4650608232000v65d2e8car58245d1a3360e43d@mail.gmail.com>
Message-ID: <B46A53B3-82AD-4D43-94CA-801995572FB7@zenspider.com>


On Aug 23, 2006, at 8:00 PM, Marko Viitanen wrote:

> I added the --debug flag, and saw that it was trying to  
> use .gemsrc. now where was that in the "getting started" instructions?

No need to get pissy. You don't need to do anything wrt .gemsrc

> Still didn't work. This time it is complaining about another file:
> Exception `LoadError' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/ 
> custom_require.rb:27 - no such file to load -- sources

that is a gem that gets installed at the end of the rubygems  
install... it basically means you didn't get a full/good install of  
rubygems.


From jim at weirichhouse.org  Thu Aug 24 07:24:47 2006
From: jim at weirichhouse.org (Jim Weirich)
Date: Thu, 24 Aug 2006 07:24:47 -0400
Subject: [Rubygems-developers] Ruby on Rails trouble
In-Reply-To: <624fb4650608232000v65d2e8car58245d1a3360e43d@mail.gmail.com>
References: <624fb4650608232000v65d2e8car58245d1a3360e43d@mail.gmail.com>
Message-ID: <44ED8C7F.1020302@weirichhouse.org>

Marko Viitanen wrote:
> I decided to try Ruby and it has not been easy or simple. I am having 
> trouble with rubygems, installing rails.
> 
> After downloading and installing ruby, I downloaded rubygems-0.9.0.zip 
> <http://rubyforge.org/frs/download.php/11290/rubygems-0.9.0.zip> from 
> http://rubyforge.org/frs/?group_id=126. Unzipped it and ran
> ruby setup.rb

You didn't mention your platform, but judging from the c: in the error 
message you gave, it looks like a windows install.  What version of Ruby 
are you using?  If you used the one-click installer for windows 
(recommended), then RubyGems comes pre-installed with that and you 
shouldn't have to install it separately.

> then I tried
> 
> gem install rails --include-dependencies
> 
> It just hangs

Hmmm ... Are you behind a firewall that requires you to use a proxy?  If 
so, you need to set the http_proxy environment variable to the proper 
value so the RubyGems will go to the proxy rather than direct to the gem 
download site.  If you are behind an authenticating proxy, then things 
get a bit trickier.

> I added the --debug flag, and saw that it was trying to use .gemsrc. now 
> where was that in the "getting started" instructions?

.gemsrc is just a configuration file that is used if found, otherwise 
ignored.  Its absence shouldn't cause any trouble.

> I made on up following a sample I found online.
> 
> Still didn't work. This time it is complaining about another file:
> Exception `LoadError' at 
> c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27 - no such 
> file to load -- sources

This means your RubyGems installation is probably garbled.  The sources 
gem is packaged with RubyGems and its absence is not good.  I recommend 
starting over with the one-click installer.

-- Jim Weirich

From rubygems at freeze.org  Thu Aug 24 08:05:16 2006
From: rubygems at freeze.org (Jim Freeze)
Date: Thu, 24 Aug 2006 07:05:16 -0500
Subject: [Rubygems-developers] replicating gem installs
In-Reply-To: <CE8D3382-4FFD-4317-BB52-D2F03107FCA4@segment7.net>
References: <bc5becf60608212107h58e89c3fl3485c068a375bd8f@mail.gmail.com>
	<D87DD72E-3C05-4415-AB86-388694A076E4@freeze.org>
	<bd41ed320608230633t4cae4dadn56438087232a4cd8@mail.gmail.com>
	<CE8D3382-4FFD-4317-BB52-D2F03107FCA4@segment7.net>
Message-ID: <1A4C55DD-006F-4B4F-9AA8-E08F54C56B8D@freeze.org>

On Aug 23, 2006, at 4:23 PM, Eric Hodel wrote:

> On Aug 23, 2006, at 6:33 AM, Anthony Eden wrote:
>
>> Just out of curiosity, why not use /usr/bin/env ruby or just put a
>> symbolic link on different machines. If they are all variations of
>> unix either of these approaches should work, no?
>
> This won't work, cron does not set $PATH.

Yeah, that's done in the shell script called by cron before exec'ing  
ruby. :)

>
> -- 
> Eric Hodel - drbrain at segment7.net - http://blog.segment7.net
>
> A: Yes
> Q: Is top-posting bad?
>   ? Derek Milhous Zumsteg
>
>
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers

Jim Freeze



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20060824/3fc70f42/attachment.html 

From rubygems at freeze.org  Thu Aug 24 08:07:38 2006
From: rubygems at freeze.org (Jim Freeze)
Date: Thu, 24 Aug 2006 07:07:38 -0500
Subject: [Rubygems-developers] replicating gem installs
In-Reply-To: <bc5becf60608231734m9bde27bk102b185e9c50abf9@mail.gmail.com>
References: <bc5becf60608212107h58e89c3fl3485c068a375bd8f@mail.gmail.com>
	<D87DD72E-3C05-4415-AB86-388694A076E4@freeze.org>
	<bd41ed320608230633t4cae4dadn56438087232a4cd8@mail.gmail.com>
	<CE8D3382-4FFD-4317-BB52-D2F03107FCA4@segment7.net>
	<bc5becf60608231734m9bde27bk102b185e9c50abf9@mail.gmail.com>
Message-ID: <3A40338A-7BD5-4BEB-809B-DA34CC50461C@freeze.org>

On Aug 23, 2006, at 7:34 PM, hbeaumont hbeaumont wrote:

>
> speaking of which - does anyone know offhand how to make it set the
> path for a whole server?

Depending upon the shell you are using, you can write csh scripts. csh
takes a flag that will load the users environment, thus setting their  
paths.

>
> I know I can set it in the acutal crontab script but I would love to
> be able to set a default for all crontabs. I get daily questions from
> users whose crontab doesn't work because they aren't using the full
> path.
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers

Jim Freeze



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20060824/a8dac038/attachment.html 

From pabs at pablotron.org  Thu Aug 31 03:44:11 2006
From: pabs at pablotron.org (Paul Duncan)
Date: Thu, 31 Aug 2006 03:44:11 -0400
Subject: [Rubygems-developers] [PATCH] RubyGems 0.9.0 Signing Updates
Message-ID: <20060831074411.GI27957@vault.home.pablotron.org>

Hi All,

Attached is a small patch against RubyGems 0.9.0 which adds the
following:

  * Ensures that the trust directory exists and is a directory
    before trying to add a certificate to the trust store.
  * Ensures that permissions on the trust directory and generated
    certificates and keys are sufficiently restrictive.

On the off-chance that this patch gets mangled in transit, it's also
available on the web at the following URL:

  http://pablotron.org/files/rubygems-0.9.0-signing_updates.diff

For the security-conscious among you, an OpenPGP signature of the
aforementioned patch can be found here:

  http://pablotron.org/files/rubygems-0.9.0-signing_updates.diff.asc

It's a relatively small set of changes. That said, questions, comments,
and unadulterated vitriol are always appreciated. :)

-- 
Paul Duncan <pabs at pablotron.org>        OpenPGP Key ID: 0x82C29562
http://www.pablotron.org/               http://www.paulduncan.org/
-------------- next part --------------
diff -ur rubygems-0.9.0/lib/rubygems/security.rb rubygems-0.9.0-fix_add_cert/lib/rubygems/security.rb
--- rubygems-0.9.0/lib/rubygems/security.rb	2006-06-06 23:39:54.000000000 -0400
+++ rubygems-0.9.0-fix_add_cert/lib/rubygems/security.rb	2006-08-31 03:17:32.000000000 -0400
@@ -95,6 +95,14 @@
 
       # output directory for trusted certificate checksums
       :trust_dir => File::join(Gem.user_home, '.gem', 'trust'),
+
+      # default permissions for trust directory and certs
+      :perms => {
+        :trust_dir      => 0700,
+        :trusted_cert   => 0600,
+        :signing_cert   => 0600,
+        :signing_key    => 0600,
+      },
     }
 
     #
@@ -342,6 +350,32 @@
     end
     
     #
+    # Make sure the trust directory exists.  If it does exist, make sure
+    # it's actually a directory.  If not, then create it with the
+    # appropriate permissions.
+    #
+    def self.verify_trust_dir(opt)
+      # grab path from options
+      path = opt[:trust_dir]
+
+      # if the directory exists, then make sure it is in fact a
+      # directory.  if it doesn't exist, then create it with the
+      # appropriate permissions
+      if File.exists?(path)
+        # verify that the trust directory is actually a directory
+        unless File.directory?(path)
+          err = "trust directory #{path} isn't a directory"
+          raise Gem::Security::Exception, err
+        end
+      else
+        # trust directory doesn't exist, so create it with 
+        # permissions
+        FileUtils.mkdir_p(path)
+        FileUtils.chmod(opt[:perms][:trust_dir], path)
+      end
+    end
+
+    #
     # Build a certificate from the given DN and private key.
     # 
     def self.build_cert(name, key, opt = {})
@@ -394,13 +428,16 @@
       # build private key
       key = opt[:key_algo].new(opt[:key_size])
 
-      # create the trust directory if it doesn't exist
-      FileUtils::mkdir_p(opt[:trust_dir]) unless File.exists?(opt[:trust_dir])
+      # method name pretty much says it all :)
+      verify_trust_dir(opt)
 
       # if we're saving the key, then write it out
       if opt[:save_key]
         path[:key] = opt[:save_key_path] || (opt[:output_fmt] % 'private_key')
-        File.open(path[:key], 'wb') { |file| file.write(key.to_pem) }
+        File.open(path[:key], 'wb') do |file| 
+          file.chmod(opt[:perms][:signing_key])
+          file.write(key.to_pem) 
+        end
       end
       
       # build self-signed public cert from key
@@ -409,7 +446,10 @@
       # if we're saving the cert, then write it out
       if opt[:save_cert]
         path[:cert] = opt[:save_cert_path] || (opt[:output_fmt] % 'public_cert')
-        File.open(path[:cert], 'wb') { |file| file.write(cert.to_pem) }
+        File.open(path[:cert], 'wb') do |file| 
+          file.chmod(opt[:perms][:signing_cert])
+          file.write(cert.to_pem)
+        end
       end
 
       # return key, cert, and paths (if applicable)
@@ -429,8 +469,14 @@
       # get destination path 
       path = Gem::Security::Policy.trusted_cert_path(cert, opt)
 
+      # verify trust directory (can't write to nowhere, you know)
+      verify_trust_dir(opt)
+
       # write cert to output file
-      File.open(path, 'wb') { |file| file.write(cert.to_pem) }
+      File.open(path, 'wb') do |file| 
+        file.chmod(opt[:perms][:trusted_cert])
+        file.write(cert.to_pem)
+      end
 
       # return nil
       nil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20060831/3ff112a2/attachment.bin 

From drbrain at segment7.net  Thu Aug 31 13:42:50 2006
From: drbrain at segment7.net (Eric Hodel)
Date: Thu, 31 Aug 2006 10:42:50 -0700
Subject: [Rubygems-developers] [PATCH] RubyGems 0.9.0 Signing Updates
In-Reply-To: <20060831074411.GI27957@vault.home.pablotron.org>
References: <20060831074411.GI27957@vault.home.pablotron.org>
Message-ID: <35C49AB0-7797-43F7-87D8-2D150C9DC3B8@segment7.net>


On Aug 31, 2006, at 12:44 AM, Paul Duncan wrote:

> Hi All,
>
> Attached is a small patch against RubyGems 0.9.0 which adds the
> following:
>
>   * Ensures that the trust directory exists and is a directory
>     before trying to add a certificate to the trust store.
>   * Ensures that permissions on the trust directory and generated
>     certificates and keys are sufficiently restrictive.
>
> On the off-chance that this patch gets mangled in transit, it's also
> available on the web at the following URL:
>
>   http://pablotron.org/files/rubygems-0.9.0-signing_updates.diff
>
> For the security-conscious among you, an OpenPGP signature of the
> aforementioned patch can be found here:
>
>   http://pablotron.org/files/rubygems-0.9.0-signing_updates.diff.asc
>
> It's a relatively small set of changes. That said, questions,  
> comments,
> and unadulterated vitriol are always appreciated. :)
>
> diff -ur rubygems-0.9.0/lib/rubygems/security.rb rubygems-0.9.0- 
> fix_add_cert/lib/rubygems/security.rb
> --- rubygems-0.9.0/lib/rubygems/security.rb	2006-06-06  
> 23:39:54.000000000 -0400
> +++ rubygems-0.9.0-fix_add_cert/lib/rubygems/security.rb	2006-08-31  
> 03:17:32.000000000 -0400
> @@ -342,6 +350,32 @@
>      end
>
>      #
> +    # Make sure the trust directory exists.  If it does exist,  
> make sure
> +    # it's actually a directory.  If not, then create it with the
> +    # appropriate permissions.
> +    #
> +    def self.verify_trust_dir(opt)
> +      # grab path from options
> +      path = opt[:trust_dir]

opt[:trust_dir]

> +
> +      # if the directory exists, then make sure it is in fact a
> +      # directory.  if it doesn't exist, then create it with the
> +      # appropriate permissions
> +      if File.exists?(path)

File.exists? is deprecated, use File.exist.

> +        # verify that the trust directory is actually a directory
> +        unless File.directory?(path)
> +          err = "trust directory #{path} isn't a directory"
> +          raise Gem::Security::Exception, err
> +        end
> +      else
> +        # trust directory doesn't exist, so create it with
> +        # permissions
> +        FileUtils.mkdir_p(path)
> +        FileUtils.chmod(opt[:perms][:trust_dir], path)

and opt[:perms][:trust_dir] are the only things in opt you use here,  
why not make them explicit arguments?

> +      end
> +    end
> +
> +    #
>      # Build a certificate from the given DN and private key.
>      #
>      def self.build_cert(name, key, opt = {})
> @@ -429,8 +469,14 @@
>        # get destination path
>        path = Gem::Security::Policy.trusted_cert_path(cert, opt)
>
> +      # verify trust directory (can't write to nowhere, you know)
> +      verify_trust_dir(opt)
> +
>        # write cert to output file
> -      File.open(path, 'wb') { |file| file.write(cert.to_pem) }
> +      File.open(path, 'wb') do |file|
> +        file.chmod(opt[:perms][:trusted_cert])
> +        file.write(cert.to_pem)
> +      end
>
>        # return nil
>        nil


-- 
Eric Hodel - drbrain at segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com



From pabs at pablotron.org  Thu Aug 31 15:19:03 2006
From: pabs at pablotron.org (Paul Duncan)
Date: Thu, 31 Aug 2006 15:19:03 -0400
Subject: [Rubygems-developers] [PATCH] RubyGems 0.9.0 Signing Updates
In-Reply-To: <35C49AB0-7797-43F7-87D8-2D150C9DC3B8@segment7.net>
References: <20060831074411.GI27957@vault.home.pablotron.org>
	<35C49AB0-7797-43F7-87D8-2D150C9DC3B8@segment7.net>
Message-ID: <20060831191903.GK27957@vault.home.pablotron.org>

* Eric Hodel (drbrain at segment7.net) wrote:
[snipped]
> File.exists? is deprecated, use File.exist.

You sir, are correct.  

[snipped]
> and opt[:perms][:trust_dir] are the only things in opt you use here,  
> why not make them explicit arguments?

I did it that way for consistency with the other calls.  That said, I
see the advantage of the approach you're suggesting: without a fancy
hash of options, the method is usable elsewhere.

I've updated the patch with both suggested changes.  The new patch is
attached.  It's also available online at the following URLs:

  http://pablotron.org/files/rubygems-0.9.0-signing_updates-2.diff
  http://pablotron.org/files/rubygems-0.9.0-signing_updates-2.diff.asc

Thanks!

> -- 
> Eric Hodel - drbrain at segment7.net - http://blog.segment7.net
> This implementation is HODEL-HASH-9600 compliant

-- 
Paul Duncan <pabs at pablotron.org>        OpenPGP Key ID: 0x82C29562
http://www.pablotron.org/               http://www.paulduncan.org/
-------------- next part --------------
diff -ur rubygems-0.9.0/lib/rubygems/package.rb rubygems-0.9.0-fix_add_cert/lib/rubygems/package.rb
--- rubygems-0.9.0/lib/rubygems/package.rb	2006-06-13 23:39:45.000000000 -0400
+++ rubygems-0.9.0-fix_add_cert/lib/rubygems/package.rb	2006-08-31 14:58:01.000000000 -0400
@@ -525,7 +525,7 @@
             if Gem::Security.constants.index(security_policy)
               # load one of the pre-defined security policies
               security_policy = Gem::Security.const_get(security_policy)
-            elsif File.exists?(security_policy)
+            elsif File.exist?(security_policy)
               # FIXME: this doesn't work yet
               security_policy = YAML::load(File.read(security_policy))
             else
diff -ur rubygems-0.9.0/lib/rubygems/security.rb rubygems-0.9.0-fix_add_cert/lib/rubygems/security.rb
--- rubygems-0.9.0/lib/rubygems/security.rb	2006-06-06 23:39:54.000000000 -0400
+++ rubygems-0.9.0-fix_add_cert/lib/rubygems/security.rb	2006-08-31 14:57:37.000000000 -0400
@@ -95,6 +95,14 @@
 
       # output directory for trusted certificate checksums
       :trust_dir => File::join(Gem.user_home, '.gem', 'trust'),
+
+      # default permissions for trust directory and certs
+      :perms => {
+        :trust_dir      => 0700,
+        :trusted_cert   => 0600,
+        :signing_cert   => 0600,
+        :signing_key    => 0600,
+      },
     }
 
     #
@@ -216,7 +224,7 @@
                 'Untrusted Signing Chain Root',
                 root.subject.to_s,
                 "path \"#{path}\" does not exist",
-              ] unless File.exists?(path)
+              ] unless File.exist?(path)
 
               # load calculate digest from saved cert file
               save_cert = OpenSSL::X509::Certificate.new(File.read(path))
@@ -342,6 +350,29 @@
     end
     
     #
+    # Make sure the trust directory exists.  If it does exist, make sure
+    # it's actually a directory.  If not, then create it with the
+    # appropriate permissions.
+    #
+    def self.verify_trust_dir(path, perms)
+      # if the directory exists, then make sure it is in fact a
+      # directory.  if it doesn't exist, then create it with the
+      # appropriate permissions
+      if File.exist?(path)
+        # verify that the trust directory is actually a directory
+        unless File.directory?(path)
+          err = "trust directory #{path} isn't a directory"
+          raise Gem::Security::Exception, err
+        end
+      else
+        # trust directory doesn't exist, so create it with 
+        # permissions
+        FileUtils.mkdir_p(path)
+        FileUtils.chmod(perms, path)
+      end
+    end
+
+    #
     # Build a certificate from the given DN and private key.
     # 
     def self.build_cert(name, key, opt = {})
@@ -394,13 +425,16 @@
       # build private key
       key = opt[:key_algo].new(opt[:key_size])
 
-      # create the trust directory if it doesn't exist
-      FileUtils::mkdir_p(opt[:trust_dir]) unless File.exists?(opt[:trust_dir])
+      # method name pretty much says it all :)
+      verify_trust_dir(opt[:trust_dir], opt[:perms][:trust_dir])
 
       # if we're saving the key, then write it out
       if opt[:save_key]
         path[:key] = opt[:save_key_path] || (opt[:output_fmt] % 'private_key')
-        File.open(path[:key], 'wb') { |file| file.write(key.to_pem) }
+        File.open(path[:key], 'wb') do |file| 
+          file.chmod(opt[:perms][:signing_key])
+          file.write(key.to_pem) 
+        end
       end
       
       # build self-signed public cert from key
@@ -409,7 +443,10 @@
       # if we're saving the cert, then write it out
       if opt[:save_cert]
         path[:cert] = opt[:save_cert_path] || (opt[:output_fmt] % 'public_cert')
-        File.open(path[:cert], 'wb') { |file| file.write(cert.to_pem) }
+        File.open(path[:cert], 'wb') do |file| 
+          file.chmod(opt[:perms][:signing_cert])
+          file.write(cert.to_pem)
+        end
       end
 
       # return key, cert, and paths (if applicable)
@@ -429,8 +466,14 @@
       # get destination path 
       path = Gem::Security::Policy.trusted_cert_path(cert, opt)
 
+      # verify trust directory (can't write to nowhere, you know)
+      verify_trust_dir(opt[:trust_dir], opt[:perms][:trust_dir])
+
       # write cert to output file
-      File.open(path, 'wb') { |file| file.write(cert.to_pem) }
+      File.open(path, 'wb') do |file| 
+        file.chmod(opt[:perms][:trusted_cert])
+        file.write(cert.to_pem)
+      end
 
       # return nil
       nil
@@ -460,7 +503,7 @@
             # convert it into a cert object, and if it's a cert object,
             # leave it alone
             if cert && !cert.kind_of?(OpenSSL::X509::Certificate)
-              cert = File.read(cert) if File::exists?(cert)
+              cert = File.read(cert) if File::exist?(cert)
               cert = OpenSSL::X509::Certificate.new(cert)
             end
             cert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20060831/ce36f6e2/attachment.bin