Secure testing team - Oct 2007 - embedded library copies in monotone

Hi Zack,

On Monday 15 October 2007, you wrote:
> > There are a number of packages including source code from
> > external libraries, for example poppler is included in xpdf, kpdf
> > and others.  To ensure that we don''t miss any vulnerabilities
in
> > packages that do so we maintain a list[6] of embedded code copies
> > in Debian.
>
> I maintain the monotone package, which presently contains embedded
> copies of several external libraries.  It is not on your list. 
> (It''s not presently in testing due to unrelated problems, but it
> hopefully will be again soon.)  Upstream is aware that this is a
> problem for Debian and other distributions, but has had serious
> problems with library version skew in the past and is therefore
> being very cautious and slow about opening up the possibility of
> using dynamic linkage. They''ve historically been very good about
> keeping up with upstream security fixes for the embedded libraries.
>
> The 0.36 source package embeds these libraries with equivalents
> already packaged for Debian:  liblua5.1 (same version as in
> Debian), libsqlite3-0 (ditto), libbotan1.6 (monotone''s copy is
> version 1.5) and part of libidn11 (also way out of date).  It also
> embeds a copy of the NetXX library, which is not packaged for
> Debian and is dead upstream; until we find a replacement it is best
> to consider that part of monotone proper.
>
> The 0.37 source package will also embed libpcre (a newer version
> than in Debian - in fact, 0.37 is being held for the next upstream
> release of libpcre, which monotone upstream has been told has
> security implications.)
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.

Cheers,
Stefan

On 10/16/07, Stefan Fritsch <sf at debian.org>
wrote:
> On Monday 15 October 2007, you wrote:
> > I maintain the monotone package, which presently contains embedded
> > copies of several external libraries.  It is not on your list.
> > (It''s not presently in testing due to unrelated problems, but
it
> > hopefully will be again soon.)  Upstream is aware that this is a
> > problem for Debian and other distributions, but has had serious
> > problems with library version skew in the past and is therefore
> > being very cautious and slow about opening up the possibility of
> > using dynamic linkage.
[...]
>
> 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.

Upstream moved *away* from external libraries after being badly burned
by not being able to control exactly which version of the external
libraries was in use.  We are talking about things like data
corruption bugs tracked to bad interaction between monotone''s use
pattern and particular patch levels of sqlite.  In some cases there
have also been locally-applied modifications necessary for
correct/secure behavior.  Everyone agrees that this is not the ideal
state, but at present, if I were to switch the Debian packages to
external libraries, upstream would insist that any bug reported
against the packaged binaries be reproduced with a bundled-library
version before they''d look at it.

Some context -

http://lists.gnu.org/archive/html/monotone-devel/2005-04/msg00175.html
http://lists.gnu.org/archive/html/monotone-devel/2005-07/msg00192.html

zw

* Zack Weinberg:
> On 10/16/07, Stefan Fritsch <sf at debian.org> wrote:
>> On Monday 15 October 2007, you wrote:
>> > I maintain the monotone package, which presently contains embedded
>> > copies of several external libraries.  It is not on your list.
>> > (It''s not presently in testing due to unrelated problems,
but it
>> > hopefully will be again soon.)  Upstream is aware that this is a
>> > problem for Debian and other distributions, but has had serious
>> > problems with library version skew in the past and is therefore
>> > being very cautious and slow about opening up the possibility of
>> > using dynamic linkage.
> [...]
>>
>> 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.
> Upstream moved *away* from external libraries after being badly burned
> by not being able to control exactly which version of the external
> libraries was in use.
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 can understand that upstream wants to bundle third-party sources, but
it''s Debian policy to prefer system libraries over bundled copies.
> We are talking about things like data corruption bugs tracked to bad
> interaction between monotone''s use pattern and particular patch
levels
> of sqlite.
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.

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

* Zack Weinberg:
>> 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.
Yepp, something along those lines.  I think you should add parts of the
AUTHORS file to debian/copyright, too.
>> 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.
We''ve got dependencies for that, as you noted below.
> 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.
Yuck, that''s right.  It''s not just "clever things",
it could be
mistakes.  For instance, if you used a "\Redundant" regular
expression,
that''s equivalent to "Redundant" in older PCRE versions
(which might be
your true intention), but newer versions add \R as an escape sequence,
so the expression means something completely different.

I think you really should restrict users to some sane subset. 8-/
>> 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.
I don''t see how Monotone''s situation is so unusual.  I
understand that
you got bitten in the past, but so have others.  But with the notable
exception of some of the Java folks, we tend to rely on system
libraries, even if they make some things harder (updates, for instance,
or testing).
> Your statement borders on an accusation of bad-faith behavior.  Please
> choose your words more carefully in the future.
Yes, it was over the top.  Sorry about that.  But if everyone shipped
private copies of libraries they are deeply concerned with, we''d run
into severe issues.  So I''m glad that you view the current state of
affairs as a starting point, and not the final packaging.