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

Florian Weimer fw at deneb.enyo.de
Thu Oct 18 21:28:58 UTC 2007


* 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.



More information about the Secure-testing-team mailing list