Duplicate of T1467

You should read the intro about becoming a registered user on bugs.gnupg.org. I
now changed your rule to User so that you may comment on other bugs.

Please provide complete bug reports. Foe example the OS you are using.

pkg-config variant.

There is also ncurses-config option...

D172: 374_pinentry-0.8.2-ncurses-pkg-config.patch

D173: 373_pinentry-0.8.2-ncurses.patch

What version of GnuPG is that?

We need to see whether we can re-use the code from GPA for this purpose.

For 1.4.1 I reverted the default for to --disable-fd-passing. This should fix
the immediate problem. If you can find the actual reason for this problem,
please follow up and change the status back to chatting.

Given that recent versions of GnupG support IDEA and won't emit such a status
line anymore, I do not think it is justified to fix this for old gpg versions.

Let's assume that the problem was in the glib library and has been fixed in the
meantime. I will soon release a new Gpg4win version with the latest stable glib
version. Feel free to reopen if you still encounter this problem.

Fixed in 0.9.4, coming soon.

Pending for a long time; should be considered for 2.1

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

Tested patches are welcome (against git master of course).

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?

We plan to do something similar for the Informsec grant.

2.0.5 is too old. Feel free to reopne if thatt problems is still in 2.0.19 or
later.

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.

Fixed in master.

Fixed. see T1384.

Fixed for 1.5 and master. Only yet tested for 1.5 on an ultra64 (gcc63).

Duplicate of T1384

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.