Bug#488753: (forw) Re: Boost bundling
In an effort to try and determine where the situation with Passenger in Debian is stalled, I went on a small adventure to figure out where things are. What follows is the details of the current situation, as well as a helpful explanation from the Passenger folks. I intend to respond to that message when I can, but first I wanted to get the current state of things loaded up into this bug report, so others can see where things are at. First I found that Passenger/mod_rails had been uploaded to NEW[0] some four months ago by Leandro Nunes dos Santos and Filipe Lautert . However, it had not been accepted by the FTP masters, and as such it was not part of the archive yet. Typically when there is a delay such as this in accepting the package into the archive there is some problem, either legal/licensing or technical that is keeping the package from being accepted. I contacted a member of the FTP team to ask what the hold-up was and was told the reason is because passenger has an embedded copy of boost and the FTP team has asked the maintainer at least twice about it and have received no reply. The embedded code problem is an interesting one, one that I have been involved in over the years working in on testing-security where we've been forced to track embedded code copies in Debian[1] so that we could have a chance to deal with security issues in embedded code copies. (A prominently horrible example is the xpdf code-base which was at one time embedded in more than 10 different source packages in Sarge, this was reduced in Etch significantly thanks to the xpdf library fork called poppler which packages were encouraged to link against, instead of embedding). As a result of these issues causing significant number of hours to track, update and manage, with many clever technical solutions developed to do things like use the clamav signature mechanisms to scan the entire archive, etc. Eventually the Debian project saw fit to adopt a policy[2] with specific language about embedded "convenience copies" of code (section 4.13). And this is where Passenger is currently stuck. I took a little bit of time the other day to try and figure out why Passenger embedded Boost and could not find much rationale online, until I found an older blog post[3] about the 1.0.2 release that contains this snippet: Fixed conflicts with system-provided Boost library Passenger makes use of the Boost C++ library. Its sources are included into the Passenger sources. But if the system already has a different Boost version installed, then the two Boost libraries would conflict with each other, and Passenger would fail to install. We’ve made sure that this doesn’t happen: now, installation will succeed even if there’s already another Boost version installed. This is a good first effort, however I believe that this solution doesn't get at the root of the problem and instead makes one of the symptoms go away instead of solving the problem. So I posted to the comments section of the blog asking for more details, and describing the issue around embedding copies of other code, and then received the following response in email (which I have obtained permission to forward here): - Forwarded message from Hongli Lai - Sender: Hongli Lai From: Hongli Lai Subject: Re: Boost bundling Date: Thu, 05 Mar 2009 10:06:44 +0100 To: mi...@debian.org Hi Micah, I saw your reply to my blog about making Boost a build dependency, but I'm afraid your arguments do not hold in our case: - The best argument for wanting to depend on Boost dynamically, is to make it easier to solve security problems. However, upgrading the Boost library will only partially fix security problems. That's because most Boost code live in C++ header files, which get inlined directly by the compiler into the executable. If a security flaw was found in a header then you'd have to recompile the executable that uses Boost even if Boost is a shared library. - Most people don't have Boost installed, or don't have the right version of Boost installed. By far and large, most of our users are _not_ Debian users, and installing Boost is a huge huge pain for 80% of our user base. By _not_ bundling Boost we'll alienate most of our users. I have a different software program which does not bundle Boost, and the #1 support question by users is related to installing Boost. Even Debian users will have a difficult time. We depend on a very specific version of Boost, one that hasn't been packaged by Debian yet. I don't think that telling our Debian users "what? don't have the right version of Boost installed? then wait x months/years until Debian has packaged it, then upgrade your distro" is an acceptable answer to our users, don't you agree? The Fedora guys have tried to patch Phusion Passenger to get rid of the Boost bundling, but after they're done they found out that Fedora ships the wrong version of Boost, putting them back at squa
Bug#488753: (forw) Re: Boost bundling
* Hongli Lai [2009-03-06 09:53-0500]: > Micah Anderson wrote: >> However, it had not been accepted by the FTP masters, and as such it was >> not part of the archive yet. Typically when there is a delay such as >> this in accepting the package into the archive there is some problem, >> either legal/licensing or technical that is keeping the package from >> being accepted. I contacted a member of the FTP team to ask what the >> hold-up was and was told the reason is because passenger has an embedded >> copy of boost and the FTP team has asked the maintainer at least twice >> about it and have received no reply. > > That's strange, I don't recall having been contacted about this subject > before. Sorry I wasn't clear here. I was referring to the Debian packager maintainers, not you (what we would call 'upstream'). micah signature.asc Description: Digital signature
Bug#488753: (forw) Re: Boost bundling
Hello, *Mark/FTP Masters team*, As stated in e-mail below from Hongli Lai (passenger's mainstream), boost library has modifications specific to passenger, so we won't be able to use a "generic" library package. Is this case, I request that you ACCEPT this package. *Micah*, thanks for your kindly help on this issue. I've been running out of time lately and was just keeping my other packages in shape, leaving passenger behind. Best regards to you all, filipe Micah Anderson wrote: In an effort to try and determine where the situation with Passenger in Debian is stalled, I went on a small adventure to figure out where things are. What follows is the details of the current situation, as well as a helpful explanation from the Passenger folks. I intend to respond to that message when I can, but first I wanted to get the current state of things loaded up into this bug report, so others can see where things are at. First I found that Passenger/mod_rails had been uploaded to NEW[0] some four months ago by Leandro Nunes dos Santos and Filipe Lautert . However, it had not been accepted by the FTP masters, and as such it was not part of the archive yet. Typically when there is a delay such as this in accepting the package into the archive there is some problem, either legal/licensing or technical that is keeping the package from being accepted. I contacted a member of the FTP team to ask what the hold-up was and was told the reason is because passenger has an embedded copy of boost and the FTP team has asked the maintainer at least twice about it and have received no reply. The embedded code problem is an interesting one, one that I have been involved in over the years working in on testing-security where we've been forced to track embedded code copies in Debian[1] so that we could have a chance to deal with security issues in embedded code copies. (A prominently horrible example is the xpdf code-base which was at one time embedded in more than 10 different source packages in Sarge, this was reduced in Etch significantly thanks to the xpdf library fork called poppler which packages were encouraged to link against, instead of embedding). As a result of these issues causing significant number of hours to track, update and manage, with many clever technical solutions developed to do things like use the clamav signature mechanisms to scan the entire archive, etc. Eventually the Debian project saw fit to adopt a policy[2] with specific language about embedded "convenience copies" of code (section 4.13). And this is where Passenger is currently stuck. I took a little bit of time the other day to try and figure out why Passenger embedded Boost and could not find much rationale online, until I found an older blog post[3] about the 1.0.2 release that contains this snippet: Fixed conflicts with system-provided Boost library Passenger makes use of the Boost C++ library. Its sources are included into the Passenger sources. But if the system already has a different Boost version installed, then the two Boost libraries would conflict with each other, and Passenger would fail to install. We’ve made sure that this doesn’t happen: now, installation will succeed even if there’s already another Boost version installed. This is a good first effort, however I believe that this solution doesn't get at the root of the problem and instead makes one of the symptoms go away instead of solving the problem. So I posted to the comments section of the blog asking for more details, and describing the issue around embedding copies of other code, and then received the following response in email (which I have obtained permission to forward here): - Forwarded message from Hongli Lai - Sender: Hongli Lai From: Hongli Lai Subject: Re: Boost bundling Date: Thu, 05 Mar 2009 10:06:44 +0100 To: mi...@debian.org Hi Micah, I saw your reply to my blog about making Boost a build dependency, but I'm afraid your arguments do not hold in our case: - The best argument for wanting to depend on Boost dynamically, is to make it easier to solve security problems. However, upgrading the Boost library will only partially fix security problems. That's because most Boost code live in C++ header files, which get inlined directly by the compiler into the executable. If a security flaw was found in a header then you'd have to recompile the executable that uses Boost even if Boost is a shared library. - Most people don't have Boost installed, or don't have the right version of Boost installed. By far and large, most of our users are _not_ Debian users, and installing Boost is a huge huge pain for 80% of our user base. By _not_ bundling Boost we'll alienate most of our users. I have a different software program which does not bundle Boost, and the #1 support question by users is related to installing Boost. Even Debian users will have a difficult time. We depend on a very specific vers
Bug#488753: (forw) Re: Boost bundling
Micah Anderson wrote: However, it had not been accepted by the FTP masters, and as such it was not part of the archive yet. Typically when there is a delay such as this in accepting the package into the archive there is some problem, either legal/licensing or technical that is keeping the package from being accepted. I contacted a member of the FTP team to ask what the hold-up was and was told the reason is because passenger has an embedded copy of boost and the FTP team has asked the maintainer at least twice about it and have received no reply. That's strange, I don't recall having been contacted about this subject before. As a result of these issues causing significant number of hours to track, update and manage, with many clever technical solutions developed to do things like use the clamav signature mechanisms to scan the entire archive, etc. Eventually the Debian project saw fit to adopt a policy[2] with specific language about embedded "convenience copies" of code (section 4.13). And this is where Passenger is currently stuck. I understand why Debian has adopted this policy. However, as explained in the forwarded email, Phusion Passenger uses a modified version of Boost. We accept full responsibility for any security problems found in Boost. If a security problem is found in Boost then we _will_ update our bundled version. -- Phusion | The Computer Science Company Web: http://www.phusion.nl/ E-mail: i...@phusion.nl Chamber of commerce no: 08173483 (The Netherlands) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#488753: (forw) Re: Boost bundling
Hongli Lai wrote: Micah Anderson wrote: However, it had not been accepted by the FTP masters, and as such it was not part of the archive yet. Typically when there is a delay such as this in accepting the package into the archive there is some problem, either legal/licensing or technical that is keeping the package from being accepted. I contacted a member of the FTP team to ask what the hold-up was and was told the reason is because passenger has an embedded copy of boost and the FTP team has asked the maintainer at least twice about it and have received no reply. That's strange, I don't recall having been contacted about this subject before. Yeap, you weren't. I was contacted... the maintainer in this case is the package maintainer. And I'd no time to go after this As a result of these issues causing significant number of hours to track, update and manage, with many clever technical solutions developed to do things like use the clamav signature mechanisms to scan the entire archive, etc. Eventually the Debian project saw fit to adopt a policy[2] with specific language about embedded "convenience copies" of code (section 4.13). And this is where Passenger is currently stuck. I understand why Debian has adopted this policy. However, as explained in the forwarded email, Phusion Passenger uses a modified version of Boost. We accept full responsibility for any security problems found in Boost. If a security problem is found in Boost then we _will_ update our bundled version. Thank you! Cheers filipe -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
