[Bug 470696] Review Request: rubygem-passenger - Passenger Ruby on Rails deployment system

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=470696





--- Comment #37 from Toshio Kuratomi <tkuratom at redhat.com>  2009-06-07 16:08:02 EDT ---
Short answer: vendoring or bundling of libraries is not allowed.

Long answer: you can request an exception from FESCo but it's not likely to be
granted with just the reasons you've given here.  When you bundle a library
and, on top of that, modify it so it no longer matches upstream, you are
starting the process of forking the library.  This may not seem like much of an
issue to a developer.  (Hey, I just have one or two forked libraries, no
problem for me to track security issues.)  But it makes life much more
difficult for distributions.  There are places that this shows up.

* Security.  You touched on the fact that you've heard the security arguments
but I'll go ahead on specify them here since there's many different places that
this touches:
  - When a security flaw is discovered in a library and bundling is not
allowed, The library can be fixed in a single package, that package rebuilt,
and when users download it, all the applications that use it are immediately
protected.  When bundling is allowed, the distribution has to find all the
packages that the library occurs in by auditing source code or running a
special tool over all elf files in all packages, then all of those packages
have to be fixed, all of those packages have to be built, and users have to
download and update each of the ones that they are using on their system before
they are protected.  There is much more work involved when bundled libraries
are involved.
  - With security issues, people want to remove as much lag as they can between
announcement of a problem and the fix being available for users.  When
libraries are unbundled, tools like vendor-sec can be used to alert
distributions of problems that need patching in their packages before the
announcement is made and then they can fix them with zero days of
vulnerability.  If bundling of libraries occurs, then the problem becomes how
to get fixes out to all affected packages.  If the distribution patches those
packages, they must be careful to not leak the fact that there is a security
vulnerability before they are allowed (which means they need to be careful who
they share the information and what information they share with others).  OTOH,
if they do not patch the packages bundling libraries, then those packages are
not protected on zero day, but only afterwards.
  - When a security flaw appears, the program has to either update to a
non-affected version of the library or backport a fix.  This can be problematic
when the code of the library has undergone many API and code changes since the
version that is being bundled and the security fixing patch is very widespread.
 Many conflicts can arise that need time to fix when trying to backport the
fixes but porting the application code to the new API version can also take a
lot of time.
  - We cannot implicitly trust an upstream application to be on top of security
issues that are released in the packages that they care about.  What happens if
you are not following boost development and don't know that a security release
has been made?  What happens if the developer that is responsible for watching
boost development goes on vacation or quits your project?  What happens if your
application ceases active development?  What happens if boost stops active
development and security fixes start originating with distro patches?
* Forking is occurring.  Once an application starts bundling libraries, it's
easy for the project to include local patches to the library to add features
that upstream doesn't have or fix bugs that upstream hasn't addressed.  This
has several negative effects.
  - When a security issue appears, it becomes harder to fix the application
bundling the library.  If you attempt to upgrade to a newer version, you have
to make sure your important local modifications get ported to the new version. 
If you attempt to backport, you have to merge the upstream fix to your own
code-base which may have conflicts with the local modifications.
  - When working with the library that comes from upstream, there is a
community of people who are interested in that library to fall back on for
help.  When working on your own private copy that community may not be
interested in helping you work on your modified sources since they don't have
control or knowledge of what your modified sources do.
  - Forking dilutes one of the strengths of open-source development.  Instead
of a project getting stronger with more people supplying patches to help drive
the project and build a bigger community, the community of people interested in
it are splintering, developing more and more divergent code-bases, solving the
same problem over and over in different ways in different private copies of the
library.  Instead of everyone benefiting, everyone has to pay.
* Bugfixes.  Are usually of lesser importance from security issues but share
the same issues arise.
* Old versions of code linger on.  If the application can bundle its own
version of a library, the incentive to port to newer versions of the library
are reduced.  This exacerbates the problems of security and bugfix issues. 
Instead of progressively porting to newer versions of a library as time goes
on, porting to newer versions becomes a chore that has to be performed at the
same time as addressing a security flaw.  This puts time pressure on the
project when the work could have been spread out over a longer period if only
the porting had been done all along.
* Licensing.  Although licensing issues can crop up in any project, projects
which bundle code from different sources together are a special source of
concern.  They make auditing for license issues a larger project.

One last note related more to what you wrote than to the reasons that bundling
is not allowed in Fedora.  You write that you are willing to:

"take full responsibilities for any security problems; that is, we will either
backport security fixes or upgrade our vendored Boost to a newer version."

However, I wonder what that means to you.  Are you guaranteeing that you will
be able to produce zero day updates of your packages that include the fixes to
your bundled boost at the same time as boost itself is updated?  Are you saying
that you will always be around to handle the problems that can arise?  What
happens if your responses are not timely enough to meet the needs of our users?
 Are you making a monetary guarantee?  I think that attempting to say that you
take full responsibility in this context should be approached with caution on
your part as what it entails could be interpreted in many different ways.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.