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.

I would also like this feature. I currently use a pair of subkeys (one for work one for personal projects) and it would be much easier if I could configure gpg-agent to append comments to the keys rather than displaying (none). Perhaps a flag could be added to sshcontrol which allows you to specify and arbitrary comment?

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

I guess for older releases it is less relevant to have very accurate version information. From now on this is more a regular maintenance task than a unit of work, so I am closing it.

Gave it a head-start.

i think it's strictly worse, even when the certificates are "trusted" in sense (1) -- with OpenPGP keyserver lookups, at least it is the client who decides which keyserver to use, on what protocol, to look up the given issuer fingerprint.

Without a committment to code review workflows, this is meaningless.

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.

Won't fix in favor of decentralisation.

I have enabled login again and added the following login hint:
"Login via your Roundup account on bugs.gnupg.org has been disabled due to the migration to Phabricator. We apologise for any inconvenience caused. If you have previously used your Roundup account in this wiki, you can request a new password using the link above."

Retested today: Works again. So I can confirm the resolution of this task.
Thanks @marcus !

As part of switching debsig-verify from using --list-packets to gpg with --list-keys --with-colons and gpgv, it would be helpful to eventually be able to get the fingerprint instead of the keyid. This is needed because debsig-verify uses the keyid to select which one of its policy files it has to load, to apply for the subsequent actual verification of the .deb package.

Now you can do this:

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

The patch was accepted, not abandoned, but the phabricator review workflow doesn't make it easy to change the state without using the arc command line tool. The quickest way to close the issue without review is to claim it myself and "abandon" it. Sorry for the confusion.

What was the reason for abandoning this?

Forgive me. I was biting my tongue.

No new tools.

My comment was only in response to this:

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.

I see at least two different kinds of "trust" here.

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

If the certificate is signed by a trusted root CA, doesn't that mean that we at least trust the URLs in the certificate chain for CRL and OCSP access?

No response.

Fixed in a1d9b046aec8cedda16a9e24eb8d2ed021f68d5d

The server was replaced due to failure. New IP addresses are: 109.235.43.70 and 2001:678:340::70. I updated the DNS entries, and they seem to have propagated (but your local cache may still refer to the old entries).

Techniker ist informiert.

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

Making matters worse, i note that some CRLs, like those issued by MIT's Lincoln Lab are quick and easy to fetch over the Internet directly, but hang or timeout when fetched via Tor.

Debian Bug 842291 shows some performance impact of the CRL checks (as well as the potential for privacy problems).

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.

IMO this would be the first step to have the options we need for EasyGPG.

Kai, as you can see from