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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
