[Nagiosplug-devel] Libtap included in distribution

[ton.voon at altinity.com]

Hi Jan,



On Fri, 22 Aug 2008 15:56:15 +0200, Jan Wagner <waja at cyconet.org> wrote:

> On Friday 27 June 2008 00:01, Ton Voon wrote:

>> Based on a comment made by Thomas, I've added the libtap distribution

>> into the nagios plugins project. This enables us to run C tests

>> without a dependency on external code.

>>

>> It includes two changes to the libtap project from

>> http://jc.ngo.org.uk/trac-bin/trac.cgi/wiki/LibTap including disabling

>> LIBPTHREAD and asprintf from gnulib

>> (http://jc.ngo.org.uk/trac-bin/trac.cgi/ticket/32 ).

>>

>> libtap will only get included if ./configure --enable-libtap is set.

>> However, compiling will only take effect if a "make test" is run.

> 

> sorry, but I have to come up with some complaints about that idea. I'm 

> speaking as member of the Debian Nagios Maintainer Group. Do you really

> think 

> it's an good idea to embedd code copies of other projects?

> 

> Embedding other software forces you to keep track of (security-)issues of

> each 

> of these projects and to update your copies at least if there occure any 

> breakerage. The chance you are missing some of them is not less and if 

> upstream of the code copies fixed their code, it will take extra time

> until 

> you release a new version with the fixed code and even it will add extra

> work 

> to your project.

> 

> For Distribution/Packagers this will become a big problem as well. They

> have 

> to keep track for all versions of these "embedded code copies" and try to



> backport the fixes to all (various) versions embedded in various software



> packages. Maybe the Security Team, which is responsible for updating

> security 

> bugs, is not aware that software "Y" is shipped within software "Z",

where

> 

> software "Y" has an security issue, so software "Z" is also vulnerable.

> 

> Even as long as you don't modify the upstream code, there is a chance to

> use 

> the embedded software from external sources (for example the version

> shipped 

> with the distribution and have the issue allready fixed). If you include

> your 

> own changes into these code copies, this isn't possible anymore and your 

> project is the single point to get this issue of your code copy fixed,

> which 

> is quite annoying for all sides.

> 

> Please think carefully about your idea to ship 3rd party software with

> yours, 

> hopefully you will reconsider your decision. The Debian Security and the 

> QA-Team did force removal of software with embedded code copies from the 

> distribution in the past, which is not what anybody whats for

> nagios-plugins, 

> I guess.



The 3rd party code in question here is only for testing purposes. It is

only enabled with a configure flag, so, outside of development, will not

usually be used.



On the general principle of whether to include 3rd party code, I'm not sure

I agree with your stance. For instance, we include the Nagios::Plugins perl

modules (and dependencies). This is to simplify installation for our users.

However, there is a configure option to not include the perl modules, so

you can add the appropriate dependencies at the packaging layer instead.



A more entrenched example would be GNU lib - we embed their code (at their

recommendation). Theoretically, a security exposure could be found there.

But we have a very simple process to update their software and cut a new

package. There's no way I would want this project, or any others that use

gnulib, to have to recode all the functionality they provide.



I can't guarantee that we will not include 3rd party software in future. We

have to make a judgement on whether a 3rd party piece of code will provide

us features or cross platform capabilities we need without re-inventing the

wheel. That's a compromise we have to make. However, when possible, we will

allow configure options to disable 3rd party code.



Ton