Done. Thanks.

In general I don't like pkg-config because it adds an extra dependecy above the
required libraries and introduces other problems. However, for GPA we already
have lot of dependencies and thus I would accept a patch.

I will stay prepared for any testing or debugging that might be requested by
anyone of you guys (but it might take a week, as the reader belongs to someone
else), such a warning could have saved lots of time for each one of us.

And, only for your files, I made a mistake in the first E-Mail I wrote Ludovic:
It's not a Cherry ST-1044U, but a Cherry XX44 smartcard reader (ST-1044U seems
to be the USB-Descriptor)

Would be great to have included if 2.1 is the ecc release.

I would love to just have 1 agent for everything.

There is no ECC support for the agent, yet. The ssh protocol is different from
the OpenPGP Protocol. It should be easy to add support, though.

Done for master (f1e1387).

Done for 2.1

D152: 342_gnupg-2.0.18_show-session-trunc.diff

Backport to 2.0 done (f772757e)

Backport to 1.4. done (cfb193a1).

You need to use another pinentry. It is easy to write a pinentry which allows
this. I won't do this becuase it defeats the actual purpose of pinentry.

(Understood there are no immediate plans for a release, but if/when we do have
one, the change will be ready)

Change committed to 1.4, 2.0, and master.

I'll setup a testing enviroment soon again and keep you informed!

Okay, fixed in master commit ea9df94. Goes into 2.1 Thanks.

I don't quite understand your point here. In any case GpgOL is not abale to
send encrypted mail via Exchange.

We don't have any plans for a new release.

please explain why this is a problem

Can i get an update on where this patch stands? I'm concerned that people are
actively sniffing around the idea of crafting duplicate short keyids:

I tested this patch, and it does in fact change the behavior as requested.

I think this is fine. I originally wrote the code to send short keyids as pksd
couldn't properly handle long keyids or fingerprints. As pksd is now dead, and
sks properly handles this, I think it is reasonable to send the longest ID
appropriate (send fingerprints if we have them, long keyids if we have them, and
short keyids if we must).

Also changed for 2.0 - will go into 2.0.18.
Also changed for 1.4.

All implemented for 2.1.

concerning the prompt: would it be possible to look up and display the key name
from id_rsa.pub, either at ssh-add time or at confirm time? i might remember
remote host fingerprints, but locally, those names are the best description.

Good idea. I started to implement it for 2.1. Tehre will be flag in the
sshcontrol file named "confirm". Need to compute the ssh fingerprint to
resemble the prompt ssh-agent prints (internally we use our keygrip style
fingerprints).

Fixed in master.

We should address this in 1.6

We will address this in 1.6. At least for ELF systems supporting the weak
pragma and for W32.

Both done.

If a recipient has more than one key - for instance outdated keys, needed for
decryption of older messages, it is sometimes difficult or impossible to make a
mail application encrypt with the correct key. Recently I fought this one, and
got around the problem in both KMail and Thunderbird by demoting the Trust
status of the older key, but although this works it's not ideal for the
following reason.

I merged in the translation to the gnupg package, where dirmngr now resides.