I strongly suggest to have an official recommendation how to solve this issue.
The currently available information does not help packagers and application
developers enought to get it right. Probable most distributions should prevent
gpg1 and gpg2 to be installed with their dependency handling.

We won't do it for 2.0 but should consider to do it in 2.1.
The 1.4 commit id is 00310b1aa868cc06cf486fcda6852e9750aa3564

Done for 2.0

No, that is way too complex and will easily lead to a combinatorial explosion.
Both versions should not be installed on a standard system. For migration
purposes this is possible but it should always be viewed as an exception.
gpgconf shall never do that. If there is a problem, the user/admin needs to fix
it. I wish we never had introduced those version specific conf files.

Andre: "gpg --dump-options" is supported for 15 years or so and thus an easy way
to figure out which options are available.

Someone should check whether this has been fixed in the soon to be released 2.0.20.

Fixed in master

Is that still something we should go for?

Well my suggestion would be that gnupg reads configuration values from
gpg.conf-version AND gpg.conf so that one could keep common options in gpg.conf
and write version specific ones to gpg.conf-version.

But with the ignore-invalid-option option we can at last fix this from the KDE
side. Werner do you have any idea how one can get the list of supported options
from gpg 1 in a reliable way? So that one could check which options are
supported by gpg1 or will there be no options added to gpg1 in the future?

Real problems have already popped up years ago:

https://bugs.kde.org/show_bug.cgi?id=226630
https://bugs.kde.org/show_bug.cgi?id=246808

So gpgconf could add, for example, "ignore-invalid-option log-file", to the
configuration file if a log-file option is emitted, and then GnuPG2 would still
honour this option, but GnuPG1 would silently ignore it?

Fixed in master.

Actually we have a solution here since 1.4.13: For example if the conflicting
option is "foo-me", you would put this line into gpg.conf:

ignore-invalid-option foo-me

and gpg will silently skip that option. Of course you need to put the above
line before the line with foo-me.

This has not yet been announced to avoid abuse but if at anytime in the future a
real problems pops up, we will have a workaround already deployed.

This is an application problem. For example KMail renders the signed parts in a
frame with a different color so to visible explain what has been signed. Mutt
has a similar feature. We can't do anything about this in gpg than to emit
certain status lines and to output the signed data.

This is long known problem with signatures and not even the worst. MUAs
introduced ways to mitigate the problems 2 decades ago. The best working
solutions is to use PGP/MIME for mail and detached signatures for other data.

That is okay. One reason for this is the encoding of big integer numbers; if
such a randomly generated number has the high bit set, a leading zero needs to
be inserted.

I agree with Ralf that we need a solution for this.
I can be a multi-step solution.

But right now, most GNU distributions are not putting much effort in
the GnuPG installation and setup help. For example: With Debian squeeze
you cannot deinstall gpg1 because the dependencies would drag down other
software. Yes, this is partly a packaging problem with should be solved on
Debian's side (as well), but if we want GnuPG to be successful we need to offer
users and packagers best practice and clear recommendations.

My suggestions:
a) Make the suggestions more clear that gpg2 only should be recommened only in
almost all installations
b) offer some safety nets if there are both installed and gpgconf is used.

D170: 372_gpl.patch

new version with end enumerate a little earlier.

D171: 371_gpl.patch

This bug is fixed for 2.0.

http://git.gnupg.org/cgi-bin/gitweb.cgi?
p=gnupg.git;a=commit;h=ae22d629b6028aa994ff09f012e1cb029575eeae

If you use --textmode during encryption the native line endings on the
decryption system are used. Adding an extra option to for arbitrary conversions
is IMHO not a good idea beause it violates the Unix principle of having
dedicated tools which work together. tr(1) does what you want.

We still have a copyright assignment policy in effect. Thus I can't accept your
patch right now. This will change in 2 weeks.

Ok, no problem.

Patches should be send to gnupg-devel and not to the bug tracker.

Thanks for information, next time I'll send patches directly there. Should I
send also this one to be reviewed on mailing list?

BTW, HEAD of branch?

master, forgot to mention, sorry about that.

Milan

We still have a copyright assignment policy in effect. Thus I can't accept your
patch right now. This will change in 2 weeks.

Patches should be send to gnupg-devel and not to the bug tracker. BTW, HEAD of
which branch?

Still have this issue. Here is an updated patch against 2.0.19. Please
consider including it, or provide some feedback if this is a bad idea / should
be done a different way.

Marking this as a bug since it restores useful functionality that was lost.

D151: 369_gnupg-2.0.19-showsession-trunc.patch

Am able to reliably trigger the flaw, by using a curl-shim gpg from another
machine on the same network as the keyserver. Close network proximity without
being the exact same machine makes it much easier to trigger the race.

D168: 368_libassuan-2.1.0-solaris-configure.ac-inet_pton.patch

As I said, gpg does not mess around with the encoding. The content is an opaque
data for gpg. Your problem is outside of GnuPG.

Do not use an outdated version of GnuPG.

1.2 has long reached end of life.

Anyway, your problem is corrupted input data. Newer version may give a sensible
error message but neityer woulde abale to decrypt your data.

Thank You for your email.

Do you mean the file name or the content of the file? gpg does not care about
the content and the file name is used verbatim. However, for display purposes
shown meta data (e.g. the informational only file name in the encrypted data) is
converted to the used character set. For any non-attended use you should use
--status-fd to get the meta data which is either UTF-8 (if gpg generated) or
whatever the sending party used.

We are having issues decryting an encrypted file with gpg (algorithm RSA 2048
encryption) when the file has special international characters. The decrypted
file has special characted decoded incorrectly for example
Sadurní as Sadurní and García as García. The gpg (GnuPG) 1.4.5 is installed on
the LUNIX RHEL 5.6 server.
Please let me know if there is patch/version that supports international
characters.

D164: 367_gnupg-2.0.17-gpgsm-gencert.patch

Ooops.

I agree that adding a better message is helpful.
What about something along the lines that says:

"cannot sign with or decrypt with key XYZ"

and explaining:

  "even when trying to decrypt with a different key, 
  the default signature key gets checked."

Certainly it would be much better if decryption would just try to
decrypt with the available keys, no matter of what status the
certificates to this or other keys are. I am worrying most about the
applications that are using Gnupg in this way, they probably will
not be able to either explain this properlto user or offer good
assistance. The reason you give why this is done is only an implementation
artifact and not logical for a user that has learned or tries to learn
about public key cryptography.

I agree that the error message is misleading. What happens is that
gpgsm prepares the keys the decrypt operation and does not distinguish
between decrypt and sign: In all cases where the private keys are
required, gpgsm will check that the configured signing key is usable.

We could remedy this by making this check depend on the intended
usage. However, this is a bit complicated and in any case, your
configuration is wrong. I'd rather say, learn early that your config
files needs an update than to fix the problem.

What about adding a hint "check your config files" to the "can't sign
suing XXX" diagnostics? I don't like to change strings right now. A
diagnostic "please check your configuration (option '%s')" would
generally be useful.

Fixed also for 2.0 and master.

Fixed with commit f795a0d for 1.4. Will fix it for the other branches later the
day.