Kid.pm loads openssl in an unsafe way on macOS (crashes on Monterey)

[devernay]

This change: 8b924f6

which was made made to work a bit later with 21a441d

Seems to be considered as an unsafe way to load openssl on macOS monterey, and crashes perl.

Note that Monterey ships with version 7.34 of this module, so only homebrew and MacPorts users (who install 7.62) are affected:

• https://stackoverflow.com/questions/67003619/mac-m1-homebrew-perl-carton-netssleay-is-loading-libcrypto-in-an-unsafe-way
• https://trac.macports.org/ticket/63415#comment:21

[Leont]

Any suggestions for an alternative check would be most welcome, but deleting it isn't an option as that will break for other libraries.

[devernay]

The fix seems to be to simply use the versioned path: cl-plus-ssl/cl-plus-ssl#115
Required both for libcrypto and libssl, it seems

[devernay]

and the versioned path is only required for the system-provided openssl.
See this comment: setting the environment variable OPENSSL_PREFIX to a non-existing dir (or to a directory where there is a non-system SSL) fixes it.
It seems like Apple has its own patched openssl, which checks that it's loaded in a "safe" way

[Leont]

See this comment: setting the environment variable OPENSSL_PREFIX to a non-existing dir (or to a directory where there is a non-system SSL) fixes it.

That sounds like something that should be fixed in Net::SSLeay's Makefile.PL, instead of in MakeMaker itself.

It seems like Apple has its own patched openssl, which checks that it's loaded in a "safe" way

How on-brand, taking something that has worked everywhere for years and breaking it 😑

[dracos]

Not just Net::SSLeay, e.g. Crypt::OpenSSL::RSA appears to crash, caused by the same issue (reported)

--> Working on Crypt::OpenSSL::RSA
Fetching http://cpan.metacpan.org/authors/id/T/TO/TODDR/Crypt-OpenSSL-RSA-0.31.tar.gz
-> OK
Unpacking Crypt-OpenSSL-RSA-0.31.tar.gz
Copying Crypt-OpenSSL-RSA-0.31.tar.gz to [...]
Entering Crypt-OpenSSL-RSA-0.31
Checking configure dependencies from META.json
Checking if you have Crypt::OpenSSL::Guess 0.11 ... No
Checking if you have ExtUtils::MakeMaker 7.20 ... Yes (7.62)
==> Found dependencies: Crypt::OpenSSL::Guess
[...]
Configuring Crypt-OpenSSL-RSA-0.31
Running Makefile.PL
Warning: prerequisite Crypt::OpenSSL::Random 0 not found.
Checking if your kit is complete...
Looks good
WARNING: /opt/homebrew/Cellar/perl/5.34.0/bin/perl is loading libcrypto in an unsafe way
-> N/A
-> FAIL No MYMETA file is found after configure. Your toolchain is too old?
-> FAIL Configure failed for Crypt-OpenSSL-RSA-0.31. [...]

[jkahrman]

Any suggestions for an alternative check would be most welcome, but deleting it isn't an option as that will break for other libraries.

@Leont can you please elaborate? I'm having trouble connecting the original submissions back to the original problem.

Without this fix, it will erroneously believe that system provided libraries aren't available at all.

Sorry, I don't follow. Every other OS is handled in this function by searching the file system in various locations. What's changed with Mac that makes this approach difficult/untenable?

[Leont]

Every other OS is handled in this function by searching the file system in various locations. What's changed with Mac that makes this approach difficult/untenable?

On recent versions of Mac a lot of system libraries don't actually exist on the filesystem (or at least not in their usual place), but the linker (including dlopen) will pretend they do. The other half of this fix was !18407.

[jkahrman]

Any suggestions for an alternative check would be most welcome, but deleting it isn't an option as that will break for other libraries.

Did you consider _dyld_shared_cache_contains_path?

https://github.com/search?q=org%3Apython+_dyld_shared_cache_contains_path&type=code

[Leont]

Did you consider _dyld_shared_cache_contains_path?

I haven't, I don't think we can use it from MakeMaker anyway as it's a C function