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@.

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.

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.

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.

no, that doesn't change anything.

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:

@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.

Patch lets it build on xenial for me, thank you.

Patch for this bug is available here, "attachment-0001.bin": https://lists.gnupg.org/pipermail/gcrypt-devel/2021-January/005079.html

I committed the partial result docker container, so I can restart it for investigation. So:

I tested xenial with gcc-5.3 (xenial distro repo) and gcc-5.4 (xenial-updates distro repo) and libgcrypt 1.9.0 from git repo and from tarball. I did not get any errors.

See T5267: Ed25519 backward compatible private key support for preceding ZERO(s) for the fix.

https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/posix_spawn.2.html dated August 9, 2007.
So, I guess that posix_spawn became available in MacOS X Leopard (10.5).

Also support older MacOS X, which has no posix_spawn.

Thanks @aheinecke for fixing my fix with 2859edd! Closing here.

In T5264#142204, @jukivili wrote:

I also needed this patch:

0001-global-fix-compile-error-at-pragma-GCC-diagnostic.patch2 KBDownload

I am going to check whether I need it on Tiger!

In T5264#142204, @jukivili wrote:

I tested building on Ubuntu 8.04 (gcc-4.2) and got same error about cipher_bulk_ops_t. Applying patch fixed that problem.

I see now my mistake: I also have to re-write line #132 which I did not see yet!

With your other patch I still get:

libtool: compile:  /opt/local/bin/gcc-apple-4.2 -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I../mpi -I../mpi -I/opt/local/include -I/opt/local/include -pipe -Os -std=gnu89 -arch ppc -fno-delete-null-pointer-checks -Wall -MT cipher.lo -MD -MP -MF .deps/cipher.Tpo -c cipher.c  -fno-common -DPIC -o .libs/cipher.o
In file included from cipher.c:31:
./cipher-internal.h:145: error: redefinition of typedef 'cipher_bulk_ops_t'
../src/cipher-proto.h:132: error: previous declaration of 'cipher_bulk_ops_t' was here

In T5264#142203, @jukivili wrote:

Thanks for testing. However, I do not believe patch has been correctly applied.

The "Portfile" that conducts the build process has the patch contained, I sent you the list of files being patched, and here is the end of my translated patch set:

I tested building on Ubuntu 8.04 (gcc-4.2) and got same error about cipher_bulk_ops_t. Applying patch fixed that problem.

Thanks for testing. However, I do not believe patch has been correctly applied.

In T5264#142094, @jukivili wrote:

Here's patch to try out:

0001-cipher-proto-remove-forward-typedef-of-cipher_bulk_o.patch6 KBDownload

T4702 is our release info task for 2.3.0

You should have received mail with additional log levels now

In T5264#142064, @jukivili wrote:

In "src/cipher-proto.h", try removing typedef and leaving just forward declaration of structure.

Performing only this change leads consistently to the well-known error of:

In T5264#142059, @werner wrote:

Do not use -fno-common

The translated bulk patch fails. Compilation still runs into this error:

In T5264#142094, @jukivili wrote:

Here's patch to try out:

0001-cipher-proto-remove-forward-typedef-of-cipher_bulk_o.patch6 KBDownload

@gniibe Hi! Can you estimate, when this feature will be released?
I have not found this patch in the latest GnuPG release tags (in the Git repository) either by the name or the commit hash.

Thanks for the report. Some time ago I wrote the code in a way that when setting the HTML body failed it would fallback to the plain body, regardless of the preferences:
So even though there is an error that error is handled. https://dev.gnupg.org/source/gpgol/browse/master/src/mail.cpp;4d57033a095aecf8529606428efef6af466f1196$1488

Alright!

@ballapete when you have time, could you also test https://dev.gnupg.org/T5268#142155 on Tiger?

Right now I am compiling with my old PowerBook in Tiger. In case a compilation fails I'll try this patch – on Tiger (Mac OS X 10.4.11)! It's a bit more primitive than Leopard.

Here's patch to try out:

BTW, we should better get back to the classic/GNU-coding-style pattern:

In "src/cipher-proto.h", try removing typedef and leaving just forward declaration of structure.