Re: the way to enigmail: gnupg 2.1 backport considerations
On 2018-11-20 15:19:45, Ben Hutchings wrote:
> On Mon, 2018-11-19 at 15:48 -0500, Antoine Beaupré wrote:
>> On 2018-11-13 22:02:45, Ben Hutchings wrote:
>> > On Tue, 2018-11-13 at 12:31 -0500, Daniel Kahn Gillmor wrote:
>> > > On Mon 2018-11-12 15:16:39 -0500, Antoine Beaupré wrote:
>> > >
>> > > > * libgcrypt20 (part of GnuTLS, 1.6 -> 1.7)
>> > >
>> > > libgcrypt is not a part of GnuTLS. GnuTLS has used nettle instead of
>> > > gcrypt for years. gcrypt is more properly "part of GnuPG" than anything
>> > > else.
>> > >
>> > > basically, all of these libraries are gnupg libraries.
>> > >
>> > > It's a little bit distressing that upstream's attempt to split them out
>> > > as distinct libraries (which i think was intended to make them more
>> > > useful to other consumers) might be a roadblock on the way to updating
>> > > GnuPG itself.
>> > >
>> > > Ben's suggestion of shipping them in a non-default location ("vendor
>> > > bundling"?) sounds pretty dubious to me -- i wouldn't want to reason
>> > > about (let alone vouch for) the upgrade path from such a hybridized
>> > > variant of jessie to standard debian stretch myself.
>> >
>> > I was thinking that those libraries would be included in the same
>> > binary package as /usr/bin/gpg2 and other executables, which would all
>> > have a run-path set. No-one should need to set LD_LIBRARY_PATH so no
>> > other executables would use those libraries, and the libraries would be
>> > removed when the executables that use them are removed or replaced.
>> >
>> > Since gnupg2 actually spreads executables across multiple binary
>> > packages, I realise the libraries would have to be an additional binary
>> > package and that would remain after an upgrade. But it would be
>> > harmless cruft that "apt autoremove" would deal with.
>> >
>> > (I assume that GnuPG 2.1 would be packaged as "gnupg2", replacing GnuPG
>> > 2.0 since that is no longer supported upstream. If not then I do see a
>> > problem of how to make, say, gnupg2.1 in jessie upgrade to gnupg2 in
>> > stretch. But that's independent of the library issue.)
>>
>> I think this is overengineered. I still haven't heard exactly what the
>> problem would be with upgrading those libraries. They are present in
>> jessie-backports and presumably well tested.
> [...]
>
> Those updated library packages are installed and used by people that
> specifically choose to use GnuPG 2.1 in jessie. I don't think we can
> assume they are well-tested in conjunction with GnuPG 1.4.
My understanding is that GnuPG 1.4 does not use those libraries at all,
and from what I can tell, gpg 1.4 does not link against them either.
A.
--
On reconnait la grandeur et la valeur d'une nation à la façon dont
celle-ci traite ses animaux.
- Mahatma Gandhi
Reply to: