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.

The repository contains outdated translations. Before releasing gnupg-2.0.17, I
had been poked by Werner and I have sent updated translation of gnupg2 back.
It's part of 2.0.17 release. You must have stored current translation somewhere
else.

Please use a wrapper for this. The problem with an --language option is how
should we display messages pertaining to option parsing if we don't have the
languages already set. This might lead to a mixup of languages which for sure
will yeild in complains by other users.

I merged it into gnupg where dirmngr now resides. The cs.po file there is
probably out of date anyway though and may need some massaging.

We allwo only algorithms which are implemented. IDEA is not implemented because
it is patented. MD5 is implemented but too weak to be used. We won't allow that.

With 2.1 the keyserver access has been moved to dirmngr and this gives us a bit
of the framework to implement such a feature. The other missing part are meta
information in the keyring - that is also on my short list.

This has been fixed in master for quite some time.

If this XDG_RUNTIME_DIR is supported on most posix platforms we may look at this

again.

Ok, using TMPDIR is great. I hope that 2.1 still provides the --no-use-standard-
socket option. Stating that "an option to specify the socket name does not make
sense because other tools need to find gpg-agent" doesn't make sense, unless gpg-
agent stopped providing $GPG_AGENT_INFO.

Actually I recently changed it to detect misconfigured cross-platform build
systems. All the m4 files are chnage from time to time; it is the same as with
libtool or config.guess.

If this XDG_RUNTIME_DIR is supported on most posix platforms we may look at this
again.

This has been changed in the current version:

Well, so be it then. I can't say I understand the decision (have you considered those
who don't need that unnecessary flexibility?), but I guess I'll just have to continue
shipping gpgme.m4 within the geany-plugins autofoo buildsys. The waf buildsys will just
have to reimplement the check. I don't look forward to the day that you guys decide to
change gpgme.m4 though, assuming that ever happens.

In particular, $XDG_RUNTIME_DIR only allows writing by the user, so if you want
to have a socket with a fixed name and no random component, you can safely do that.

Hence my followup correcting that to $XDG_RUNTIME_DIR, which if set points to a
user-specific writable directory intended for this kind of purpose (sockets and
other runtime files for user-specific daemons).

If you use CMAKE, you need to write your own test. gpgme-config provides all
what you need.

We won't do that. The socket is per user and thus /var/run can't be used (no
sticky bit). In any case GnuPG is moving away from random directories to a
weel-known per-user socket. GnuPG 2.1 will have this as the default.

Correction: this directory should move to $XDG_RUNTIME_DIR (if set).

That's the current approach I'm using, but like I said in the first message, it
feels ugly and hackish.

Okay, I now see what you mean.
autoconf.sh is a mainatiner tool and not a distribution. If your application
uses gpgme, I suggest to distribute the gpgme.m4 in the m4 directory.

I don't understand what you mean. gpgme.m4 gets installed my gpgme and thus the
AM_PATH_GPGME macro is available. There will be no pkg-config support, becuase
cusom config files are more flexible.

For each test we write a log file. What is the content of conventional.test.log ?