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.

Frankly, I still do not understand the problems with cross-compiling. Since 2014 we support SYSROOT and the respective foo-config script is installed as $SYSROOT/bin/foo-config. This guarantees that a matching config script is used and because it is a script it works on all platforms from which we are cross-building. It is also fine to install that very script in the bin dir of the (target) host; it will work there as long as host is a Unix system. So it does not matter whether it is a plain text file (a la pgk-config) or a POSIX script. The only important thing is to really install the foo-config at SYSROOOT/bin - make install does it.

It seems to be a cpp problem. Andre, would you mind to take this bug?

Release today.

Just commited. Thanks.

The next version will have a details button to show the actual gpg output. This will often be helpful.

The current version is 0.9.10 and the reported 0.9.5 is 4 years old. We also received no more info.

The "Copy" menu item already copies public keys to the clipboard.
I now added a private key key copy option to the context menu.

Thanks for the report. I would also like to see what

I will disable your account but destroying the account and all data is not possible because this has public interlinked content. The intro page at dev.gnupg.org clearly explains this as welll as the privacy policy linked from the side menu; excerpt

The pages of the Verein shall use a different layout than the general gnupg.org pages.

Please put

Editor fault. The browser's editor is not like Emacs and here o my laptop the backspace key does not work as intended. I guess I was about to write ".. a back signature's usage flag".

The fix was not fully correct because it considered a back signature's usage tool.