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.

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

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.

Note that current versions don't install a skeleton conf file anymore.

I just verified that this is indeed fixed.

@marcus sure, but I am currently away on vacation and won't be back until mid August. Also, I'd need some detailed build instructions (I'm on mac os) since I'm not very familiar with building C code - I brew installed gpg.

Hi Justin

In T2923#100519, @dkg wrote:

including these tests (or something similar) in the gpg test suite would be a good way to avoid future regressions.

this discrepancy is easily explained. You are entering a date that is interpreted as UTC, and it is echoing it back using your local time zone. PST is UTC−8:00, matching the output.

Can you provide samples that highlight the problem?

I'm re-opening this ticket because i think Valodim has clarified what he meant, which is different than what werner closed the ticket for.

including these tests (or something similar) in the gpg test suite would be a good way to avoid future regressions.

Note that T2923 includes a patch that might help.

My point is that without clear documentation of what is expected, it's pretty hard to tell whether the code is even working or not. Sounds like it isn't :(

Is this correct?

I don't think this issue is actually resolved. there's a feature here (i think) but it's not documented to the point where anyone can figure out how to use it. If there's no way to use it, the feature should be removed (or at least deprecated).

Ah, ok, thanks for the info!

Likely fixed by commit a4d1595a2638db63ac4c73e722c8ba95fdd85ff7 (rijndael-aesni: split assembly block to ease register pressure) in 1.7 branch (and included in 1.7.3+).

I tried to find evidence that such a change ever landed in 2.0. I now believe the mistake is in the NEWS file. As 2.0 is nearing EOL, we won't backport this.

Well, yes, it's not general authentication like AE provides, didn't think this through entirely. However, handing encrypted data to gnupg and then not being sure if it was actually decrypted with a passphrase makes even the confidentiality property questionable.