Re: libpaper and gnulib
On Sun, Nov 13, 2022 at 02:01:50PM +0000, Reuben Thomas wrote:
> I am the upstream maintainer of libpaper (which used to be a pure-Debian
> project), and also a Debian Maintainer trying to get a new version of
> libpaper into Debian. (It involves an API/ABI transition, from the current
> libpaper1 to libpaper2.)
>
> Bastian Germann (bage@debian.org) is kindly helping with the packaging and
> sponsoring my upload.
>
> I just got a rejection for libpaper_2.0.3-1 from ftp-master (in this case,
> Thorsten Alteholz), who said "I didn't find any explanation why you
> embedded a copy of gnulib in your source tarball. Do you really need that?"
Even if you do end up build-depending on gnulib, I see no reason why you
should strip the files out of the source tarball. There's no
DFSG-freeness issue here, and removing them would introduce unnecessary
complexity (even if uscan makes it mostly straightforward these days,
it's still more complex than not doing it; and the files containing
elements from Gnulib are by no means neatly confined to a single
directory or anything like that).
Other things to consider:
* upstreams rarely (if ever?) track exactly how new a version of Gnulib
they need due to its typical use as a copylib, so build-depending on
the packaged version would likely make backports harder (keeping the
files in the source package would mitigate this a bit since at least
backports could drop the build-dependency if they needed to);
* although Boyuan Yang has been doing a good job recently at keeping
the package updated and I don't want to throw any shade in their
direction, I think I am probably not the only person who would be
slightly uneasy about introducing a build-dependency from (at least
in some cases) rather critical packages to a QA-maintained package
whose only active packager for the last three years seems reluctant
to take over full maintainership;
* interactions between upstream code and Gnulib can be pretty subtle,
so consider if you're really prepared to debug the FTBFS reports
likely to result from using a different commit from upstream, on an
ongoing basis;
* the "unless the included package is explicitly intended to be used in
this way" language in Policy 4.13 was specifically intended to cover
Gnulib, and IMO ftpmaster should take that into account (see
https://bugs.debian.org/392362).
Notwithstanding this, I'll have a look at my own packages that use
Gnulib to see if it's reasonably practical these days to switch to using
the packaged version. I don't think this is going to be a quick
decision for me. Part of my concern based on over 15 years of
experience with using Gnulib is that I'm unsure whether this is going to
introduce an unreasonable amount of breakage over time, rather than
necessarily whether it will work right now.
I had a look through my email archives, and found a discussion about
this way back in 2008 in the context of some other package, where I
wrote this response (in part). I think it still largely stands up.
========================================================================
During the debian-policy discussion, Ian Jackson brought up the question
"When we find a /tmp handling vulnerability in gnulib, will we not have
a serious problem?", which is likely to be the core of ftpmaster's
concern here. I understand this type of concern since Gnulib does indeed
contain some /tmp-handling functions, although mostly just very basic
ones (for example it provides replacements for mkstemp and mkdtemp). I
think this type of concern is mitigated for the following reasons,
though:
* While (as others have brought up) you need to be careful about it,
Gnulib makes it easy for upstreams to keep up to date using
'gnulib-tool --update', and so they generally do. (You'd get a lot
more skew if they had to copy files in by hand.)
* Gnulib is IMO best regarded as the other half of Autoconf (the bit
that actually supplies replacements for all those functions that
configure scripts check for ...), and we're well used to Autoconf
working this way. Which is better: having each upstream maintainer
write their own replacements, or having a common repository of them
in Gnulib? I know which I prefer.
* Gnulib is maintained by many of the same people who maintain things
like the core GNU utilities and are frequent contributors to GNU
libc. I know that arguments based on people's competence are not the
best since (a) security holes crop up in even the best code and (b)
of course everyone says *they're* competent, but at least my
experience of Gnulib has really been very good.
* The usual argument is that these functions should go in a shared
library instead. In fact, many of them do, namely libc - in a number
of cases this code isn't used on Debian. In cases where it is
(xmalloc, xasprintf, execute_java_class, etc.) I think it's
nevertheless better than people rolling their own slightly different
versions.
* The functions that Gnulib tends to provide are basically those that
are in libc or little things that lots of upstreams tend to
implement themselves (badly). In pretty much every case, equivalent
code would be in the package anyway; if you forbid the use of Gnulib
then they'll just write it themselves! gnulib-tool only copies the
files that are actually used.
* One effect that I have noticed in using Gnulib as an upstream is
that, because it provides implementations of GNU-specific functions
for systems that lack them, I am much more likely to be willing to
use those functions. Despite the fact that some code ends up being
copied around as a fallback measure (much of it not used when built
on Debian, as above), this comes out as a net win as far as security
is concerned. I'd much rather live in a world where people use
Gnulib and so are willing to use non-portable functions like
asprintf, canonicalize_file_name, openat, and so on than our current
world which is still full of stupid vulnerabilities due to people
getting sprintf or realpath buffer sizes wrong or race conditions
while traversing directory trees.
========================================================================
--
Colin Watson (he/him) [cjwatson@debian.org]
Reply to: