Re: the way to enigmail: gnupg 2.1 backport considerations
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
Reply to: