Duplicate of T1384

Marking as resolved, as this seems to work fine now as far as I can tell (I'm
certainly happy).

scrypt has now been implemented.

D167: 370_scrypt.diff

Done in master.

Ah yes, that Serpent case again. We have a fix for that but a brief inspection
made me believe that it will only happen if the serpent.c code is used outside
of the Libgcrypt. It is an alignment problem. Please give me a few days to
prepare an updated patch.

I just verified that the issue only appears on 64 bit sparc, all others like 32
bit i386, 32 bit sparc and 64 bit amd64 work fine, so it is most likely a byte-
order issue.

Argh, I did quite some fixes for the 1.5.1 release and assumed that I applied
this one as well. Now pushed but too late for 1.5.1 :-(. However, there is no
need to use automake for a released version.

You are using version 1.4.5 and not 1.5.0.

Two hints: Your are using the Solaris as and ld - better try with a native GNU
toolchain. You have some global CLFAGS set which add a lot of extra and useless
include paths. Please remove them.

I close the bug because it is pretty old. Feel free to re-open it if you have
newer info and tried with 1.5.0.

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.