Unfortunately, building without "--disable-asm" does not work if building a universal package under MacPorts (e.g. 32bit and 64bit x86 or 64bit x86 and arm64).

In T5268#142714, @gniibe wrote:

To do that, I'd like to know, when the symbol getentropy was added.

to explain a bit more: This report was opened after the reported defect was already fixed.
As we are getting many reports and technical suggestions, please keep the reports focused on one point only if possible
and open general discussion points about development improvements on gnupg-devel@.

Anyhow. Let us unrelate this from personal issues and just to be clean respect the content of the issue. Git links should not be promoted and cbiedl asked me today why we disagree because plain text protocols are really not state of the art. Cbiedl: You should be able to fix this it would be in the gnupg-doc branch afaik. If you have permission problems please let me know. I'll assign this to you.

Git repos are development only and developers need to find a way to establish some trust in the source before building it. All kind of mischief can happen with arbitrary sources. https does not help at all. You need to find a way to establish trust - how you do that is up to you. For example looking at signed commits and try to figure out whether you can trust this key.

For what it is worth we have also just tasked someone from our team to reinstate our buildbot / CI but this would likely not have helped in the current case of the libgcrypt buffer error as only ASAN with large hashtests would have found this. Still we have the general infrastructure for such tests we are just lacking resources. That is why we publish everything and encourage the community to at least help us with testing.

the issue regarding this self test was immediately found after release. Our development is completely open and everyone is free to run tests with our software on any platform at any time. We would respect and fix all those bug reports. None about this reached us during the development phase.
As this is not happening as it should during development we release and test on our platforms and build systems. When after the release others test, too we immediately fix the issues as happened with 1.9.1 in libgcrypt.

@werner, I cannot follow you. What exactly do you mean?

A public keyblock without a user id packet is non-compliant. I see no reason to provide a feature to created crippled data. We had all this discussions back in the early 90s regarding to self-signatures. OpenPGP spoke a final word on this in 1998 by making user ids and corresponding self-signatures mandatory.

Not exactly the answer I was hoping for..

Oops, that was an experimental feature never intended for a released version. Will be removed in a way that it does not leas to compile problems - just to be extra cautiousness.

I think that a backport to 1.8. also makes sense

I think this works now with error handling. At least it works for me, but needs some more testing of course.

I'm slightly against a backport as this is a behavior change for example KMail and GpgOL which use the --sender option might get different results after this change. I don't think it would be problematic but as said I have a slight preference against backporting because changing behavior of existing calls is better something for the new major release which is in its final steps for release anyway.

In T4735#135315, @werner wrote:

Shall we backport this to 2.2 which is our LTS release?

Thanks for the feedback. I sadly forgot to include the italian translations of GpgOL in the installer. So they will only be part of the next relase.

Here is a patch adding those checks:

diff --git a/cipher/ecc-ecdsa.c b/cipher/ecc-ecdsa.c
index d540578e..30103f14 100644
--- a/cipher/ecc-ecdsa.c
+++ b/cipher/ecc-ecdsa.c
@@ -172,6 +172,9 @@ _gcry_ecc_ecdsa_verify (gcry_mpi_t input, mpi_ec_t ec,
   mpi_point_struct Q, Q1, Q2;
   unsigned int nbits;

no, that doesn't change anything.

In T5268#142612, @ballapete wrote:

Wouldn't it be better to move these failures as a single one into the configure script that it definitely can tell "This Mac has getentropy()"?

Does it build if configure with parameter 'ac_cv_sys_symbol_underscore=yes'? <path-to-libgcrypt-source>/configure ac_cv_sys_symbol_underscore=yes --host=aarch64-apple-darwin ...

Compiling now works, but I get the following linker errors:

@jukivili Thanks for the reply! We've reverted that commit downstream in Gentoo as a temporary workaround, as due to some complications, our release systems needed to build without asm (for now) to ensure portability. Rest assured, this is not the default, and is discouraged for regular users.

Problem solved in Gpg4win 3.1.15 version! I think it can be closed!

Latext 1.9.1 builds without any unreported workarounds. Done. Close.

Building without "--disable-asm" works without any issues.

Thanks for your report.

FYI, this is not just an MacOS issue. We see that also on Gentoo Linux:

FYI: This commit broke building without ASM, see bug T5277.

Stick to your channels and get back after you have learned basic some basic developer workflows.

@hanno, this is a bug tracker and not yet another media for your rants.

Yeah looks like a duplicate. You may rename the bug to "Please implement some basic safety checks in a CI".

This should already be fixed in libgcrypt 1.9.1 by rCc6425a5537294dfe2beaafc9105f7af4ceac677f.

Same as https://dev.gnupg.org/T5277, thanks for the note.

This is likely the same as https://dev.gnupg.org/T5277. Do you configure with --disable-asm? If so: it should work without.

Wouldn't it be better to move these failures as a single one into the configure script that it definitely can tell "This Mac has getentropy()"?

Fix has been released. Keeping this in testing state for easier visibility of this task.

I applied the two patches on Mac OS X 10.5.8, Leopard, to random/rndlinux.c, resulting in this unified diff:

Release done.