The correct technical term is OpenPGP Public Keyblock but I better shut up on the certificate vs. Public key(block) question.

Thanks

Thanks.

Thanks.

Thanks.

Thanks.

Thanks

Thanks.

Thanks. May also happen if the first print_assuan_status fails.

Fixed in 1.8

Fixed in 1.8

yat2m updated. Thanks.

Thanks.

Thanks again.

Thanks. Not a real world problem now but needs to be fixed.

Thanks. There is an easier solution for this, though: I now trim trailing LFs.

May I suggest to use a (new) gpgrt-config instead of the current name libgpg-error-config. The long term plan is to change the name of the library.

Thanks. Fixed in master. Needs backport.

Thanks. Fixed in master.

Thanks.

Thanks. That code is from 2001 and whne I changed to another time representaion in 2003 (due certs with 40 years expiration time) I missed to changed that condition.

Thanks. I added these files.

iirrc, that are memory mapped files.

Can you please be so kind and show the compiler warning? I can't see any fault in the code unless the OS is broken.
Instead of that change I would suggest to change the sprintf to

snprintf (buffer,  sizeof buffer, "%04d-%02d-%02d",
          1900+tp->tm_year, tp->tm_mon+1, tp->tm_mday )

I am sorry about this but the hkps pool has load problems because only a few servers are left. You might have a better chance getting your key uploaded by configuring another pool. See https://sks-keyservers.net . The admins are aware of the problem but there won't be any short time solution.

Thanks for the reporting templates; would mind to fill in some bug details?

That is up to @BenM

The default mode of the tool is to use the Native Messaging protocol which prefixes requests and responses with a 32 bit native endian length header. It is the default due to the way browsers call native messaging programs. If you want to use it in a different way, use the option --single or --interactive.

That it will not be a problem on that or near that date but already now because some use expiration times of 20 years.

See T4195 for the general problem

I have not looked at the new error but the year 2099 is clearly a y2k38 problem. gpg has some precautions but I have not checked the key generation code. The gpgme interface uses a signed long for the expiration time, although that it parses the dates received from gpg as an unsigned long. Right now, I am not sure why we did this because an unsigned long would just work. Maybe we can change or enhance the interface. But in any case this is a general problem and not specific to this bug.

@BenM thinks that swig is still the best option. Actually this case helped to find a bug in gpgme. See my next commit.

That swig based interface is not really robust and it can't be because it does not known about API requirements. I bet there are other places where mandatory parameters are not checked.

FWIW, you should better not change the build-aux/ files becuase they are supposed to be updated from libgpg-error.

Is this new in gpgme 1.12 or might it also be in older versions?

That is a different python binding than what we provide with gpgme. Our gpgme based binding is called "gpg" and was formerly known as "pyme". I strongly suggest to install gpgme and not to use pip because the "gpg" module over there has not been updated for quite some time.

From where did you go that "python package gnupg==2.3.1" ?
Sorry, I can see what kind of Python code this is. It is not part of GnuPG, though.