How does it come that you have a Linux kernel without threads? Or maybe the better question is why does libc not support threads?

Good morning.

The now used /var/run thingy solves all these problems nicely. In fact we may eventually remove the use fallback of using sockets in the GNUPGHOMEDIR.

Eventually we will move to keyboxd which is already an experimental option in 2.3. Thus we won't do anything here.

The other patches don't make sense because of future plans for dirmngr.

Critical attributes are well known from CMS and X.509 and some have a history which can only be described as cargo cult. We should not allow them in the OpenPGP ecosystem without giving them a specific semantic aside from "we do something with it".

Done. FWIW. in 2.3 symcryptrun will be removed entirely.

RFC 4880 says:

POSIX says so (use printf instead).
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html

Without any defined semantic it is not proper to ignore a critical bit. The software which created this keyblock seems to aim for incompatibility.

iirc the advise from the GNU coding standards is to use printf(1) instead of trying to figure out how echo(1) works.

Thank you. I'll fix. Perhaps, I'll ignore old UNIXen like AIX 6.1, which has no way to echo with no newlines.

The problem ist not an "ugly error message" but it does not recognize that the e-mail IS encyrpted by Symantec-PGP! But the plugin always says:

Actually I would be in favor of removing this portable thingy. It is and will always be the worst and most insecure way of using crypto.

Looks like this has been addressed in af23ab5c5482d625ff52e60606cf044e2b0106c8. A quick test building the current version in master with --disable-asm worked for me.

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

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.