Use

gpa --version

on the command line. We have the rework of the help menu on our todo list, thus
I close this bug.

I know, however the checks do only basic checking and reject more exotic
addresses. Actually the specs don't say anything about the format of a user ID;
it is just a convention that they resemble a mail address.

GnuPG Shell is, and always has been, released under the GNU General Public
License.

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

I searched for '-'s and they are only on the BEGIN and END message lines. The
encrypted file is over 350K, this is the tail of the file:

There is some garbage at the end of the file. I can't tell you more without
seeing the encrypted file. ctb=2dmeans that a '-' has been detected. A possible
reason for this is a broken MIME parser.

Thank you for the information, with it I will be able to alter behaviour on the
fly (via system variable) but anyway, it would be really great gpg could pass
an argument -- I think it is a bit more elegant way to control the behaviour.

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.