This is the current development version of GnuPG.
Details
Thu, Aug 21
Well, I will re-use this as a feature request to add this feature. Workaround is to list the key with --with-keygrip and backup the ~/.gnupg/private-keys-v1.d/<keygrip>.key files.
Fri, Aug 15
Wed, Aug 13
We decided that gpg should emit a status message for success, too.
gpgme should then look for that status message instead of only absence of error.
A quick check with passing ASSUAN_PIPE_CONNECT_DETACHED does not changed anything.
Tue, Aug 12
I wonder whether rA3bccb33ccd9028ff505d9979fd6c8a37393b892d which changes Assuan's waitpid function for Windows is well aligned with the my_waitpid in gpgme's assuan-support.c (which does nothing). gpgme creates a detached process in most cases but for gpgsm assuan_pipe_connect is used without the ASSUAN_PIPE_CONNECT_DETACHED flag.
Another data point is that the faulty versions use libassuan 3 with a slightly changed API. May one of the follwing chnages cause the problem?
Mon, Aug 11
Although in VSD 3.2.2 we get no warning when configuring S/MIME debugging wrong we then get a nice message "Configuration error" when trying to encrypt with S/MIME, instead of gpgsm hanging without any message at all:
Fri, Aug 8
The issue also occurs in VSD-3.3.2 and 4win-4.4.1 but not in VSD 3.1.26
Thu, Aug 7
Mon, Aug 4
The advantage of using a fingerprint for referencing a key is that there won't be any collisions in the keyid. Further this unifies the schema with an LDS (Windows) installation where DNs must anyway be unique. But take care the client needs to support this new flag. This will be the case for gnupg >= 2.5.12 (cf. T7756)
Applied the change above.
I realized that I enbugged in rG5efabec21883: gpg:ecc: Use the common function of gnupg_get_ecc_params..
It has been regression since 2.5.9.
Fri, Aug 1
Test on Windows by overwriting gpgtar from gpg4win-5.0.0-beta357 and also tested on Linux. Debian packages with patches are already available.
There is a new --keyserver-option update-before-send which is enabled by default.
Thu, Jul 31
Wed, Jul 30
tested with Gpg4win-5.0.0-beta357 (GnuPG 2.5.11):
Note that 2.5.11 fixes a regression in 2.5.10 regarding the use of notations for 3rd party signatures. See T7743
Tue, Jul 29
The card returned these 32 bytes:
1883ba0d1cacda6f357ad9caa062ebd7b3a07291a7788565caf38973bf414286
agent_card_pkdecrypt however returned 33 bytes:
411883ba0d1cacda6f357ad9caa062ebd7b3a07291a7788565caf38973bf414286
Thus the indicator byte is 0x41. The specs (librepgp, rfc4880bis) say: