I have confirmed that rA69069bc63e6b fixes the build on macOS.

Yes, the fix is included in the Gpg4win 4.3.1.

Was the fix part of a stable release? The beta was 4.2.1b55. Stable download on https://gpg4win.de/ is 4.3.1. Am I correctly assuming, that 4.3.1 includes the fix and this issue here can be closed?

Use of execve is better (avoiding use of environ).

Fixed in: rA69069bc63e6b: Remove an declaration for an unused function

Actually we should get rid of stdio functions and use the es_foo replacements from libgpg-error.

Thank you for your report.

The use of putc_unlocked has long been removed. So we should also remove the declaration. Normally this does not harm but in your case you may want to pass CFLAGS="-DHAVE_PUTC_UNLOCKED" to make or remove the above declaration.

Verified the fix.

Pushed the change to master. Please test.
rCbb0895bbb7c6: m4: Fix acinclude.m4 for underscore detection in the symbol.

Thank you for the report.

Thanks for the detailed analysis; we will check to tomorrow why this was changed.

Here is a fix for the issue which preserves the removal of cut:

See: MacPorts Ticket 70267 and MacPorts PR #24601

While the above patch worked for MacOS 10.8 and above, MacPorts CI shows a second error for older MacOS versions:

It looks like various flavors of BSD (including macOS just declare environ when needed): environ -- user environment Note: this is a very old MacOS X man page, however the current version is from 2003, and has the same Synopsis.

This diff for 1.11.0 fixes the problem for me:

The following logic from 1.11.0 acinclude.m4 cannot possibly work to detect _ at the beginning of symbol names:

The toolchain is clang / llvm and the apple ld, native build, not cross compiling.

Meanwhile version 1.32.2 builds. Greatest change is Python 3.12 instead of 3.11…

Sorry, I meant they do *not* arrive at the web interface, they are not visible to me.

It seems my eMails to gnupg-devel@gnupg.org do reach the list …

On Mac OS X 10.5.8, PPC Leopard, it built with the patch, gpg-agent works.

Trying to reach Ralph Seichter via the eMail address he is using failed – Osterferien?

Thank you for your quick testing.

I've reported the success to MacPorts. My test was performed on only one platform, Mac OS X 10.4.11 or "Tiger". Since there exists a problem with building recent version of GPGME testing on Mac OS X 10.5.8 or "Leopard" will have to wait a few days…

With the unified patch all works fine (again), even the test target succeeds!

Performing the patch manually the "port" (package) built and installed. Starting then gpg-agent worked too, killing it (with gpgconf) worked as well.

The patches looks too large to merge (than actually needed), and not enough/clean like not having detection of the system.

strcasecmp is pretty standard on Unix. However, in GnuPG we test for it and mostly use our own ascii_strcasecmp to avoid fun with locales. Ralph Seichter is providing macOS builds for GnuPG (https://sourceforge.net/p/gpgosx/docu/Download/) . Maybe it is worth to contact him via the gnugp-devel mailing list and ask him whether he has experience with your toochain.

By adding "-Wl,-t" to the arguments g++ reported:

Libtool invocation has "--tag=CXX --mode=link /opt/local/bin/g++-mp-7 -std=c++11 -pipe -Os -std=c++17 -D_GLIBCXX_USE_CXX11_ABI=0", but g++ then has no -lstdc++ – in C -lc is automatically used because there all C library functions can be taken from… (same for mathematical functions and -lm)

It seems libtool fails to add the standard C and C++ libraries to the link command line. On Linux I have "[...] -lstdc++ -lm -lc [...]" in the libtool link command line. Looks like a bug in the tooling (macports or libtool).

The solution seems to be a newer libccid version. If that is the case we may want to include the fix also in our own ccid driver.

Got this from my card vendor. Sonoma had a buggy CCID driver; compile one yourself and the bug's gone: https://forums.developer.apple.com/forums/thread/732091?answerId=768462022#768462022

For reference, here is a link to the gpgme homebrew formula:
https://github.com/Homebrew/homebrew-core/blob/master/Formula/g/gpgme.rb

Just to clarify, PIP wasn't used to install the .egg package. The package was built and installed via Homebrew. The error message occurs when using basic PIP commands such as pip list or pip freeze. PIP is picking up the gpgme egg from the shortcut included in the site-packages directory.

We don't use or suggest the use of PIP or other insecure software distribution systems.

Well, this bug is fixed by using a decent libgpg-error or configure it correctly.

Funny error description from macOS. Looks that there is no device - your PC/SC test programs confirms this. Thus I don't think this is a bug in scdaemon.

I am wondering a bit about the gpg: DBG: chan_3 <- ERR 100696144 Operation not supported by device <SCD> which is not the string I expected for this error:

Hi, thank you so much and sorry for delay.
This beta is working for us perfectly.

Changing debug options unfortunately didn't change much.

Thank you very much, we will try it and let you know
Regards
Lukas

Please try the following beta: https://files.gpg4win.org/Beta/gpg4win-4.2.1-beta55/gpg4win-4.2.1-beta55.exe This should solve your problem. And if not you can now open the encrypted attachments with Kleopatra and it will show your mail.

Ok and its possible to know, how long its should usually take to make new release ?
Can you tell me more about support contract or when i can find more information about it ?
Regards
Lukas

I guess you need to wait until we do a new release. If your company relies on this software it might be a good idea to enter into a support contract as other do.

i dont get any responce, what is next step in this case.
Regards
Lukas

So by we already have code to handle this problem, we had code for "No body but multipart/mixed" and your message was "empty body but multipart mixed" so I just needed to also check for an empty body and the code worked.

Ah damn, now that I closed this as a duplicate I found that we already have code to handle this problem.

Well the message is content-type multipart/mixed. For GpgOL to investigate the mail it needs to be multipart/signed oder application/encrypted or application/pgp-encrypted. (and some other things) But multipart/mixed is something that we don't take a second look at because this means "unencrypted mail with attachments."

thank you, i send you test mail
Regards

Hi, my suspicion with the different tenant is that some middleware of yours is inserting something like "DANGER this could not be Virus Scanned by your super secure and expensive middleware" which then results in the mail beeing multipart/mixed instead of pgp/encrypted in the MIME type. Could you ask your communication partner with the problem to send such a mail to you and with CC to "andre.heinecke@demo.gnupg.com

I was trying to solve it with support, but it was not solved until today, this issue we are facing more thank like 2years.
I guess its need to be solved with more advanced support than classic one.
Regards

Looks more like a support question but feel free to create a sample message, encrypt it to info at gnupg.com (WKD) and attach that message to this report.

Anyway, thanks for fixing this.

It does work indeed!

Guessing that it works now.

I don't see a reason backing off the original commit. A fix for macOS is now available (rCfa21ddc158b5) and will be in the next release. No reason for other changes.

This problem was introduced by commit cf10c74bd9d5aa80798f1c0e23a9126f381b26b3. Perhaps that change should be backed out in the interim so that a portable fix can be considered for the original issue?

It is a bit complicated. Let me describe the situation.

Actually Linux already returns ENOSYS on older kernels where there is no getrandom libc call. Thus returning ENOSYS if we don't have the libc version of that syscall (i.e. getrandom) in FIPS mode seems to be the Right Thing to do. My whole comment was about fips mode - it does not make much sense to enable FIPS mode if the system is not appropriate for it.

I see, your issue is with the use of getrandom for FIPS. I understand now.

ENOSYS is POSIX. My point is that: getrandom was introduced in Linux kernel with flags for particular purpose (differentiate use of /dev/random and /dev/urandom), but that feature has gone.
But, for FIPS behavior, RHEL and related OS use (possibly, some would say misuse) getrandom with GRND_RANDOM. This use is RHEL specific (not for other GNU/Linux). Use of getrandom is non-POSIX.

In T6442#169419, @gniibe wrote:

Returning ENOSYS is too strict, in my opinion; It doesn't work for machines other than CentOS/Fedora/RHEL.

Returning ENOSYS is too strict, in my opinion; Because the code in question doesn't work for machines other than CentOS/Fedora/RHEL. For other machines, it would be natural to just rely on getentropy (rather standard call).

What Werner wrote was also my thought. If getrandom is mandatory for FIPS, then it must not be possible to disable it silently.

What about