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.

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.

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.

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.

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

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.

With commit 9998b162b47931fb8a8ed961d53418d505358888:

T3252 is about meta data for each key.

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.

Implemented in da91d2106a17c796ddb066a34db92d33b21c81f7.

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

Implemented in f17862d47.

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.

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.

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.

Another reoccurring concern is lingering agents spawned in test suites. See, e.g. a discussion from this week: https://github.com/pazz/alot/pull/1081#issuecomment-315131053

Well, we always have to weigh the costs with the benefits. From the description of the task, the benefit was to satisfy "people [who] really don't like having idle processes lying around", which is not a strong motivation to take implementation and maintenance cost of any solution.

This is a disappointing resolution. There are many other reasons for having a daemon, which include keeping a sensitive piece of data in memory (and not on disk) for a limited period of time, while providing controlled access to it. This is exactly what gpg-agent does.

Thinking about it more broadly, i think that gpgv (and gpg, when used in signature verification mode) should have a return code that is as close to the true/false underlying semantics that users will want, rather than relying on status messages to distinguish between these cases.

for expiration (or for revocations flagged "key was superseded" instead of "compromised"), you can have a signature made *before* the key's expiration/revocation, but you might be verifying it *after* the key was revoked/expired.

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

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.

I added a note to gpg-preset-passphrase in 877a321d011deb3e8501aa9cc5e9f9cd0b19dddf.

Nobody provided a better description, so I am closing here. Of course, we can still add one if somebody wants to improve it.

Landed in 67cd81ed90ad88cbe607b7f7d1a0b1e08b8ac1f1.

The revert was done in 7195b94345b0bb937477dc47fc5ec27fb108a099.

Without the necessary info, we can not act on this.

Sorry, I expressed my concern poorly. gpg does recognize the keys as being expired/revoked, but this is not reflected in the exit code of the gpg/gpgv process.

@landro Would you like to do one more round of testing?

Werner's comments indicate that this is expected behavior. Also, concerns were raised that this is difficult to implement correctly, and it is difficult to test. So, I am closing as wontfix.

Without a strong use case, I am closing this feature request. It may well turn out that like --allow-emacs-pinentry, the best solution in each case will be to add specific options, and then a generic pass-through will never be required. And we don't want to add features just in case somebody might need them in the future.

Given that 2.0 reaches EOL in 6 months and the bug has been here for ages, I won't backport it to 2.0 anymore.

I don't think that's what we want. An OpenPGP certificate has a claimed temporal validity window: from the creation date of the certificate to its expiration or revocation date.

So both gpg and gpgv seem to return success (as in the exit code is 0) if the signature is correct, even if the key is revoked or expired:

We have to check what happens here, because list-sigs should be fast.

--with-fingerprint is an option to modify the output of --list-keys and not a command. There are other --with-xxxx options for other purposes. There is no command to list a keyring. This is why gpg meanwhile prints a warning when used without a command.

I don't think anyone is suggesting the use of gpg without a command. However, use WITH the --with-fingerprint command seems to be broken. Thank you for providing a correct way of doing what we want, but please either explain why the use of the --with-fingerprint command isn't working, or put this back as a bug.

The use of gpg without a command is simply wrong. This has never been specified and could actually lead to surprises.
You need to import the key first and then look at it with -k (--list-keys) or --fingerprint.

Yes, please please raise the priority on this. I just spent 15-30 minutes looking through tons of emails on lists saying to use --with-fingerprints and wondering what the heck was wrong with the people posting that until I saw this bug. Please raise priority, please fix.

The sqlite backend was a little experiement that I did and it will not be merged.

In T1938#99890, @marcus wrote:

It's unclear from the discussion if this issue has been resolved.

It's unclear from the discussion if this issue has been resolved. @werner can you please comment on this?