Done in commit d3132553 for 1.5. Needs to be fixed in master.

1.6 (current master) now has a feature to switch to a pure /dev/random based RNG.

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

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

D161: 363_obsolete_automake_macros.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.

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.

This problem also happens with gcc if run in -std=c99 mode. It is due to a
change in gcc 4.3. It has been fixed in for stable and master. It is thus
likely that the problem is also solved for clang.

I have implemented your suggestion for 1.4. Check out commit b1abc01 of GnuPG.

Yes, mandatory locks are a problem. LockFile works on a separate lockfile to
implement such an advisory locking. If we would lock the random_seed file
directly reads or writes will fail and we won't be able to lock the creation of
that file.

You suggestion for 1.4. makes sense.

I'm not sure what you mean by "no portable advisory locking in Windows".
There's LockFile()/UnlockFile() as used in the new dotlock code. Would it be a
problem if the locks on random_seed were mandatory locks? If so, then using the
dotlock code is certainly the shortest path to a perfect solution.

Regarding gpg 1.4, however: The reason why I opened this bug is that gpg
randomly fails to encrypt what it was told to encrypt. This is as bad as if it
would be randomly crashing. I don't mind an occasional "note: random_seed file
is empty" message nor a performance penalty from needlessly re-generating the
seed file. Modifying the error handling after read() as I tried to outline in
my previous message ought to be enough to get rid of the random fatal errors.
Do you consider such a change suitable for gpg 1.4?

clang falsely pretends to be gcc by defining GNUC. However, it
does not has the features of gcc. Please fix clang.

Inline is an extension to C90 implemented by almost all compilers.
What we do is what the gcc manual suggest for ages:

   This combination of `inline' and `extern' has almost the effect of
   a macro.  The way to use it is to put a function definition in a
   header file with these keywords, and put another copy of the
   definition (lacking `inline' and `extern') in a library file.  The
   definition in the header file will cause most calls to the function
   to be inlined.  If any uses of the function remain, they will refer
   to the single copy in the library.

I don’t know why clang seems to be the only compiler who does not grok
this. Libgcrypt has been compiled on a wide range of compilers
without any problem.

Wait, I see. Clang pretends to be gcc and defines GNUC. Thus
mpi-internal.h includes the inline functions:

  #ifdef __GNUC__
  #include "mpi-inline.h"
  #endif

which is a valid gcc construct. As with some other bug reports; I can
only suggest to fix clang and don't have it define GNUC .

Funny that several other compilers grok that asm stuff.

That code is only used if compiled by GCC (GNUC >= 4). Now if clang
pretends to be gcc, it needs to make sure to be 100% compatible with gcc.

It seems that my patch does actually break gcc... i'm not sure how to handle
this correctly anyway. It seems that the problem is actually unsolvable, and
there's no correct way to mix inline functions and external assembly definitions.

D154: 346_0001-Fix-use-of-inline-to-avoid-multiple-declarations.patch

tests/basic.c does now test with unaligned parameters.

See http://bzr.savannah.gnu.org/lh/grub/trunk/grub/revision/368{5,6}

Why do you include openssl and other stuff with -I ?

I don't do that on purpose. I guess it's the build system, that does that.

Why do you include openssl and other stuff with -I ? Please show the config.log
file.

2.0.18 has been released and fixes this problem

Libgcrypt does not support 64 bit Windows yet. In particular do not use it even
if it would build and run fine. MSVC is not a supported build platform anyway.

I will shortly release 2.0.18 to address this problem.

Thanks for the answer.
What is the solution right now?
Not use libgcrypt 1.5.0 with GnuPG <= 2.0.17?
Or patch GnuPG?

That's known. GnuPG devel has already been fixed in git (328ac58).

Tested System was Debian Lenny, XEN Instance.
Used command was

gpg2 -b testfile.txt

We should address this in 1.6

We will address this in 1.6. At least for ELF systems supporting the weak
pragma and for W32.

i dont quite understand/agree with the last few comments, but i guess it doesnt
matter that much since the code now uses AC_PATH_TOOL which is all i wanted ;)

Okay, using AC_PATH_TOOL to implement AM_PATH_GPG_ERROR makes sense.
I changed libgpg-error and updated the macro in libgcrypt master.

The idea for a search path for a cross-build environment is not sane. If you
have a cross-build environment then it is easy to set it up correclty. If your
environment is already broken, gcrypt-config could only help by printing an
additional warning, but it will never be bulletproof.

i'm not requesting you install HOST prefixed wrappers. that would actually be
worse since people setting up cross-compile environments already generically
take care of this issue.