Today
Yesterday
To reproduce the hang, a loop will suffice (usually happens within the first 15 times, once it needed 50 runs):
This is still open. It cannot be tested because Gpg4win still doesn't use KIO::move on Windows (because the above patch has not yet been merged).
There's no other configuration, this happens with a clean gnupghome with one smime cert + root cert and the above gpgsm.conf (output on stdin/stderr):
I think this is still open (and requires T6537: Make KIO::move work on Windows when moving between different partitions).
This is not yet fixed. KDE still applies a patch to gpgmepp (and gpgmeqt) to ifdef a few GCCisms.
Sun, Jan 25
@werner I added an implementation https://dev.gnupg.org/D622
that matches Linux behavior and avoids the message about secure memory not being supported on Windows. The change is scoped to the pinentry tool and intentionally follows Linux behavior. Does this approach look reasonable to you?
I think "O" is a better key:
We need to change the accelerator. Right now gpg-agent uses
Sat, Jan 24
Fri, Jan 23
I don't think that we will implement that any time soon. Today we too often require more mlock-able memory than available and in this case Libgcrypt resorts to allocating new memory arenas which are not locked. This is not as worse as one might think: the majro advantage with secmem is that a free() on secmem allocated memory will also wipe that memory. A better solution has always been to use an encrypted swap/paging file. 25 years ago, it was not easy to configure but today there should be no problem and hopefully already the default.
Please run with --debug 0 which should show you which confiration files are read in which order. Is there anything in a common.conf file? A log-file statement tehre would overwrite the command line option.
While key generation works now with an expiry date up to 2106-02-04, the representation on the command line is a bit ugly.
Current state needs to be tested
@ikloecker: Is this fixed?
Current state needs to be tested as soon as T7509: gpg4win: Make the AppImage build work with the new Docker-based build script is resolved
@werner: Is this resolved?
We need to test the current state
this seems obsolete
Thu, Jan 22
Fixed and backported for VSD 3.4
Backported for VSD 3.4
I have split out the "Tab navigation in the Smartcard Dialog is broken" issue because it's unrelated to this ticket: T8051: Kleopatra: Tab navigation in smartcard table is broken