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.

IIUC, for the build of Homebrew, it is the issue of in: https://github.com/Homebrew/homebrew-core/commit/e7da1e2157b2e8373c3b39ea6398f51588ea537c

Please have a look at T5024: libtool problem for some platforms for 'make check' (program built with -no-install won't work without installation), if make check works after the installation of libgcrypt.

See T2056: libgcrypt: make check fails "random" test on OS X 10.11 with link error, if test with 'random' fails.

HAVE_COMPATIBLE_GCC_AMD64_PLATFORM_AS is never defined on ARM64 as it depends on "$mpi_cpu_arch" == "x86". Instead I think new check for GCC assembly ELF directives would be needed in configure.ac, similar to HAVE_GCC_ASM_CFI_DIRECTIVES check. Following check should work, but I have not yet tested it:

ARM64 has been only tested on platforms which support ELF.

Yes, I did. Identical result.

Why the hell do they that? The standard compiler on a system is called cc which may translated to whatever the system installs for it. gcc is a specific implementation with certain properties. Di you try CC=clang to override this?

And the arm64 cross-compiler:

Sorry, I forgot to mention that Apple ships a gcc-wrapper for clang. It just accepts gcc command lines parameters and translates them to clang parameters.
Here is the output of gcc --version:

You say that you build using clang but the log shows that you invoke gcc.

In T3189#117959, @gniibe wrote:

Do we need to expose the secmem routines, as a public interface of gpgrt?

I would find it useful. For example I'm making a utility that gets a passphrase with GPGME and gpg-agent, and would like to copy it into a buffer that lives on after closing the context.

OK, I upgraded the patch, including style adjustments to GNU style despite feeling that not having clang-format support for GNU style leads to it driving away contributors. It also credits Andy, and I have personally e-mailed Andy before.