We can't do that because gpg2 requires gpg-agent (not to a 100% right now but
eventually there will be no way without gpg-agent). Pinentry is a property of
gpg-agent and you can control which pinentry to use by using a symlink or
gpg-agent's option --pinentry-program.

See the previous comments. This is not a bug.

You are wrong. My system operates correctly. Think chroot() (so no /dev) +
ligcrypt then. But if it was discussed then EOT.

The current svn trunk features a user provided trust anchors. Thus if a CRL
could not be validated just because the trust anchor is not available in
trusted-certs/, dirmnngr will casche the CRL anyway and ask back whether the
user trusts the trust anchor. The latest GnuPG implements the counterparts
which uses the /.gnupg/trustlist.txt to answer this.

No, we don't want to do that. If you do not like this use the option:
--allow-freeform-uid

Right, email addresses are unique, but the key-email association is not unique.

Email addresses on the Internet *are* unique. The option is too easy to misuse,
especially for a security program where selecting the correct recipient is
crucial. But, whatever. GNU.

Thanks. I have added it to the website
http://www.gnupg.org/documentation/guides.html#other . It will show up by
tomorrow.

The GNU project does not list proprietary software as GPG-Shell

That is not a bug - but a feature. For PGP/MIME messages GPGol uses its own
MIME machinery. Running this for the preview window would be too cumbersome.1

The first is a problem of the distribution. Distributing gpg2 without a
properly installed pinentry is just stupid.

That is very likely a matter on how the passphrase has been created. It is
known that WinPT at some point changed how it encoded passphrases.

Oh, interesting. How do you plan to handle common problems like no pinentry
configured (or even installed because distros don't make gnupg depend on it) ?

gpg2 can't use that as the agent is a hard requirement. The only reason for
keeping the passphrase callback is for symmetric encryption.

I understand your conclusion. I know nothing of GnuPG's demographics other
than what I might guess. If there are a number of users who may be unaware,
then I think that it might be helpful information to include somewhere. I do
think however that to introduce change in the software because of a lack of
knowledge would only contribute to the continued lack of knowledge.

x: Do you agree with my conclusion?

Ok. Thanks for your attention and patience.

Latin-1 defines those as application specific. Some terminals actually use them
as control characters. Thus when filtering any output to do no harm it is
better to escape them too.

Because --with-colons is not for humans.
The specification says that the output is utf-8.
Haveing this variable would add an additional burden
to each consumer of --with-colons output to convert it.

Ok. I see.

We install all the documentaion we consider as useful. If you do not like that,
delete these files after installation.

Because --with-colons is not for humans. The specification says that the output
is utf-8. Haveing this variable would add an additional burden to each consumer
of --with-colons output to convert it.

I think whether --disable-nls is exclusively related to the software may be a
matter of interpretation.

Why? Why not to use --charset to set encoding? Why escaping is needed if this
mode (with-colons) is not appointed to diplay( isn't it?) but to get keys
information to applications?

Your keyring is corrupted. You better get a backup.