[Pkg-nagios-devel] [Nagiosplug-devel] Libtap included in distribution
sean finney
seanius at seanius.net
Fri Aug 22 16:12:07 UTC 2008
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
More information about the Pkg-nagios-devel
mailing list