Perl-Toolchain-Gang / ExtUtils-MakeMaker

Perl module to make Makefiles and build modules (what backs Makefile.PL)
https://metacpan.org/release/ExtUtils-MakeMaker
64 stars 76 forks source link

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

Open devernay opened 2 years ago

devernay commented 2 years ago

This change: https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/8b924f65a0485266822c904e11698f95019bc467

which was made made to work a bit later with https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/21a441da515d55654bca4971f21ad2550de069d2

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:

Leont commented 2 years ago

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 commented 2 years ago

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

devernay commented 2 years ago

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 commented 2 years ago

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 :expressionless:

dracos commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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