Fixed in 94eea0ed2c8b47cb0fe02b22cbe668705a5fe0d0

.

gpg 1.4 only gets important updates.

This is solved easily by using "--yes", which sets the force flag on the DELETE_KEY operation. This prevents gpg-agent from doing a confirmation.

Here is what Vinay Sajip wrote:

Thanks, fixed in 01c68a6a.

According to the link above, the reason we need entropy on import is the KEYWRAP between gpg and gpg-agent. The reason we are stalling is that we use getrandom() and the urandom pool is apparently not initialized on that system.

The beta is not released, but maybe Andre can make use of that info.

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.

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.

We now strip trailing slashes (and backslashes on Windows) when setting the home directory with --homedir and when retrieving it from GNUPGHOME.

I would say this is okay now. We switch to the Windows system directory which is unlikely to have non-ascii characters. If we ever need to change this, this can now be done in gnupg-chdir and the new gnupg_daemon_rootdir functions.

This needs to be changed. See the comments for the commit.

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.

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

@marcus From my memory, importing private keys with passwords requires passphrase. Is this not a case in recent versions? What when you have some private keys in keyring and you import more private keys? Isn't the access to private keyring password protected in GnuPG 2.1 as I thought?

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.

The diff was commited. A general review of the ldap fetching on Windows is still pending but I think this can be resolved for now and we revisit this topic when we see new problems.

The fixed sed expression still does not work correctly; it misses the plain "-O" form of the option. As per gcc docs, -O is the same as -O1, and clang accepts it (and the build falls over with it) even though it does not document it at all.

The warning is just a warning, so no problem. The pragma even indicates the compiler for which it is intended.

as a quick fix something like the attached seems to avoid the immediate issue{F166535}

This test failure is already fixed with 1.9.0, so close it...

I've been informed that this apparently is an enigmail-bug: https://sourceforge.net/p/enigmail/bugs/687/

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.

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.

The other thing is to allow only one keyring, or better, use a central key daemon to access keys (kind of local keyserver).

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

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).

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.

Isn't it much nicer if we semantically convey that a key doesn't have associated user id information, compared to just listing such keys between "Andre" and "Arnold"? I'd much rather special case the empty string in the key list than an arbitrary string that may or may not have a universally obvious meaning.

So, just use "Anonymous"? This clearly identifies what this user id is
about and does not lead users to think, that something is wrong.

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.

I think "anonymous" user ids are a valid use case, since openpgp doesn't allow "no" user ids. Disallowing zero-length user ids will just cause implementations that intend to use anonymous user ids to use another type of "empty", like a single space character. And the effect of that will be that it's no longer trivially defined what an "anonymous" user id is for special handling, e.g. showing a localized "anonymous key" placeholder. Please don't restrict zero-length user ids.

Just noticed that we fixed something related to this in 1.4:
bb61191aad98c3dbb487c1f76dd1552d44a52fe3

Hmm, that is actually the original file. I received it by mail, maybe the sender's MUA added the BOM.

Fixed in rC1d8e4c2c3a7d: Remove byte order mark.

Thank you for the report. I think that there is a https://en.wikipedia.org/wiki/Byte_order_mark in those files.

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

gpg imposes limits on the length of data items in OpenPGP messages. OpenPGP does not specify any requirements on the length of keys or other properties, thus implementations can use sensible limits.

Fixed in b231959728a0056094134e0fca8cc916c24ef37e.

User IDs of length zero do seem to be in compliance with RFC4880.

No. But as of 3.0 GpgOL for Outlook 2003 and 2007 is no longer maintained and the support for this will be removed in some future version. This bug only affects new installations of GpgOL on the unmaintained (by Microsoft) Outlook 2003 and Outlook 2007 Versions. So -> Wontfix.

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.