Now you can do this:

I know exactly what you mean, but werner disagrees so that's not going to happen.

Forgive me. I was biting my tongue.

gpgme_data_t are first class objects with an API to create and destroy them, and some articulated rules how to use them (only one thread at a time). gpgme_key_t objects can not be created but only be returned with gpgme_op_keylist_next.

It's been a month since last release, no error reports so far.

No response.

Perfect! This works exactly as I wanted. I indeed use Fedora 26, adding this line below to my .bash_profile works perfectly with the Yubikey to find the gpg keys on it and use it for ssh.
export SSH_AUTH_SOCK=$XDG_RUNTIME_DIR/gnupg/S.gpg-agent.ssh

It wasn't a natural thing to do gpgme_op_import because i already had my gpgme_key_t object, which i was using to display an index of available keys to the user.

Please use the systemd unit files as shipped upstream. This allows the agent to be launched automatically whenever someone tries to use one of its sockets, but doesn't pre-emptively launch the agent until needed.

In T3331#101967, @werner wrote:

If you don't have a TCP enabled OS, you can use configure --disable-dirmngr.

Hi. You can start gpg-agent using gpgconf --launch gpg-agent. I'll delegate the systemd questions to Daniel.

One way to prevent this mechanically would be to store an identifier for the gpgme_ctx_t object from which the gpgme_key_t object came inside the gpgme_key_t object itself, and then verifying that the keys really came from the same context. But such edge cases seem to be quite rare, and I'd hope that most developers make a tacit assumption that objects stemming from a specific context can not be repurposed in a different context ad lib.

Why wasn't the natural thing for you to do gpgme_op_import?

I'm not sure i understand why i'm "chasing a ghost" -- i'm reporting the experience of a developer (me!) who tried to use gpgme, read all the docs, and was still surprised and dismayed by the metadata leakage.

To make this work again, I think gpg-agent needs to cache the public key or support batch-operations (which would require some restructuring in gpg to request such a batch-operation).

Turns out that 2963 fixed this at the same time.

You are chasing a bit of a ghost there. The operation was originally added for GPGSM to support the IMPORT --re-import command that removes the ephemeral flags from certificates that were previously imported as a side-effect of an external keylist operation. That's where the footnote comes from.

Thanks for the improvements, Marcus!

This bug is still present in 2.1.23.

Most of your concerns seem to come from the "move keys" wording, which I removed. I also fixed the return values. The footnote is specific to X.509 peculiars.

Done in 274609ba.

Fixed in 977fc5f0e.

I just tried on an up to date fedora 26 system, and could not reproduce this.

Maybe ask on a mailing list for help to find out why your environment is broken.

Funny. We should make show-unusable-subkeys the default to detect such flaws ;-)

With the exception of Windows, we only provide source code. Thus you need to compile it for your platform yourself or a find a distribution which comes with GnuPG.

I tried on a fresh installation of Ubuntu 14.04.5 and could not reproduce the problem. Apparentlcy your test suite tries to link against an installed version of the library, which is very odd.

Thanks for your report. Indeed this accidentally was broken in the last release. Fixed now. As a workaround copy libintl-9.dll to libintl-8.dll and rename it back in the portable directory afterwards.

This is not about faked-system-time, nor about misconfigured systems, it is about gpg using uninitialized or invalid data. This is one instance of that problem, and there could be more. I'm sorry if I failed to communicate this.

Also note that --faked-system-time is a debugging aid and nothing you should use under production. A wrong system time is a security problem anyway because it invalidates assumptions gpg takes. A small clock skew is annoying but the way to avoid is is easy enough.

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.

I'm closing this. Feel free to reopen the bug with more information.

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

No worries :)

I'm sorry; given the original error message

[-- Error: decryption failed: Invalid value passed to IPC --]

I thought it was the same problem I was having.

I see your point.

BTW, dirmngr has an option --disable-ipv4.

If you don't have a TCP enabled OS, you can use configure --disable-dirmngr.

ah, great! sorry i got confused :)

Can you provide a patch for our version of the libtool macros that only adds support for illumos?

I only removed the documentation in the STABLE-BRANCH-1-4. Nobody said we want to remove this feature, and it is still documented in STABLE-BRANCH-2-0 and master.

fwiw, faked-system-time is used in several non-gnupg packages in debian already.

I just removed the paragraph (gpgtwoone is not used anymore anyways). Fixed in eb15d5ed8.

Please ask any Unix sysadmin for help. Paid support is available from the companies listed here: https://gnupg.org/service.html and there are lot of others.

It's actually --no-use-agent:

Hi Werner,

libgpg-error is a placeholder project for the master version of our libtool, but all other packages are likely to be affected as well.

The platform is illumos, a fork of OpenSolaris.

I think you should take this up with the support of your in-house web service, and if the developers of it find a bug, they can report it here.

This looks suspiciously like T1547: gnupg >= 2.0.21 won't build on OSX 10.8.5 with XCode5.

No response.

No response.

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

For me, it works. Please re-open if you still have any issue for NetBSD.

Well, at least this works without changing the environment:

Thanks for the update, any fix for above issues not able make and make install

I don't know. We only provide binary packages for Windows.

could you tell me how to download direct binary pkg which we can directly install for solaris 10

dcfb01959802 looks much better, thanks for the review. All tests passed.

below also failed to make .

HI Werner,

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

That's it. I can reproduce this on Debian.

Reverted.