Sufficient workarounds have been found.

It takes a couple of seconds for dirmngr to terminate after closing the last connection, maybe due to the timeout in the pselect call. Apart from that, it works as expected.

It's not really a good idea to use the same RSA key for encryption and signing. (Although when I wrote scute, I couldn't generate a CSR for the encryption key, because the CSR had to be self-signed, meh).

Well, the 16 byte fingerprint is used for MD5 (old v3 keys). Those aren't supported by default anymore, but the comment indicates that discerning existing entries is difficult.

What catches my eye is that emergency_cleanup() is not guarded from being invoked twice in the way that got_fatal_signal() is.

Besides -v, --status-fd 2 (for example) also shows useful information, as usual.

You get more information with -v. Because a key can have multiple subkeys, this is not so easy to fix, because at the point that we decide that we can't build the signature we don't have all the information on potential key candidates anymore.

The last time GOOD_PASSPHRASE was emitted was in 67934a8c1 (parent of 21b0a955) in 2010. I think that's just water down the river at this point.

A decision must be made what the desired behaviour should be.

Homedir is an obvious choice, but I don't think make_absfilename adds a drive letter. Another idea is to use GetWindowsDirectory() or GetSystemDirectory. Note that chdir is deprecated by MSFT, hence _chdir.

Ah, yes, this can happen, see T2313. With --batch, this can be avoided, and I added the NEED_PASSPHRASE with 872137b59.

This works in recent 2.1.x versions, so let's close this here. 2.0.x is going EOL soon and won't get non-critical changes.

Can somebody test 78ebc6260 under Windows? I think this would fix it.

Werner implemented --output in a8363b7d0bcc77b55226d5fe8f972214c968ddc3.

Thanks, I fixed this in d8e46f106 for export-secret-keys. I am not sure how/when import asks for a passphrase. Please clarify if that is still an issue and reopen the report (or create a new one).

We can't reproduce this with recent versions and would need more information.

Deleting a secret key does not delete the public key, which can still be edited. This is normal behaviour. You can use --delete-secret-and-public-key to delete both at the same time.

Fixed in e4c720fa3.

It is not supported to pass arbitrary information through gpg and gpg-agent to pinentry via environment variables. You will probably find good use of the pinentry-mode=loopback option.

One problem I see is that S/MIME doesn't standardize sign+encrypt, but requires nesting of those operations, leaving it up to the implementor to pick the order etc. From an interoperability point of view, this seems like a world of hurt if you take this out of the context of MIME.

Do you have a use case?

I fixed the initial-import case in 609bbdf3614fbadeba7a6cbdfdf5004b23516a64. I could not reproduce the export case, for me the export using export-clean is different from the normal export. Maybe it got fixed in an unrelated change, such as 356323768a1a29138581d0aceed0336ab8be0d5c. If you still experience issues with export-clean, please reopen.

Your report does not have a lot of information, but I tried the settings dialog in gpa and kleopatra. gpa does have a upper checkbox for advanced settings, and it works as expected. This is with the latest version.

Given that 2.0 only gets important updates, and for 2.1 it is fixed, we can close it.

So it seems that accessing through gpg-agent is the better solution.

See here in current code. https://dev.gnupg.org/source/gnupg/browse/master/g10/keygen.c;cea4313644b531ef87b8c8e4bfddde4388cbbe0d$2375

GnuPG allows an ISO date at the prompt since 1999, see bd7298cf0d, but it is not apparent from the prompt (hidden feature).

Changing the message affects all translations.

Fixed in cea431364.

I couldn't reproduce this, but even if I could, there would probably be nothing we could do about it (in case there was locking going on, it is necessary).

I tested this with "--full-gen-key" (RSA sign only) and "--edit-key"/"addkey" (ElGamal encrypt key) and at the second step it only asks once to unlock the key.

The upgrade path problem could be alleviated by this: Add support for a new locking order to gnupg, but don't use it by default. Then, after a couple of years, activate the new locking order in the configuration, so that systems with multiple versions of gnupg installed use the same locking order as long as none of the used versions is too old.

As long as the cache of the reader is short-lived, I don't see a problem. The operation started before the writer, so it can use the old data to finish. Any other policy could lead to other problems (for example, a long sequence of writers could starve a reader that tries to refresh due to cache stealness). So, IMO, only if you keep long-running gpg/gpgsm processes around (maybe in --server mode?) you could have a problem.

According to this, setting LD is not sufficient to make gcc use a different linker.

Well, we don't maintain a wiki, so I think this should be tracked elsewhere.

With commit 9998b162b47931fb8a8ed961d53418d505358888:

GnuPG tries to create its _default_ home directory because this is the common case. Creating a home directory in every case would clutter the disk with gnupg related data which may even be sensitive.

In 3ef0938cfd8637e9801369f142eb8dd564f2ca61 --allow-loopback-pinentry became the default.

Implemented in f17862d47.

Should be resolved. Reopen if it is still an issue.

@aheinecke did you change the default?

werner says it's not a bug.

gpgtools will have to update.

werner said this won't be fixed.

gpg 1.4 will now only receive important updates, and this is a change in behavior, which might break scripts.

This has been improved by e467a000f87e87582f5838964b6f1e0a960d4445

In addition to Werner's concerns, making network requests to unverified URLs can be harmful in many ways. For example, it would allow a third-party to detect when the signature was verified, among other even nastier things.

Maybe for 2.2?

I don't know if decryption method was changed, but at least the "can't sign using" message appears to be unchanged yet (from looking at the source code).

werner said he doesn't like the proposed solution, so this is a wontfix.