[pkg-gnupg-maint] Bug#933713: libgpg-error-dev: make package fit for cross development

[Daniel Kahn Gillmor]

On Sat 2020-03-07 16:17:36 +0100, Francois Gouget wrote:
> On Wed, 12 Feb 2020, Daniel Kahn Gillmor wrote:
>
>> On Tue 2020-01-28 13:01:04 +0100, Francois Gouget wrote:
> [...]
>> > So I think it is reasonable to stop shipping gpg-error-config, just like
>> > FreeType stopped shipping freetype-config to become multiarch-compatible.
>> 
>> I agree that upstream's preferred configuration mechanism
>> (gpg-error-config) is not well-suited for the modern multiarch world.
>
> But is gpg-error-config upstream's _preferred_ configuration mechanism 
> or merely the legacy one?

I haven't been able to get a read on that, but i note that GnuPG itself
(made by the same people) appears to be using gpg-error-config.  See
m4/gpg-error.m4 in the GnuPG sources.  They use the idiosyncratic
--with-libgpg-error-prefix= as an argument for doing cross-builds.

> I did not try. But any package that depends on a multiarch-incompatible 
> xxx-config script is broken imho.
>
> Now an alternative to removing gpg-error-config is to make it 
> compatible with multiarch. The only differences between the two copies 
> are:
>
> -libdir=${prefix}/lib/x86_64-linux-gnu
> +libdir=${prefix}/lib/i386-linux-gnu
> ...
> -           output="$output -L${prefix}/lib/x86_64-linux-gnu -lgpg-error"
> +           output="$output -L${prefix}/lib/i386-linux-gnu -lgpg-error"
>
> The -L option is not needed on Debian so it might as well be omitted.
>
>
> -               host) echo "x86_64-pc-linux-gnu" ;;
> +               host) echo "i686-pc-linux-gnu" ;;
> ...
> -            echo "x86_64-pc-linux-gnu"
> +            echo "i686-pc-linux-gnu"
>
> This one is the real problem. Maybe it can be derived from some other 
> source. Or maybe removing support for host would have less impact than 
> removing gpg-error-config entirely.

I agree with you that these things are not aligned with modern
multi-arch packaging, and are problematic today.

> Wine normally uses GnuTLS. But GnuTLS is missing support for ECDH public 
> key encryption. From the patch that triggered this:

This is a mystifying claim.  GnuTLS has supported ECDHE for ages.  It
just supports it for TLS sessions.

Maybe you're saying that it doesn't offer the cryptographic primitive
for non-ephemeral ECDH encryption.  But that's reasonable, because
modern TLS doesn't do encryption to static keys.  GnuTLS is not a
generic crypto platform, and it doesn't claim to be.  It claims to be a
solid TLS implementation with a sensible API (which it is!)

> https://www.winehq.org/pipermail/wine-devel/2020-January/157434.html

This seems to be talking about wanting to do something other than TLS.
It's not clear why wine would want to adopt libgcrypt if they're already
using GnuTLS, which uses nettle for its cryptographic toolkit.  Why pull
in another reverse dependency?

> For now this patchset is on hold to not add a new dependency to Wine.

Wine should just use nettle directly instead of growing a dependency on
gcrypt.

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20200309/659e6944/attachment-0001.sig>