Implemented in c4506f624ed6854aa0ba1629aa2d1d43eb26900d.

We are in feature freeze and changing the status code of gpgv will likely cause problems for gpgme. We need to defer this.

In fact, on Windows you would need to have a system service. We did this in the past for the dirmngr but remove that feature due to possible security problems and problems during installation.

I encountered this bug again in production while creating keys on an air-gapped system that had the wrong time zone configured. I consider this kind of problem grave and embarrassing, but we failed to agree on a way to fix it in the foreseeable future.

That is correct, gpg-agent does not daemonize on Windows if --daemon is given, it is simply not implemented.

Stephan released revised document which should fix this.

It looks like this was on my side. I can't reproduce it anymore; in other words dirmngr survives changes to DNS servers now.

Just for the protocol: This fix made it into the 2.1.22 release. Thanks a lot! (bug has tag "gpg22" though)

debug dns

log-file whateveryouwant

You're right, stat() works correctly. I created a small tool that implements the same logic. For some reason dirmngr is still not able to find the DNS server after suspend/resume in combination with changed locations. I still get "no route to host" errors.

According to POSIX stat(2) follows a symlink and thus /etc/resolv.conf is the right name to use. (To stat /etc/resolv.conf itself lstat(2) would need to be used. ). I just checked the macOS man page and it says nothing to the contrary.

Unless --quiet is used we now print

Can now be found in the 2.1.22 man pages.

2.1.22 released - the plan for 2.2 is end of August. But it is just a plan.

That is due to your fix for T2236 where you reused the code from keyedit which was intended to work only on the console.

FWIW, using a Debian specific thing is not portable and Unix sockets won't work on Windows. Thus using the standard localhost connection is simpler than adding extra complexity.

Okay, I implemented the second part and Tor is now used if availabale.
--no-use-tor disables Tor.
--use-tor forces use Tor and can't be reset.

rG166d0d7a2439f30c0a250faadc16ce3453447d71 is a first take on this. It is not complete but should be sufficient for now.

I'd like to hear a little more about the use cases we imagine for Anonymous OpenPGP certificates.

In T3284#100822, @werner wrote:

No. gpg-agent is a different implementation of the ssh-agent protocol than ssh-agent. Making the keys persistent is on purpose.

Fixed in e7fc6e3bf0eb6ffe53e1f099d28ce45cef4a8a87.

No. gpg-agent is a different implementation of the ssh-agent protocol than ssh-agent. Making the keys persistent is on purpose.

Hm. Could you elaborate on that? Why do you think it's dangerous?

I consider allowing empty user ids too dangerous.

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.

Implemented in da91d2106a17c796ddb066a34db92d33b21c81f7.

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

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.

But that is not very user friendly. I wasn't aware of that way to list and delete keys for example.

Note that you can do

There are two issues here.

Fixed in b231959728a0056094134e0fca8cc916c24ef37e.

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

Maybe for 2.2?

Sorry, I went through considerable length to reproduce this, but failed.

Hi Justin

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.

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.

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.

Thank you very much for addressing this so quickly. I agree that corrupt data needs no further details here.

Thanks. Indeed we should have better error codes. However, passing all error codes from the backend to the user is not useful.

I am using Debian 9 with the packaged versions. For gnupg this is 2.1.18.

@aheinlein we need to know the gnupg version you are using with GPGME.

Agreed, i think the OP is asking for X when he wants Y, so that makes this request a little bit strange.

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:

I'd prefer a 2.2 release.

Note that the documentation clearly says that --nameserver expects an ip address. Now we could make it accept a port too, but that would not make the OP happy, as he wants to talk to localhost, but in tor mode, all dns requests are routed through tor (this is actually one of the main motivations for using a custom DNS resolver).

This is not specific to Python, and it may not even be a bug in GPGME, but in gpg. Needs some more investigation.

OK, I pushed my fix into master.

The canonical repo is git://git.gnupg.org . We have not yet mirrored it at dev.gnupg.org.

Since there is no news for the last two weeks, I am wondering: am I the one blocking the situation here? Are you waiting for me to do something to make progress?

I added a new task status "Testing".

On Wed, 28 Jun 2017 15:47, noreply@dev.gnupg.org said:

What tests do you want to be done?

What tests do you want to be done?

Given that we have no TESTING status, the only way I can handle this is by keeping the ticket open and add the TESTING flag. Closing a bug which has not been tested is a bad idea.

I'm going to close this task now. If we need more options to be configurable, it is easy to open another task for them.

@werner An open ticket should mean there is something that can be acted upon. Unless you are saying that we should actively look for regressions or should actively do more testing, this ticket should be closed now. There is plenty of peripheral information that will remind us of this ticket in case more issues resurface related to this change.

seems this was fixed along the way, then. I only tested with 2.1.18.

I can't remember either. We should swicth back to mailing lists for such things.

Anyway we should not allow empty user ids.