I have now learnt how GCC uses 'undefined behavior' for aggressive optimization
and that this could break code doing unaligned accesses even on x86. So this
needs to be fixed after all.

There have been some problems backporting the batch to 1.7 thus it will not go
into 1.7.6.

The patch has been applied to master and the 1.7 branch. A 1.7.6 will be
released soon.

D402: 933_01-rijndael-ssse3-fix-compiling.patch

Attached patch should solve LTO problems with rinjdael-ssse-amd64.c.

'memcpy' problem seems to be because of bad interaction between -flto and
#pragma "no-sse". Strangely switching memcpy to buf_cpy solved problem, even
through buf_cpy itself just uses memcpy (on x86).

With this issue solved, I ran in to problem with rijndael-ssse3 assembly code
blocks going missing with -flto and link failing. So rest of the changes in
patch are for fixing lto visibility of assembly.

Yes, sure.

werner: Well... Doesn't it destroy libgcrypt's performance?

Jussi: would you be so kind and look at this problem?

The configure option --disable-asm might help.

Applied with commit 0a90f87799 to master. I will backport and release 1.7.5 today.

The Gentoo bug report for this has a
proposed fix, correcting a typo (EGAIN-

EAGAIN) in an autoconf script.

https://bugs.gentoo.org/show_bug.cgi?
id=602502#c5

I improved our test suite so that it detects this problem.

This is indeed a bug in libgcrypt. Thanks for the report.

No info recevied and thus closing. You should switch to 1.7 (and soon 1.8)
anyway. A lot of things have been fixed since 1.6.

FWIW, we do not see any problem with current Libgcrypt in our CUI system running
under Sierra.

Given that the patent expired I consider touching that comment not important.

Sorry for not providing further infos, I did not find the time before now.
I just tested with version 1.7.2; there the problem has disappeared.

I guess this change mentioned in the change log is the relevant one:
+2016-07-01 Jussi Kivilinna <jussi.kivilinna@iki.fi>
+
+ Fix static build.
+ * tests/pubkey.c (_gcry_pk_util_get_nbits): Make function 'static'.

Thank you very much, the case can be closed.

I confirmed on AIX 7.1 with GCC 4.8.1, libgcrypt 1.7.2 builds well. "make
check" goes success with no errors.
I'm closing this again, because the particular problem of typedef has been fixed.
If you have another issue, please open another report.

I see. We use system() in the random test to re-execute itself. This involves
the shell and thus the problem. Need to uses fork/exec or CreateProcess calls
for that test. I guess this needs to wait until we have moved that to code to
libgpg-error as our portability layer.

This is still a problem on OS X 10.11.5. OS X's System Integrity Protection
"feature" is causing that test failure. If S.I.P is disabled there's no problem.

A similar-looking test failure happens in perl
(https://rt.perl.org/Public/Bug/Display.html?id=126706). Perhaps the diagnosis is
the same here.

You may want to test 1.7.2 instead.

1.7.2 with the fix has been released

commit 3f98b1e adds a better fatal error message. Will be released with 1.7.2.

It has been fixed with commit 4a983e3.

Currently, there is no need for alignmask API. Implementations that we have at
the moment can handle unaligned data and some have fast paths for word-aligned
in/out buffers (which malloc can provide).

We could add section in documentation about appropiate memory alignment for best
performance, and tell to align buffers to cacheline size.

Hello,

I posted fix for this issue to mailing-list. See:
http://marc.info/?l=gcrypt-devel&m=146732375910584&w=2

Hi,

Can you please let me know if we could get hold of the older version than
1.7.1 of libgcrypt ?

Can you please let me know how we can fix this bug. We are using Redhat Linux 6
and the highest version it supports for gcc is 4.4.x . If we need to go for a
higher version we need to download source code and do the rpm( which may take
more time. )

It seems that it's the bug of libgcrypt.
https://lists.gnupg.org/pipermail/gcrypt-devel/2016-June/003901.html

Well it is a bug in your code and not in Libgcrypt. The md_read function is
guaranteed to always return a valid digest. However if you explicitly for SHA1
and SHA1 is not enabeld in the context we can't continue. Better use 0 as
second arg to md_read.

I will improve the error message for 1.7.2

I think that it requires GCC version 4.6 or later for AVX instruction.
4.9 or later is better.
Ideally, configure should check GCC version.

Awesome, that did the trick!
Many thanks.

Sorry, my near sight. I only fixed cofactor support, in a case where "h" is
provided.
I should have fixed other parts, too. Now, I fixed in master:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commitdiff;h=0f3a069211d8d24a61aa0dc2cc6c4ef04cc4fab7;hp=fa917d2e24b0c98143a079ab4889ad8f69bee446

It is backported to 1.7 branch too.

libaacs should work with this patch.

Well, I still get a "Missing object" error in libaacs, and I'm not sure how to
fix it. But the patch is in, so I think the bug can be closed.

It seems the problem is around the code here:
http://git.videolan.org/?p=libaacs.git;a=blob;f=src/libaacs/crypto.c;h=4db7641ec8e9af3cdf056562de39a39e3fa0c09b;hb=HEAD#l308

And the error I get when I try to scan a disc with aacs_info is as follows:
crypto.c:587: _aacs_verify: gcry_pk_verify failed. error was: Missing item in object
aacs.c:1502: invalid signature in cached hrl

If you have any hints, I'd be very grateful. Thanks!

Can we close this bug? (1.71 has been released)

libgcryp-1.7.0 t-lock and random test cases consistently crash on
SPARCv7 platform. On other platforms like x86/amd64/SPARCv9 the tests
succeed.

• 8< ---

PASS: t-mpi-point
PASS: curves
/bin/bash: line 5: 6557 Bus Error (core dumped)
GCRYPT_IN_REGRESSION_TEST=1 ${dir}$tst
FAIL: t-lock
PASS: prime

[...]

PASS: fips186-dsa
PASS: aeswrap
PASS: pkcs1v2
random: running './random --in-recursion --early-rng-check' failed
FAIL: random
PASS: dsa-rfc6979

256 of 1026 tests done
512 of 1026 tests done

• 8< ---

This will be useful for GnuPG itself. For example, currently in
gnupg/agent/command-ssh.c, we have a function ssh_receive_key which compose a
private key from 'ssh-add'. With this API, it will be cleaned up.

Shoul all be done for 1.7.0.

Given that a released version of libgpg-error does now exist, the problem should
be solved even for further versions taken from the repo.

Cofactor is defined by the curve. I guess that the cofactor of the curve in
libaacs is 1. Although my patch includes the code which gets cofactor from key
parameters, the ECDSA computation itself doesn't use cofactor actually.

Well, I haven't expected there is a user who uses (flags param), because it was
mostly for our development. There must be more bugs around that...

I encountered this bug when I tried to use libgcrypt-HEAD with libaacs.
libaacs uses ECDSA, and when it calls gcry_pk_verify(), I get GPG_ERR_NO_OBJ
because the sexp was constructed without the h parameter.

Good catch.
Fixed in c7430aa752232aa690c5d8f16575a345442ad8d7.

A beta version is not a released version. For example SO numbers may be
different. BTW 1.22 has been released.