Please try again with a recent version of GnuPG. We had a dozen more releases since 2.1.11 and we can't spend time on trying to replicate bugs which may have already been fixed in the last 18 month.

So it fails after a timeout. Which probably means that the conf->sync calls timeout which probably means that some gpgme process call to gpgconf hangs. Maybe some IO Flush that does not happen correctly on MIPS. But this is pure guessing.

Talked with Jochen and tested this. Jochen's test forwarded the mail so he ran into T2854

Unfortunately, even building for two Python versions is a bit of a hassle with the existing autoconf framework for Python. I did that when porting the Python bindings back to Python2 after we decided to also support 2 so that people could start to use our bindings even if they still need Python2. I don't see us extending it for more versions.

Merged, thanks for the reminder.

I can't reproduce this issue. I've imported the attached mail with KMail and synced the folder to outlook.
GpgOL did decrypt the mail. It did not set the category correctly (These were two other bugs which I've fixed now) and displayed the wrong status information but decryption happened.

I suspect this is a duplicate of T3253, where the same behavior (non-floating pinentry dialog) was observed under both the i3 and the Awesome tiling window managers. This bug has been fixed in master and the fix will be part of the upcoming pinentry-1.1.0 release.

this is also https://bugs.debian.org/866555

This is probably broken since Werner enabled descriptor passing by default in 5090f6f24. The analysis in https://dev.gnupg.org/T2919#99901 is correct, but it's not enough to put the operational error in the right place. Also, the calls to _gpgme_wait_one have to be replaced by _gpgme_wait_one_ext. The change overall will be somewhat destabilizing.

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