Ian Jackson <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
