[Pkg-nagios-devel] [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