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 (b...@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) [cjwat...@debian.org]
