[DRE-maint] Bug#448639: Debian Bugs information: detailed logs for Bug#448639

[Clint Byrum]

Hi Daigo, thanks so much for your thoughts on this matter,

On Aug 30, 2010, at 8:21 AM, Daigo Moriwaki wrote:

> Clint Byrum wrote:
>> In the upstream default install of rubygems, the default location for
>> these binaries and rubygems library files is /usr/bin, and /usr/lib
>> respectively. This places the binaries in the default shell path for most
>> FHS systems, so that users can have an experience something like this:
>> 
>> $ sudo gem install rails [... gem downloads and installs rails ... ]
>> $ rails my-facebook-killer-app/ [... A skeleton of a rails app is
>> created ...  ... I Start hacking on my-facebook-killer-app ...]
> 
> My opinion is opposite. I'd like to require users a manual intervention to
> execute binaries from gems due to security concern. Users might think that gem
> install something is very similar to apt-get install something. However,
> Rubygems' security culture differs from Debian's. Signed gems are not popular.
> Imagine that a gem (located in a server or through network) is attacked to
> include a malicious executable named 'ls', which then installs in your
> /usr/local/bin.
> 

I agree that users need to be protected from insecure code being inserted
into their environment. However, I feel that this is the responsibility
of the system administrator.

As a sysadmin, If I download a tarball, I must take the responsibility to
check for a signature.  If it is signed, I must take the responsibility
to verify that this key is in my trust network. If no such signature
exists, or if I cannot trust the author, I must make a best effort to
review the build system and code before placing it on my system.

However, we all know that system administrators are busy, and do not have
time for this, so many will simply refuse to install using tarballs,
trusting instead the distributor of software they have chosen (such as
Debian), or will skip this step, endangering their users. But that is
their choice, it is their system and they must choose what level of risk
they take. Security is not a state of being, but a process involving
risk management.

rubygems is no different than wget, tar, make, and gcc. These are all
just developer tools, and as such, can be dangerous. Right now, if an
admin makes a decision to install gems in /var/lib/gems/1.8/bin, and
then adds that directory to the default user path, users are at risk,
just as they would be if the programs were in /usr/local/bin.


> In addition, I'd like to make room in /usr/local/bin for local installations,
> such as setup.rb, make && make install etc... I think that I have made success
> in this point since nobody has ever claimed that /var/lib/gems is in his/her way
> .
> 

Daigo, I think you have done an amazing job with rubygems thus far,
and we should all be thankful for the hard work you've put into
maintaining it. This directory layout does make a lot of sense, in a lot
of ways. However, it is clear to me by talking with the ruby community,
and reading the comments added to this bug report, that this scheme has
caused issues, and so needs to be reviewed and possibly changed.


> 
>> However, this introduced an incompatibility with the FHS definition of
>> the purpose of /var[1].
> 
> I agree with the primary purpose of /var that you mentioned. But I can not find
> any better place to install gems files with two points above satisfied.

I think that by requiring FHS compliance, and choosing a default path, 
Debian policy has defined a small, acceptable level of risk for users.