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).

Let the compiler remove it. I added this comment:

Hmm - I can't explain why this would have affected 1.4.4 but not 1.4.3, but that
is my experience.

In general we try to avoid direct tests for OS features but use configure tests.
However in this case it is simpler to always include sys/time.h. This is
harmless because gcrypt.h does it also unconditionally.

I don't think that it is a regression in Libgcrypt because the problematic rule
was not changed. Did you change the CFLAGS passed to configure?

On further inspection I figured that it is not a unaligned problem, which would
clearly be a bug, but a restriction that the function works only onh full
blocks. This is the same as with CBC mode with the little difference that the
CBC mode detects this and returns an error. The most straightforward fix would
be to detect this usage error in CTR mode too.

Fixed in revision 1373. I don't think that this needs an extra test becaise the
error was sooooo obvious.

Okay, I can duplicate on a powerpc64.

Fixed. The new hmac256 problem has been split out to T979.

Duplicate of T979

my$ printf "what do ya want for nothing?" | ./hmac256 Jefe
hmac256: fatal error: self-test failed
my$

The second implementaion hmac code is also used by the hmac256 utiliy we install
since some time. Can you please run this and compare the result? (best with the
hmac256 in libgcrypt/src/):

Sometimes weird things happen :_(.

Out of curiosity, I tried to rebuild the 1350 revision that you linked to below,
and it also worked. I'm not sure what happened, but at least I cannot reproduce
this any more.

I've re-run the 'basic' self test several time, and it works every time (except
for the hmac problem).

I'm relatively certain that it is correct. I created by running 'make dist' on
my machine and transferring the entire libgcrypt-*.tar.gz archive to the Solaris
system and building libgpg-error and the libgcrypt archive there. The system
doesn't have libgpg-error or libgcrypt installed before. The only way I see
them being wrong would be if there is a gdb/gcc problem, which isn't completely
unlikely, the tools on that platform are fairly old (gcc 3.4.4).

Are you sure that the backtrace is really from svn1350? The given line numbers
don't match.

Another fix was needed, please use revision 1365.

Fixed in svn revision 1364. Will go into 1.4.4. If you want to test it, grab
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/*checkout*/trunk/mpi/mpi-pow.c?rev=1364&root=Libgcrypt

As found out after having filed this bug, it's the libtool devs who have failed
it: http://osdir.com/ml/gnu.libtool.bugs/2005-05/msg00249.html .. so now I at
least know I don't have to bother the people behind the projects that use
libtool with it.

This looks pretty much like an autoconf bug. However, a broken instalaltion of
a compiler is a bad sign for a system, so one might even be thabnkful for such a
message ;-).

You are wrong. My system operates correctly. Think chroot() (so no /dev) +
ligcrypt then. But if it was discussed then EOT.

No they are not. Your system is not operating correctly and thus there is no
other way than to terminate the process immediately. Most applications do not
bother to check return codes and thus Libgcrypt even does not provide a return
code for important operations like getrandom. The application can't resolve
that problem anyway.

It doesn't seem to work:

is the latest snapshot. I'd appreciate if you can test it so that I can close
this bug.

Thanks. I fixed that and described what the handler is expected to do.

If you make a release candidate I can test it on a solaris machine.

Next time I do code staring I should put off my Joo Janta 200 Super-Chromatic
Bug Sensitive Sunglasses first.

I did some more code staring and comparing to 1.2.x without a result.
I have still no Solaris box available but the Debian build logs of 1.4.1 show
that the tests all run fine.

Fixed in 1.4.1.