|
|
| (72 intermediate revisions by 5 users not shown) |
| Line 1: |
Line 1: |
| I'm getting tired of explaining why bundled libraries are not allowed. Let's document all the reasons and then link to it from the relevant Packaging Guidelines.
| | This page has been rendered irrelevant by updates to the bundling policy. The previous content is of course available in the page history. |
| | |
| I don't know if this is relevant to the Packaging Guidelines but I showed this video of my PyCon Presentation to some people in docs and they thought it was useful for explaining the reasons not to bundle to people coming from a proprietary software background. Might be good to link to from a tips and tricks page or something. http://pycon.blip.tv/file/2072580/
| |
| | |
| == Why no Bundled Libraries ==
| |
| | |
| Although you can request an exception from FESCo there are many reasons not to grant one. These are the reasons that it's painful for us to have bundled libraries in the distribution. An exception should only be granted if the value of bundling exceeds these costs.
| |
| | |
| === Security ===
| |
| | |
| * 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 ===
| |
| | |
| 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 ===
| |
| | |
| Bugfixes are usually of lesser importance from security issues but share
| |
| the same issues of hanging onto lingering problems that have been fixed in the main package.
| |
| | |
| === Old Code ===
| |
| * 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.
| |
| | |
| == When a Bundled Library is Discovered Post-Review ==
| |
| Bundling of libraries is a serious problem. If a package that is in the distribution is discovered to have bundled libraries we need to fix it. First, open a bug report against the package. Then add the bug to the [[https://bugzilla.redhat.com/show_bug.cgi?id=504493 Duplicate libraries tracker]]. Once that's done, if help is needed fixing the bug ask on the mailing list.
| |
| | |
| [[Category:Packaging guidelines drafts]]
| |
