D163: 365_mpi_longlong_h.diff

Also in other GnuPG related software. Just fixed for GnuPG 1.4.

Fixed with commit 37f1a42. Tested on a Power7 box. I guess we need to do a new
release soon.

try starting pinentry with these options (ASSUAN commands) where $TTY and $LANG
are correctly set in current environment

OPTION ttyname=$TTY
OPTION lc-ctype=$LANG

I know, it will be update before a release. Thanks for the reminder.

No. See the discussion on the maling lists for the reason why we limit the RSA
key size to 4k.

Again a warning: Do not propose the use of such large keys. The end effect is
that people don't use encryption because it is too slow on non-big machines.

Argh, the IDEA source is really old.
Sorry for not testing it on, say a PPC.

D162: 364_gnupg-1.4.13-big-endian.patch

idea.c uses wrong #define to check for big endian architectures

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.

D161: 363_obsolete_automake_macros.patch

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.

See the Topics field above: wontfix.
The feature request has been rejected. If you still want to pursuit it, please
start a discussion at gnupg-devel and don't contine here at the BTS.

Not ure to understand you comment...
Have you added support for XDG basedir spec?

Add more complexity to the already complex configuration.

Fixed also for 2.0 and master.

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

My guess: Whoever wants to use said certificates would add them bey themselves …
I don’t see the need for adding them by default.

Do we need to do something for 1.4?

Because I was able to verify the origin of these root certifciates. But see the
comments. The German signature law imposes some strict requirements on
qualified signatures; despite that GnuPG is not certified, it is prepared for
such a certification.

To me this is still a bug (why only some more or less random German CAs only?).

Finishing things up now.

Note that this implies setting Host: properly as well

Please notice that backward compatibility can be preserved by continue to use
$HOME/.gnupg if it exits but using/creating XDG dirs when it is not exit.

That would be incompatible to previous versions and is thus not an option. If a
user wants this GNUPGHOME provides an easy way to do so. Keys should be
considered part of the configuration.

David, what is the status?

Sorry, we can't do anything about it after a release. Delete the com-certs file
and the keys and you are done. Anyway, expired certificates are required in
X.509 - for example in the chain validation model.

Without a real example file, I don't think that the problem can be
reproduced. Thus I'm closing this issue because of the lack of activity
for more than 12 months.

Matter: Thanks for the report! As Werner suggested: Please ask on the
mailinglist if you continue to have problems, until we can somehow produce a
test case and then somebody is able to file a new report.

That is actually a gpg*sm*.log. However, I am not sure whether a gpgme log will
be helpful. I need to replicate the problem first.

Note that the topic is currently under discussion on gnupg-devel.

Taking

D160: 360_pinentry-gtk2.patch

Fixed in master and 1.5 by adding an aligned attribute to RIJNDAEL_context.
However, this is not portable becuase we do this only for gcc. To mitigate the
problem I will replace the ifdef GNUC by a macro figured out by configure.

That was fixed by
2010-11-11 Werner Koch <wk@g10code.com>

• agent.h (opt): Add field SIGUSR2_ENABLED.
• gpg-agent.c (handle_connections): Set that flag.
• call-scd.c (start_scd): Enable events depending on this flag.

and thus 2.0.19 should work fine.

Thanks to gniibe for mentioning this.

Yep, you should have mentioned the aligned problem in the selftest. I don't
follow the gentoo tracker if we are already discussing here. I will soon look
at the problem. A new 1.5 release is anyway due.

Gentoo thinks about patching its package with their own solution till an
official fix :
https://bugs.gentoo.org/show_bug.cgi?id=442568#add_comment

Gentoo devs identified an issue in the source code :

Please build it with a stock compiler and standard options (i.e. none). Same
problem? No, then add options until you get the segv again.

TIt is a 3.6.6 vanilla kernel of a stable Gentoo with 3.6.6 vanilla kernel and
gcc-4.6.3 (+ Gentoo patch set), all options are here :
https://bugs.gentoo.org/show_bug.cgi?id=442568#c0

and there's the complete build log attached too (gzip'ed - the mime type might
be sometimes not recognized correctly)

Please provide more information, in particular: the OS Version, the compiler and
all options used for building.

quick bisecting gave :

tfoerste@n22 ~/devel/libgcrypt $ git bisect bad
83f80d39c3feddc7e055525d47dcf3f069801e89 is the first bad commit
commit 83f80d39c3feddc7e055525d47dcf3f069801e89
Author: Werner Koch <wk@gnupg.org>
Date: Tue Feb 15 14:38:02 2011 +0100

    Change more AES-NI code into plain asm

:040000 040000 5f3aef9e672defe8feeec28e4c6aa2b810c7e0e8
01816387886d3d8e832d0a97e1e0f1a984fa9256 M cipher

I'm not able to reproduce the problem with commit b1abc01. It was reproducible
with the preceding revision (commit a74f05c), so I can confirm that b1abc01 has
fixed it.

Fixed for 1.4.13 (95347cf9).

Fixed for 1.4.13 (e3e5406)

Do you still have this problem with 1.4.12?

Fix for 1.4.13 (commit 64e7c23).