[pkg-gnupg-maint] Bug#953800: Bug#953800: gpgme1.0: don't fail checky2106 on 32bit systems

[Daniel Kahn Gillmor]

Control: found 953800 1.13.1-6

If checky2106 will always fail on 32-bit systems, that's a clear
indication that GnuPG will fail on those systems when it encounters
objects that have a timestamp that lands about 86 years out from now.
For example, an OpenPGP certificate with a 100-year expiration date
issued any time in the last 14 years.  Or an OpenPGP certificate with a
75-year expiration date issued 11 years from now.

The test should *not* obviously fail on 32-bit systems, but it is a
combination of bugs that upstream declines to fix:

   https://dev.gnupg.org/T4766
   https://dev.gnupg.org/T4826

I honestly don't know how to resolve this issue correctly, given
upstream's refusal to acknowledge it as a problem worth fixing.  To the
extent that software on debian depends on these systems going forward
while OpenPGP is in use, and they may encounter signatures or
certificates with expiration dates later than 2106, our users *will* run
into this problem, well before 2106 itself rolls around.

i'm working on an update to the gpgme1.0 debian packaging that will
permit the package to skip this particular autopkgtest if it is failing
on 32-bit platforms as long as a certificate or signature created
"today" with an expiration date of 75 years is handled correctly.

This is a reprieve of 11 years.  Hopefully by then either upstream will
have resolved the problem, or either GPGME or platforms with a 32-bit
unsigned long will no longer be relevant to Debian.

On Fri 2020-03-13 17:42:05 +0100, Gianfranco Costamagna wrote:
> also, taking this patch would be so appreciated.

> +    - debian/patches/0006-PIC-and-shared.patch: Libs are -fPIC and -shared.

This is an entirely different matter, and seems related to
https://bugs.debian.org/870383 -- it would probably be better dealt with
over there or on a new bug report.

Has this change been recommended upstream?  Why should debian or ubuntu
carry it separately?

> +    - Add in libgpgme-dev a libgpgme-pthread.so pointing to libgpgme.so, this
> +      will fix the build failures of kf5-kdepim-apps-libs when built against
> +      this gpgme package.

This is also a separate issue, and should probably be dealt with
separately.  Are you sure this isn't a bug in kf5-kdepim-apps-libs, and
not gpgme?  where does kf5-kdepim-apps-libs get the idea that it should
be looking for libgpgme-pthread.so instead of libgpgme.so during build?

   --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/20200624/48a94c4e/attachment.sig>