On 13/11/2018 17:43, Antoine Beaupré wrote: > On 2018-11-13 13:24:39, Ben Hutchings wrote: >> On Mon, 2018-11-12 at 15:16 -0500, Antoine Beaupré wrote: >>> Hi, >>> >>> So I've been looking at Enigmail again, after a long journey helping >>> people in stable getting that stuff fixed. It's pretty obvious there's >>> no way to upload that without first doing a GnuPG 2.1 backport into >>> jessie. >>> >>> That, it turns out, requires *four* more source package >>> backports. Fortunately for us, *all* of those are already in >>> jessie-backports. They would, unfortunately, probably need to be >>> uploaded straight into jessie-security, however, if only for >>> consistency's sake. >>> >>> That would mean, however, a more or less forced update on the following >>> libraries in jessie: >>> >>> * libassuan (part of GPG, 2.1 -> 2.4) >>> * libgcrypt20 (part of GnuTLS, 1.6 -> 1.7) >>> * libgpg-error (GPG, 1.17 -> 1.26) >>> * npth (GPG, 1.0 -> 1.3) >>> >>> How should we handle this? I haven't looked at each backport in detail >>> to see if ABI changes are significant, but the version numbers seem to >>> indicate they are not (for what that's worth of course). >> [...] >> >> Unless these are bug-fix-only updates, I don't think they are suitable >> for jessie-security. > > I doubt they are: > > https://tracker.debian.org/media/packages/liba/libassuan/changelog-2.4.3-2~bpo8%2B1 > https://tracker.debian.org/media/packages/libg/libgcrypt20/changelog-1.7.6-1~bpo8%2B1 > https://tracker.debian.org/media/packages/libg/libgpg-error/changelog-1.26-2~bpo8%2B1 > https://tracker.debian.org/media/packages/n/npth/changelog-1.3-1~bpo8%2B1 > > Lots of "new upstream release" in there which can basically mean > anything. Here are the respective changelogs: > > https://sources.debian.org/src/libassuan/2.4.3-2%7Ebpo8+1/ChangeLog/ > https://sources.debian.org/src/libgcrypt20/1.7.6-1%7Ebpo8+1/ChangeLog/ > https://sources.debian.org/src/libgpg-error/1.26-2%7Ebpo8+1/ChangeLog/ > https://sources.debian.org/src/npth/1.3-1%7Ebpo8+1/ChangeLog/ > > None of those are patch releases. In fact, in some cases, there *are* no > patch releases (e.g. libpth) and I doubt minor releases are really minor > anyways... > > So yes, those are significant upgrades. > > I take solace in the fact that those packages are on jessie-backports > already and that if they would have broken stuff, people would have > noticed already... > > ... right? :) > >> Would it be possible to bundle the libraries with gpg 2.1, and install >> them somewhere that doesn't conflict with the existing versions? > > That is a possibility. libassuan, for example, is basically this in > jessie right now: > > /usr/lib/x86_64-linux-gnu/libassuan.so.0.4.2 > > jessie-backports ships: > > /usr/lib/x86_64-linux-gnu/libassuan.so.0.7.3 > > both share the same major SONAME, unfortunately. So they is a clash on > the .so.0 symlink. I am not sure how the linker could handle duplicates > of those entries. And we'd have trouble in /usr/share/doc/libassuan0, > for example. > > libgcrypt is similar: > > /lib/x86_64-linux-gnu/libgcrypt.so.20.0.3 > /lib/x86_64-linux-gnu/libgcrypt.so.20.1.6 > > libgpg-error: > > /lib/x86_64-linux-gnu/libgpg-error.so.0.13.0 > /lib/x86_64-linux-gnu/libgpg-error.so.0.21.0 > > libnpth0: > > /usr/lib/x86_64-linux-gnu/libnpth.so.0.0.3 > /usr/lib/x86_64-linux-gnu/libnpth.so.0.0.6 > > I am not sure how we could ship both versions of those libraries in > jessie - that's beyond my linker skill level, i'm afraid. ;)
I can think of two options: 1) Ship them in a private dir (e.g. /usr/lib/gnupg2/), and link them to those libs. Then ld should add an RPATH, otherwise an LD_LIBRARY_PATH hack could be used. 2) Statically link the libraries into gpg2 Cheers, Emilio
