gpg-connect-agent is used by gpgconf to make things easier. Adding socket playing games is the opposite of simplifying things.

Yes, it will be in 2.2.3. It's too late for 2.2.2.

So is 380bce13d94f the correct fix? If so, I will update the OpenBSD port including this as a local patch.

This is a bug in gpg-agent.

Done. Will go into 2.2.2.

What I use to force the old keyring format is to export a public key to a file and rename that to pubring.gpg. And of course delete the pubring.kbx.

This is suuper useful! I can see there is a pSUBKEYEXPIRE, but no para_name for this. Can an expire date be passed for a subkey via Subkey-grip?

Yes, I put the tag of gpg2.2, as it's useful to compose key from external source.

Shall we mark that for backport to some 2.2 version?

What do you think about a special case for the homedir "/dev/null" ? We use this device as a specila value at other places too. I have often seen "/nonexistent" in /etc/passwd but there is no standard for this. However, /dev/null is well defined.

D441 applied. Closed.

agreed, generically changing this check to log_info doesn't make sense. However, in *this circumstance*, gpg actually has no error.

$ gpg --homedir /notexistent -dv <1.msg --override-session-key 7:D6E1027D58A0CB047C41EA881A137197 --status-fd 2 
gpg: keyblock resource '/notexistent/pubring.kbx': No such file or directory
[GNUPG:] ERROR add_keyblock_resource 33587281
gpg: public key is 7F3B7ED4319BCCA8
[GNUPG:] ENC_TO 7F3B7ED4319BCCA8 18 0
[GNUPG:] ERROR keydb_search 33554445
gpg: encrypted with ECDH key, ID 7F3B7ED4319BCCA8

Indeed, this makes gpg return 2. The reason is that the first error message uses log_error which sets a flag to have gpg return 2. Now, changing this to log_info may produce problems for applications which expect that gpg errors out for a bad homedir.

Oh I see you did the Right Thing which back then I was too lazy to do. Thanks.

can you try it with --homedir /does/not/exist

I would consider this feature request. Right now you can do this by providing an empty keyring.

I am pretty sure that older cards required this behaviour. It might have been a workaround for a bug in scdaemon, though - I am not sure. So we should test this with all available card versions.

I close this for now. If you run into problems with 2.2.2 again, please re-open this bug.

rG3b66a256e376: agent: Allow recursive use of pinentry. fixes the test case above.
I wish it doesn't cause any other issues.

OK, I can make reproducible error case:

Verified that the fix works, I can create subkeys now.

Thanks!

The obvious fix to unlock and relock the pinentry during the callback would have the problem that instead of the confirmation request a pinentry from another connection may pop up. That would be quite confusing.

I moved most of the output to the debug category. Everything elese does not make much sense. I also fixed the stats printed for each reordered/fixed key to be prefixed with the keyid so all info is on one line. -q should fully silence them.

The trust-model=direct does not care about signatures or user ids. It simply checks the user assigned _ownertrust_ to decide whether a key is valid:

Just tried this but can't replicate it:

$ ../g10/gpg -dv <1.msg --override-session-key 7:D6E1027D58A0CB047C41EA881A137197 --status-fd 2 
gpg: public key is 7F3B7ED4319BCCA8
[GNUPG:] ENC_TO 7F3B7ED4319BCCA8 18 0
gpg: encrypted with ECDH key, ID 7F3B7ED4319BCCA8
[GNUPG:] BEGIN_DECRYPTION
gpg: AES encrypted data
[GNUPG:] DECRYPTION_INFO 2 7
gpg: original file name=''
[GNUPG:] PLAINTEXT 62 1508859245 
[GNUPG:] PLAINTEXT_LENGTH 68
"Well hello there Charlie Brown, you blockhead."
                -- Lucy Van Pelt
[GNUPG:] DECRYPTION_OKAY
[GNUPG:] GOODMDC
[GNUPG:] END_DECRYPTION
$ echo $?
0
$ gpg -k 7F3B7ED4319BCCA8
gpg: error reading key: No public key

Is this still a problem with 2.2.1? IIRC, we fixed a few DNS things.

What I use to force the old keyring format is to export a public key to a file and rename that to pubring.gpg. And of course delete the pubring.kbx.

This can be triggered if --max-passphrase-days has been set.

In 2.2.2 you will see "Secret sibkeys are available" and commands which require the primary key are disabled.

gpgme does not known about return codes because it uses a double fork approach. However, certain staus lines could have the same effect.

Hm, perhaps this non-zero return code is due to not being able to write to the GNUPGHOME directory, actually. It goes away when GNUPGHOME is writable. That doesn't make sense either -- this operation doesn't actually depend on being able to write to GNUPGHOME, so it shouldn't return a different error code if GNUPGHOME is unwritable.

I am closing this bug report, as I can't get feedback to fix something.

DCO = Developer's Certificate of Origin. See gnupg/doc/HACKING under "** License Policy" .

We can't change that anymore. So the question is how and whether to fix it. Right now gpgconf --list-dirs has no need to ask gpg-agent for the actual socket and it would be a catch-22 anyway. Thus to fix this we need to parse the gpg-agent.conf in gpg.conf directly.

No, I used the standard Windows command line

Thanks for testing. Did you try with a powershell?

Tried this on Windows 8.1 (x64) with GnuPG 2.2.1 (libgcrypt 1.8.1) and was not able to reproduce it.

I tried to replicate this but failed. Well, I am on Vista and standard cmd.exe. Can you please try your tests again on a standard cmd.exe shell?

Well we could of course also add code to gpg-agent to verify the card key but the fix I just pushed fixes the problem more easily. If we ever want to implement PASSWD --verify for card keys (which has a couple of side effects) this patch won't be in the way.

@gouttegd provided a patch to implemented that policy. I setup a server server to check this:

gpg -v --fetch-key https://test.gnupg.org/testurl/redirect-to-http.html

This comment in the gpg code is relevant for the bug:

/* Verify the passphrase now so that we get a cache item for the
 * primary key passphrase.  The agent also returns a passphrase
 * nonce, which we can use to set the passphrase for the subkey to
 * that of the primary key.  */

Hello.
I am having the same problem with my Yubikey v4.

That is a server error - the redirect is under the server's control and if the server advises to connect via http we should do that. Well, unless our policy is to not allow such a redirect - such a policy makes a lot of sense of course.

Raising priority so that we have a chance to review this for the next 2.2 release.

OK, I changed my own purpose. I don't touch internal representations.

Committed to both branches (master and 2.2), so, closing.

The new unified compliance checker was not initialized. Fixed in the 2.2 branch.

I'm fine with (and i totally understand) wanting nothing but UTC in the machine interface and internal representations.

[copied from gnupg-devel@]

I think any existing script that assumes UTC should add an explicit Z suffix. (that is, i don't think the breakage is a big deal, and anyone writing scripts that needs this kind of precision will be more likely be thankful that we have a sensible, normalized interface).

It is pretty much confusing. When a user specify in YYYY-MM-DD format with no hh:mm:ss, it is interpreted as local time (noon of that day).
When a user adding Thh:mm:ss, it is UTC.

While I confirmed that GnuPG interprets YYYY-MM-DDThh:mm:ss in UTC (which should be interpret as local time according to ISO-8601), I don't know how we can fix this.
If I change the interpretation of GnuPG (possibly supporting the format with Z suffix and timezone), it may break existing script which assumes UTC.

Bug confirmed in rGa766a37290cf: Print keyid in gpg --list-packets..

When Thhmmzz is specified, no adding 12 hours, that's the intention of the code, I suppose.
However, the implementation is wrong, since the beginning (not supporting "Z" or timezone for ISO-8601. interpret the string as UTC).
I will take that, too.

Is it possible that this is related to T3278 ?

I think that adding 12 hours by parse_expire_string make sense.
The test suite should be fixed.
I will.

fwiw, i agree that GnuPG should interpret these as ISO-8601 strings. At the very least:

Nice find, @gniibe ! So this looks like a bug either in GnuPG's test suite, or in parse_expire_string, right? How do you think it should be addressed?

In the log, I found:

Possibly, timezone (of build machine) matters.

GPGME does not use gpgv. What Justus likely meant is that we would need to change the common code used by gpgv and gpg. That may give problems in GPGME.

Can you describe the problems it would cause for gpgme? gpgme already currently expects that gpgv will return a failure for signatures made before the validity window of the key. so gpgme won't break just because gpgv is capable of returning a non-zero response.