[Pkg-nagios-devel] [Nagiosplug-devel] Libtap included in distribution

[sean finney]

hi everyone,

figured i would through my 0.02 $LC_MONETARY from the armchair :)

on the issue of embedding 3rd-party code, i think the situation is a little 
more nuanced then "include it or do not include it".  my personal 
recommendation, from having worked in this and other projects that wish to do 
so, as well as with the debian security team who often have to deal with the 
problem, is roughly as follows:

	"embedding code is okay, as long as you do not force users/packages/etc to 
	 use your embedded version"

providing bundled code is a great way to ensure cross platform / environment 
consistency.   however, as jan mentioned, this has security implications if 
the bundled code ever has a serious security problem, or otherwise requires 
an update.  

for example, PHP typically bundles the gd image library, imap client library, 
etc with their code.  both of these libraries have a long and ugly history 
security-wise, which in turn resulted in the upstream PHP project needed to 
release security updates due to their bundled code.   also, they bundle stuff 
like timezone data, which is a major pain in the ass to keep up to date (we 
recently patched that feature out, but i digress)

debian and others choose to build such packages using the distro-provided 
libraries instead, thus making bundled code unneeded but ultimately harmless.  
in most/ideal cases it's just a matter of passing --with-foo=/usr or similar 
to a configure script which will override the default behaviour of using the 
bundled version.

if nagios-plugins could/does provide similar functionality, i think the 
problem is essentially moot.

however, note that "do not force them to use your version" also means you 
shouldn't make any incompatible changes to the bundled code, as it would 
prevent others from using their local system versions.  i saw some mention 
earlier of needing to make a change in libtap for example.... though maybe 
that's not as grave since upstream work for that seems dead (you should email 
your patch anyway, as well as have it documented for posterity though, i'd 
say).

also, as an aside, i don't think libtap is packaged in debian at the moment (i 
tried packaging it a year or two back and ran into some problem before losing 
interest), though i do see gnulib packages.


	sean

On Friday 22 August 2008 05:09:30 pm Andreas Ericsson wrote:
> Then why is it needed? If it's just for tinderbox builds, why not install
> it on the various tinderboxen? If it's not for tinderbox builds, why ship
> it at all? If someone needs to test libtap functionality they can jolly
> well install libtap imo.

for anyone who wants to write/run tests on their local code.  i don't see that 
as being incredibly problematic.

> > 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.
>
> It'll be even easier when you move to git, as you can then use gnulib
> as ae submodule (Jim Meyering who maintains gnulib is an avid git-fan
> and contributor) ;-)

agreed, though from my experience git submodules are still quite lacking from 
a usability perspective.

> I should probably shut up though. It's friday and beer is flowing
> freely within the office walls :-)

git clone beer://andreas here



	sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/pkg-nagios-devel/attachments/20080822/9eb2d256/attachment.pgp