Possible solutions to improve rubygems for intrepid

[Kees Cook]

Hi,

On Tue, Sep 16, 2008 at 03:19:29PM +0200, Stephan Hermann wrote:
> On Tue, 2008-09-16 at 09:42 +0200, Lucas Nussbaum wrote:
> > On 15/09/08 at 21:51 -0400, Mathias Gug wrote:
> > > Hi,
> > > 
> > > Here is a summary of the different solutions that have been discussed to
> > > fix bug 145267 [1] aka binaries installed by gems via the gem command
> > > are not on the PATH:
> > > 
> > > 1. Provide binaries in /usr/local/bin: 
> > > 
> > >   a. Via symlinks from /var/lib/gems/1.X/bin/: uses postinst hooks and
> > >   update-alternatives. This is what the reverted upload implemented [2].  
> > > 
> > >   b. Put binaries directly in /usr/local/bin instead of
> > >   /var/lib/gems/1.X/bin/. This solution has been suggested by Lucas [3].
> > > 
> > > Issues:
> > > 
> > >   * installed binaries could be overwritten by other installation
> > >     systems and breaking binaries installed by the gem command. The gem
> > >     sub-system would be less robust due to its links in /usr/local/bin/.
> > 
> > This is not different than manually installed software (using
> > ./configure ; make ; make install), so it's unlikely to be a surprise
> > for the user.
> > 
> > Note that 1.a requires upgrading rubygems to a VCS snapshot (so hooks
> > can be used), while 1.b is a one-liner away.
> 
> Both ideas have one problem:

I have to disagree.  As Lucas says, this is identical to having an admin
download and use the gems directly. 

> User 1 just does "gem install ..." and somehow all the stuff lands
> somewhere in the general $PATH (/usr/local/bin/ or via alternatives).

This is _expected_.  Without this, the software isn't actually useful in
any real sense of the word.  If the software gets hidden, the User will
ignore the Ubuntu-installed version of gems, and install it from 3rd
party source, and end up with things directly installed anyway.

> User 1 just runs something from real ubuntu packages and this software
> fails, because of different versions of dependend software
> in /usr/local/bin or specified in alternatives.
> User 1 just runs something from real ubuntu packages and this software
> fails, because of different lib versions of dependend software.

This would happen with 3rd party source too.  It is not something that
is solvable outside of dpkg packaging.  We should help people in the
least destructive way, which is using the /usr/local symlinks.

> User 1 writes bug reports to Launchpad, because he/she thinks it's
> ubuntus problem, but in reallife it's a gem package which disturbed
> his/her system.

This again will happen anyway when they have 3rd party source installed.
However, it's _harder_ to diagnose when they're not using the Ubuntu
gems installer since we will not be able to get versions on things like
the installer, lists of symlinks, etc.  Non-dpkg software installs are
always getting in the way of LP bug reports; this is not anything new to
triagers.

> Having the gem installation path somewhere far away from the standard
> PATHs (speak: $PATH) is a better approach and the responsible admin or
> the developer can symlink, move it, copy it somewhere where it fits for
> his/her system.

That's fine for them if they choose to use 3rd party source.  For what
ships with Ubuntu, we should help the default choice: making the gem
useful immediately while doing the best we can to maintaining system
sanity.

-Kees

-- 
Kees Cook
Ubuntu Security Team