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.

I think the code is using https://en.wikipedia.org/wiki/Estrin%27s_scheme but I have no scholarship applying this to AES-GCM. I will have to look closer.

I think I am doing to try to do this on top of the work of Szabolcs Nagy[1] with the goal of making it portable, and also serving as a test cast to my carry-less multiplication intrinsic RFC[2]. Hopefully I can also remove the manual register allocation that makes it still a derivitive work of Andy, however this algorithm takes advantage of the communicative properties of carry-less multiplication, which is mult(H) on page 5 of the gcm spec[3], this communicative property works differently than with addition and multiplication in a way I do not entirely understand.

I believe the problem here is OS X 10.12's (and above) System Integrity Protection (SIP). SIP protects system integrity by doing things like sanitizing environmental variables for system programs. Sanitizing environmental variables on system programs avoids code injections.

Solved in master (1.9). We won't do it in 1.8.

I'm afraid that the dynamic linker doesn't allow hardcoding library path in an executable on macOS.
(It is only supported on some limited platforms.)

For the reference of full mod_sqrt, see https://eli.thegreenplace.net/2009/03/07/computing-modular-square-roots-in-python/

There are no log file but you can run the test by hand:

Patch backported to 2.2

• compressed representation of EC point can be used in:
  • public key
  • (exporting) private key
  • signature
  • ECDH ephemeral key
• Accepting compressed representation,for the initial implementation, I'd like to limit our effort for curves of NIST and Brainpool, except NIST P-224, which p = 3 mod 4.

Creating is not that useful - we prefer modern curves anyway.

I think that retrieving a parameter in compressed format is all what we need as per API.

(3) _gcry_ecc_os2ec in libgcrypt/cipher/ecc-misc.c should be modified to support parsing compressed representation.

What kind of API should we offer?
(1) offering something like q@comp name for gcry_mpi_ec_get_mpi
But...
If the intended use case will be in create_request function in gpg/sm/certreqgen.c, the 'q' is already generated in the form of SEXP.
It is up to an application (gpgsm), to convert non-compressed point representation to compressed point representation, here.

We will need this for 1.9

Yes please.

Ok. This was just something that I noticed while going through configure.ac. Should I make patch for this or do you want to?

Changes pushed to master.

Thanks for the info. So I guess me added that restrictions to be on the safe side regarding the VS-Nfd evaluation. For 1.9 we can and should lift that.

Please see [1] appendix F - I tested it more or less on all major CPUs, small
and large, old and new:

AFAIK, Stephan evaluated it only for x86, let me ask him ...

As of now we doubt that the proposed patch helps and we even fear that it could make things worst. Thus, as long as there is we have no description of an attack we won't do anything about it.

Change of gpg-agent for ECC-SOS

Taking a look at other GNU manuals, both GNU make and GNU Bison have a better phrasing,
so I suggest the Bison way (https://www.gnu.org/software/bison/manual/html_node/index.html):

This manual (7 December 2019) is for GNU Bison (version 3.5), the GNU parser generator.

Ah, okay, then the phrasing is missleading, the sentence looks like libgcrypt was released on this date and not the manual.

Nope, that is correct, the last update of the manual was

I tested with this patch (which changes use of constant-time routine when it's secure memory):

Fixed in rC0ff36e04f7cd: ecc: Remove hard-coded value for ECC_DIALECT_ED25519..

In the function nist_generate_key (cipher/ecc.c), ec->nbits is number of bits of P.
... while mpi/ec.c sets 256.

It's a kind of "bug compatibility" but it's a regression anyway.

Hi @slandden.
Do you have any updates?

In T4906#133954, @JW wrote:

@jukivili,

I'd be interested in seeing the results of testing the patch. Can you provide a link to the results?

I'd be interested in seeing the results of testing the patch. Can you provide a link to the results?

@jukivili : Thank you. Please apply & push it.

Attached patch should solve the issue for gcc 7.5 and clang 8.

You can test with newer compiler.

OK. I reopen this ticket to collect information.

It looks like the recipe to build the source file is missing the necessary arch options. I.e., -mcpu=power7 -mvsx ...

I can't reproduce the error (no problem for build). My (cross-)compiler is:

I think that it is compiler issue for AltiVec (now, VSX) support.
The usage is not ambiguous. It _is_ ambiguous in the header file.

Thansk for your report.

Please write proper bug reports and do not just post snippets from some arbitrary build process. In addition master is non-released software and thus it is in general better to ask at gcrypt-devel@gnupg.org for help.

I recall that I talked with Stephan about it but things got lost.