[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#392362: [PROPOSAL] Add should not embed code from other packages



Ian Jackson <ian@davenant.greenend.org.uk> writes:
> Colin Watson writes:

>> Gnulib in fact provides a number of other useful utility functions as
>> well as simply replacement functions (e.g. xmalloc, xasprintf,
>> compile_csharp_using_pnet, execute_java_class) so this assumption may
>> well not be correct.

> When we find a /tmp handling vulnerability in gnulib, will we not have
> a serious problem ?

The sort of functions that gnulib provides are generally not going to have
this sort of problem, but yes.  It's a worry.

On the other hand, gnulib simply doesn't support a library model of use,
and has a lot of infrastructure built up around *not* being used that
way.  To turn it into a library and modify source packages to link against
it would be quite a bit of work on the Debian side that's not the
direction that upstream is going.  So I think we're on the bad end of that
tradeoff.

In the interest of getting *something* into Policy, even if it doesn't
give us everything that we want, I'm inclined to accept Colin's suggestion
and exempt cases where upstream intends the code to be embedded and not
used as a separate library.  It means that Policy won't be helping with a
few of our annoying cases, but at least we say something about the general
case and the specific cases can still be dealt with on a case-by-case
basis the way that we do now.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Reply to: