This is the dependency graph:

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.

In addition to what I said above - the patch comes with two small side-effects - The size of the content in the tab is constant over the tabs, so that even a page with not very many settings will show a scrollbar, even if it only makes it possible to scroll in empty space from below.

I have made a patch for this, that add scrollbars to scroll up and down in the settings. This adds the need to set a default window size, which I have set to 700 x 500, which seems fine. Tested on a relatively low-resolution machine (1366 x 768), where it seems to work fine for me.

While we have no way to express possible range of values in structure member, we can do something like this (which is not needed actually, if the gmtime function returns correct value).

Here is the warning:

../../libgpg-error/doc/yat2m.c: In function 'isodatestring':
../../libgpg-error/doc/yat2m.c:373:29: warning: '%02d' directive writing between 2 and 11 bytes into a region of size between 4 and 11 [-Wformat-overflow=]
       sprintf (buffer,"%04d-%02d-%02d",
                             ^~~~
../../libgpg-error/doc/yat2m.c:373:23: note: directive argument in the range [-2147483647, 2147483647]
       sprintf (buffer,"%04d-%02d-%02d",
                       ^~~~~~~~~~~~~~~~
../../libgpg-error/doc/yat2m.c:373:7: note: 'sprintf' output between 11 and 36 bytes into a destination of size 16
       sprintf (buffer,"%04d-%02d-%02d",
       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                1900+tp->tm_year, tp->tm_mon+1, tp->tm_mday );
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

iirrc, that are memory mapped files.

@werner
This was an issue we talked about.

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 )

There were two ways to access the registry and the config value load did not fallback to HKLM. I've removed the second way and I've tested it and it works now as it uses the codepath with the fallback.

Thanks for the quick reply!

Thanks. I've never seen that, so my test definitely did not test moving junk mails.

It doesn't work too.

Hi,
As for getting Help, we all speak German ;-P

Thank you for the feedback. Very strange, that should have been solved indeed and in my tests it works and I also got feedback from other reporters who had that problem with 3.1.3 that it works in 3.1.4.

I'm also seeing the same behaviour on a freshly installed Windows 10 1809 with Gpg4win v3.1.4. Have to kill dirmngr from task manager to be able to get into Kleopatra.

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.

Apparently, it is not the bug of gpg, but you just specified wrong line in your /etc/apt/souces.list.d/skypeforlinux.list, where filename extension .gpg is irrelevant.

Done for libgpg-error.
Will extend to other software.

Applied to master: rE91bcb2c7d824: gpg-error-config: Support "auto", architecture independent script.

It is propably related to decrypting large (single) tar-files. It works flawlessly when renaming the tar-files to another extension before encrypting and afterwards decrypting it again. But as long as it is named xyz.tar Kleopatra crashes. Could it be that untarring causes some "out of memory" failure? I recognized that while decrypting the tar there was no sign that the decryption process would allocate any disk space. There is just an empty randomly named folder being created upon decryption.

Thanks for taking the time to create this report. It should be fixed in Gpg4win-3.1.4 please try out that version. :-)

Related, the tab formatting (mixed first one tab and then space), as in lines 131 to 137 of src/icons.c _really_ causes headaches.

Nesting the op_genkey() calls inside try/except statements with the exceptions being caught as "oops" and otherwise "oops" being set to None provides a means of checking whether the 2099 expiration is a problem and 2037 is not.

Well, I guess this answers my question in T4192 regarding why op_genkey was in use.

Interesting, I'll look into it, but is there a reason for using op_genkey instead of create_key (optionally with create_subkey and/or key_add_uid)? The latter should be easier and more pythonic.

In T3354#118876, @justus wrote:

This should already be possible, iirc the Arch Linux maintainer patched
it in. I believe there is a 'prepare' target that takes care of all the
preparations (duh), and then you can build for every Python version by
executing the Python build system with the Python version of your choice.

@werner, thanks for rMff6ff616aea6 -- i've backported it to debian's packaging and it lets us cleanly build against all installed versions of python.

Almost the same bug also happens with pinentry-tty.

Sorry, pressed enter too early. the bug report is complete so far. I guess it is a lot of work to reproduce, so I'd try to be very responsive instead.