The compiler folks are breaking all assumptions C hackers used for decades :-(
The benefit is a little performace improvement which might be outweighted by the
bugs introduced due to the code changes required to to use gcc specific stuff or
even memcpy everything forth and back.

Libraries are a part of the application. Hiding all details of a
library is simply not possible. You suggestion does not work either;
because switching the thread system is not possible: Either you are
using thread system A or thread system B; A can't switch to B, because
it does not know about B's internals.

FWIW, I started to work on another random backend which uses /dev/random
directly. It is not yet finished, though.

FIPS requires anyway a specific machine and a specific built binary.

Already fixed, will be in 1.5.0

I don't agree. Your program might install HOST-prefixed tools, our programs
don't thus I can't see that as a but. You need to pass the correct
--with-gpg-error-prefix option. The GnuPG related software does this for 10
years or so.

The manual clearly states:

Already fixed in git master.

AC_PATH_TOOL will fall back to gpg-error-config, so the default behavior is
unchanged. AC_PATH_PROG however will wrongly select the host's gpg-error-config
which breaks cross-compiling. it isnt up to random packages to manage the HOST
prefixed tools, so the gpg-error package not explicitly installing it is
irrelevant. cross-build systems take care of creating the wrappers automatically.

D143: 316_libgcrypt-tests-ldadd.patch

http://pkgs.fedoraproject.org/gitweb/?p=libgcrypt.git;a=blob_plain;f=libgcrypt-1.4.5-ImplicitDSOLinking.patch;hb=HEAD

Given that we don't install a HOST-gpg-error-config tool, it does not make sense
to look for it.

The given patch URL is not valid.

Fixed in trunk and 1.4. Thanks.

I understand (and exactly it is why I do not want use some weak RNG but use
something robust in crytsetup).

No, this would violate the design of the RNG. It is already hard enough to come
up with good random and we don't want to weake it anymore.

I am sorry but this is really misfeature rather than a feature. So you basically
say, that if caller of libgcrypt does not want to having it mess with uids and
capabilities it has to copy over about 600 lines from the secmem.c just to
delete the few calls?

This is not a bug but a feature. If an application does not want this behaviour
it needs to register its own allocation handler.

See for example here:
http://code.google.com/p/cryptsetup/issues/detail?id=47

will be in 1.4.5 to be released in a few minutes.

According to the wrieshark tracker, this has been solved.
Fix will be in 1.4.5.

Okay, for the development version I implemented a configure option
--disable-O-flag-munging
This is in the SVN trunk, rev 1415.
I believe that is the least intrusive change. Is it important for you; thus
shall I backport it to 1.4.5 which will be released in a few days?

Sorry, this is not a help line.
Ask on the gcrypt-devel ML or get commercial support.

A bit more of context is required. OS, CPU, libc version, etc.

I have implemented the mentioned checks for CTR in libgcrypt trunk, rev 1414.

As suggested I have excluded the ID 17 on W2000 systems. I never had this
problem on my W2000 system, so I can't test whether this is sufficient. Please
try the test dll at:

Hello Werner,
Thanks for your response. I have installed libgcrypt through depot file in
unix system and it has been install successfull only thing is it doesn't allow
us to provide any configure option. Can you please guide to me where I can
find EGD package tool compatible to HP-UX 11i?

seems related to the use of --enable-hmac-binary-check

Applied. Thanks.

We won't do any changes to 1.4 anymore. You need t wait for 1.5; sorry.

You were right, of course! Thanks for the tipp, which revealed it immediately.
Please close this ticket.

That is a warning to tell you that you called a regular Libgcrypt function
before gcry_check_version. It auto-initializes Libgcrypt as a workaround.

Right, such code should have a comment or use an assert instead. Thanks.

Is it possible to match at most one occurrence of a pattern without the "-r"
option? ("extended regular expression", a GNU extension unfortunately)

That's fine, I am always worried when seeing such dead code that the logic at
this place became wrong

Sure, you are right. OTOH this code is in use by gnupg and libgcrypt for many
years without problems (twofish.c used similar code).