Note: The commit in master (1.9) is rCe0898d0628789414
and in 1.8 it is rC03e6d6597198ee

The commit which fixes this is rC761a1a0d30

I agree to the sexp change - but it should not be backported to 1.8

For printing SEXP, it would be good to have this change:

rG47c1c329ed82: agent,ecc: Use of opaque MPI for ECC, fixup 'd'. does the fixup when reading keys.

I describe about rC6f8b1d4cb798: ecc: Consistently handle parameters as unsigned value..

Reading compressed point (in keys) is supported (except for NIST P-224). When curve point is represented in compressed format, it is correctly interpreted now. So, for example, I think that with 1.9.0, gpgsm can handle certificate which uses compressed format in its curve point representation.

Yes, bug is also in 1.8 branch.

Do we need to backport to 1.8?

Do we really need this for 1.9?

What is the state of this bug? Reading is implemented - do we really need writing (maybe to support certain smartcards)?

It is possible to disable the mlock thingy and if that is not wanted the application should be modified to be suid(root) during Libgcrypt initialization - this is actually how we handle this in GnuPG. Or maybe I don't understand the bug described here. It seems to be more of a support question.

For security and auditing reasons a Libgcrypt SO may not be "unloaded".

gcry_ecc_get_algo_keylen has been added with commit a658c9ccc2c741f40b0b5cdbcd184cfb9a841d17 but documentation is missing.

Thanks. I added the OIDs and the missing curves. To go into 1.9

Flagged as high becuase this is RC for Libgcrypt 1.9

Reimplemented 8 block parallel in "vertical" orientation.

With little extra effort, stitched implementation turned out ok after all.

Applied to s390x optimizations feature branch:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=7532e27cacb74c92fd561524a0897163b0fcd7f4

Applied to s390x optimizations feature branch:
SHA256: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=0b555c3cc7c2b80ec2628685946a6139a1996911
SHA512: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=45f0ec0c4e3b08627cbf7e65f5f110c321710d01

Applied to s390x optimizations feature branch:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=88570515b4ca92a44c4e40c31f877c11cc00ab68

Applied to s390x optimizations feature branch:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=5aeb091f911398217b2e9facb9bdeb05c63d7844

Applied to s390x optimizations feature branch:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=9219d9d1b60c01a4c7dbde05ee6b5b52e0d7d072

Implemented stitched ChaCha20-Poly1305 (vector ChaCha20 & ALU Poly1305). Unfortunately performance is less than OpenSSL (vector ChaCha20 & vector Poly1305). Instruction latencies make Poly1305 slower than combined OpenSSL ChaCha20+Poly1305, thus it is not possible to reach same performance with stitching. Vector Poly1305 implementation is therefore needed.

Currently have 8 block parallel implementation done. Need to check if 6 block parallel approach is better (as used in OpenSSL - benefit being less register pressure and less moving of data between registers and stack).

I cannot find good test vectors for PBKDF2 with HMAC-SHA-2.

Our tests are now in tests/basic.c.

For CMAC tests, we would need to use newer test vectors.

I would add "Provide a verbose message of why the key cannot be imported".

OK, then we'll have to live with --disable-asm until the next major version is released, or switch to gcc.

We should not do this.

AArch64 clang support was added to 'master' on 2018-03-28. One would need to backport commits 8ee38806245ca8452051b1a245f44082323f37f6...9b58e4a03ba3aeff7bae3f40da706977870c9649 to 1.8 branch.

In T5157#139622, @gniibe wrote:

ARM64 has been only tested on platforms which support ELF.

While it doesn't looks good (using AMD64 even if it's ARM64), I think this patch should be applied:

diff --git a/cipher/asm-common-aarch64.h b/cipher/asm-common-aarch64.h
...

So, I'm going to push D513 to both of 1.8 and master (to be 1.9).

I created D513: Support macOS build with SIP by using posix_spawn in tests/random, which is more conservative; It only affects build under macOS.

In T5159#139739, @werner wrote:

Put

extern char **environ;

after the the include directives.

Put

extern char **environ;

after the the include directives.

After applying @gniibe 's patch:

The problem is that posix_spawn is not portable enough for libgcrypt. It is really time that we move the spawn functions from gnupg to gpgrt so that we can use them also in Libgcrypt.

BTW, I'm not sure if the claim in T5009#136688 is correct.

See also: https://dev.gnupg.org/T5009#136688

See my comment in: https://dev.gnupg.org/T5024#139701

After disabling SIP, now all checks pass without having the library symlinked to /usr/local/lib. So it might be T2056: libgcrypt: make check fails "random" test on OS X 10.11 with link error after all.

After doing:

Another issue that comes in to mind is that current ARM/ARM64 HW feature detection most likely wont work on MacOS. Thus HW accelerated AES&SHA&GHASH implementation wont be used.