[Secure-testing-team] embedded library copies in monotone

Zack Weinberg zackw at panix.com
Thu Oct 18 22:35:51 UTC 2007


On 10/18/07, Florian Weimer <fw at deneb.enyo.de> wrote:
> >> Thanks for the information, I added it to the list. But I really think
> >> you should try to link dynamically in your Debian package where
> >> possible, even if upstream doesn't want to do it. In particular
> >> libpcre already had security issues in the past, so it would be
> >> important that you try to link to the packaged version.
> >
> > I'm not going to diverge from upstream on this.
>
> Well, you have to, because currently, upstream is in breach of the PCRE
> license (haven't checked the other libraries).  See, if you use your own
> private copies, you have to take care of all the nitty-gritty details
> yourself.

If you're talking about what I think you are (statement of licensing
needed to be copied into the AUTHORS file), it has already been fixed.
 If not, I would appreciate details.

> I think your copy of SQLite is mostly unpatched, and libpcre3 has quite
> a good track record as far as backwards compatibility is concerned (same
> for SQLite).

I think that's the case as well - but the principal concern here is
not API breaks and not bugs clearly in the library or clearly in the
application.  The principal concern is interaction bugs provoked by
using the application with a version of the library that it has never
been tested with.  Such bugs have happened over and over again and we
are unwilling to risk any more until the application / libraries are a
good deal more mature.  You will note that we don't bundle zlib, which
has achieved a level of stability where it can be trusted not to cause
these problems.

I do plan to migrate the Debian package away from the bundled
libraries, but it will be done slowly, one library at a time, and in
order of stability - probably libidn first, then lua, and only after
that's proven to be safe will I even think about unbundling sqlite or
botan.

PCRE is a special case: regular expressions are not needed for core
functionality, and the autoconf logic to use an external version is
already present -- but if we permit version skew in PCRE, people who
do clever things in their .mtn-ignore files may have them work or not
work depending on where they got their copy of monotone.  And the
version currently bundled with monotone is newer than the version
currently available in Debian.  Once we get parity there, I'll switch
the package over -- there will, however, be a fairly tight versioned
dependency.

> I can understand that upstream wants to bundle third-party sources, but
> it's Debian policy to prefer system libraries over bundled copies.

If Debian cannot tolerate monotone's unusual situation I will, with
regret, have the package removed from Debian.

> It's rather selfish and harmful to the distribution as a whole if every
> maintainer fixes such bugs in a private copy, instead of addressing it
> for all users.

The bugs have, in general, been reported to the upstream maintainers
and fixed there.

Your statement borders on an accusation of bad-faith behavior.  Please
choose your words more carefully in the future.

zw



More information about the Secure-testing-team mailing list