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.

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

again.

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:

That's not a bug.

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.

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

FWIW, I started to work on another random backend which uses /dev/random
directly. It is not yet finished, though.

Use the pdf version.
An info file will be installed with gnupg.

I fixed that in the README files but won't change it all over the project tree.

We have no way to merge secret keys. Thus fixing this would be very hard.
There are a couple of other problems related to this and we won't fix them either.

I understand (and exactly it is why I do not want use some weak RNG but use
something robust in crytsetup).

This is not possible - pinentry is called from a background task and thus needs
a way to take over the current terminal. A simple command line input would be
too easy to fake by data to be processed. If you really want this, please write
your own pinentry.

ok, please close off this bug and I will move to latest version.

We don't continue 0.9.x. Thus I don't want to fix that problem unless you have
a real need for it.

The first part is not easy to fix and would require quite some rework. I don't
think this is justified.

Forget the second part. It prints this message only, if it indeed needs input
and giving --yes works in this case too. So there was a fault on my side.

Maybe we misunderstood(?). The gpg-agent is not used.

What you want to do is to make the configuration depend on the input data: The
keys are input data. This is not acceptable.

This has been discussed several times on the mailing lists. You can't do that
because gpg needs to ask several questions. There are too many choices for a
command line mode. --sign-key makes it only easier in the most common cases. A
--force option won't help because you don't know which user ID you are going to
sign.

also sprach Werner Koch via BTS <gnupg@bugs.g10code.com> [2009.05.06.1111 +0200]:

Nope. Featurism without clear semantics. Use something like this

#!/bin/sh
fpr="$1"
shift
gpg --options myconf/gpg.$fpr.conf "$@"

The coupling to secmem is why I propsed this for pinentry not for GTK+ itself.

I assume you want to change $HOME/.gnupg to something like $XDG_DATA_HOME/gnupg.
Obviously this is not a good idea because ~/.gnupg is a weel established
standard for more than 10 years. We can't change this just for the purpose of
easier backup. However, there are simple workarounds like setting
GNUPGNOME=$XDG_DATA_HOME/gnupg or by using a symlink.

I understand. Such a diagnostic is of course possible.

If we use "--multifile --sign", we got an error message:
gpg: --sign does not yet work with --multifile

This would be too complicated to fix. It is not just --passphrase but also
--use-agent which gets into the game.

Please wait for the final release of Gg4win 2.0 which incldues a completely
reworked GpgOL.

No, it can't be. The exit status is not sufficient to convey all required
information. IF you want that you need to use gpgv along with a keyring of
trusted keys.