[Nagiosplug-devel] Libtap included in distribution
ton.voon at altinity.com
ton.voon at altinity.com
Fri Aug 22 16:40:17 CEST 2008
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
More information about the Devel
mailing list