I've attached the config.log file.

There's an issue somewhere: I built & installed libgpg-error 1.22 beta exactly
the same way as I did with 1.21. I'm not surprised by your answer: you guys have
already dismissed another perfectly valid issue report.

Something went wrong wile you installed libgpg-error. The linker picks up
another version of the library. If you need help, please ask on gnupg-devel.
Glad, that it now works for you.

pushed to the 1.7 branch.

Thanks for the info and the patch.
I have pushed commit 4545372 to master and it will eventually go into 1.7.1.

Hi Werner,

FreeBSD 9.x uses gcc version 4.2.1 20070831 patched [FreeBSD]

Thanks for the patch.
Which compiler version are you using?

Please provide more information. A kernel version is not sufficient. What
distro are you using, which compiler, etc. Sending the file config.log or a
transscript of the configure run would be helpful.

D365: 816_patch-cipher_crc-intel-pclmul.c

The following patch solves the problem.

System is Linux 3.2.0-23-generic.

If I understand correctly, we cannot compile latest libgcrypt because:

• the installed libgpg-error is a beta release
• it has been installed in /usr instead of /usr/local

That's unusual.
So I rebuilt libgcrypt with libgpg-error stable 1.21 installed in /usr, and it
passed.

It is true that I have built & installed libgpg-error from git master into
/usr:
./configure --enable-shared=yes \

			--enable-maintainer-mode \
			--prefix=/usr --sysconfdir=/etc --localstatedir=/var

But what do you mean by "properly install the library"?

Your system is misconfigured. You are using the gpg-error.h header
file from an unreleased version of libgpg-error but you are linking to
an older library.

  checking for gpg-error-config... /usr/bin/gpg-error-config
  checking for GPG Error - version >= 1.13... yes (1.22-beta14)

It seems you installed a libgpg-error version from git master
(.1.22-beta14) into the system directories instead of using
/usr/local. And you forgot to properly install the library.

Configured with:
./configure --enable-shared=yes \

			--enable-maintainer-mode \
			--prefix=/usr --sysconfdir=/etc --localstatedir=/var

In sexp.c we use suitable_encoding to decide on how to print the value: Either
as token, as an escaped string or as a hex-string. This is only done when using
FMT_ADVANCED. We could come up with some heuristics on how to print in base64
instead of hex (i.e. |YWJj| instead of #616263#) but that has the drawback that
the output would not be readable by older versions of libgcrypt.

Hwoever, what can be done is to make do_vsexp_sscan work with base64 encoding -
as of now such a value is simply ignored.

Can you please enter the command "where" in dbx after the fault?

No updates in 8 months, thus closing.

Thus clang is wrong here because it prints an "error" and not something like a
"performance hint". I close this bug.

Current code is perfectly fine as crc-intel-pclmul.c is i386/amd64-only source
file and that target architecture can handle unaligned loads.

The code in question is only for i386 and given that no SSE instructions are
used I wonder why you consider this a bug. The code might be faster if we would
access the short properly aligned but the question is whether this is worth an
extra copy operation.

jussi: What do you say?

Not easy yet, need more time to dig.

ping - will check tonight.

Meanwhile I also commited the Fedora patch.

aixtools: Had you a chance to test it?

Great! Thank you, Werner.

We now require a 64 bit integer type for >= 1.7 (commit 897ccd2)

There are still problems with libtool; see recent Debian problems on building
gnupg for Windows. Thus we won't chnage libtool for 1.7.0.

(The patch has been applied to 1.6 and master)

Well it took quite some time but I have now commited all 10 patches to master.
I have a fixed a few things (mostly style).

I have not yet added the Fedora patch. I'll ask Tomáš whether he can send me a
signed off patch.

Applied to master will go into 1.7.

I tried the patch and the problem hasn't shown up for me after an hour of
continuously running the test suite, so it looks fixed! Thanks for the fast
turnaround on this tricky problem.

By "all zero", I mean that a limb can be with bits of all zeros, so that e =
ep[i] can be zero.

D359: 783_mpi-pow-normalize-expo.diff

Thank you very much. It is reproducible for me, too. I located the issue.
I think that it is reproducible for any libgcrypt (even < 1.5.3).
With the patch attached, problem seems to be gone.
Problem is that the DH exchange introduced in the commit fc4a969a in libssh2,
the EXPO argument is coming without normalization, so, count_leading_zeros
results undefined value on IA-32.
In libssh2, it's random bytes, so, it can be all 0.

A couple more point: openssh must be installed on the system so the test suite
will work. Also, the problem seems to have started in commit fc4a969a in libssh2.

This recipe generally causes a hang within no more than 5 minutes of running
through the test suite on my system. libcrypt is assumed to be installed in the
normal location, or set PKG_CONFIG_PATH appropriately. Run "src/curl --version"
to make sure it says libssh2/1.7.0_DEV to prove it's picked up the right libssh2
and "ldd src/.libs/lt-curl" to make sure it's using gcrypt.

git clone https://github.com/libssh2/libssh2.git
cd libssh2
./buildconf
./configure --prefix=/tmp/install --with-libgcrypt
make -j6 && make install
cd ..
curl -O https://curl.haxx.se/download/curl-7.47.1.tar.lzma
tar xaf curl-7.47.1.tar.lzma
cd curl-7.47.1
PKG_CONFIG_PATH=/tmp/install/lib/pkgconfig ./configure --enable-debug
--without-ssl --with-libssh2
make -j6
while true; do make -j6 test TEST_Q='-a -p -n SFTP SCP'; done

If it is difficult for you to minimize your test case, as long as it is
reproducible, please let us have your test case. We'll try to figure out the bug.

Note that we need a 64 bit Libgcrypt for a 64 bit GpgOL. Thus checking that
rndw32.c works proberly on 64 bit Windows will soon be important.

I can't show you math proof at hand, but I'm confident enough J can't be negative.
This implementation of mpi_powm was introduced in October 2013.

libgcrypt 1.5.3 was the one with old implementation.

The code that's failing is single threaded and passes valgrind, address sanitizer
and undefined sanitizer tests. I can't think of how the stack could be corrupted
from outside the routine, except perhaps that a signal handler is involved. If
you're confident that j could never be negative in the normal case, then I'll try
tracking down how that could happen.

Thank you for your experiment.
I suspect other cause(s). In the code itself, there is no possibility J can be
negative. However, it could be possible, in practice, when the stack is
corrupted because of wrong allocation of memory or by other threads.

I tried doing exactly that, but it didn't reproduce the problem. I assumed that
either the internal representation of the input values set up in my test program
with gcry_mpi_scan() and gcry_mpi_set_ui() subtly differed from the ones
encountered in production, or there was some code path that uses an uninitialized
variable, but I don't know if either theory could be the case.

When you get negative value for J on entry of the for loop, you can examine four
arguments to _gcry_mpi_powm. And then, you can write standalone program to
emulate it. Debugger or printf.

In what condition can J can be initialized < 0?
Do you have some idea?

Thanks for writing the report - that is better than having your report ticked
only in my mail folder.