OSX Catalina: 'cfn init' terminated by signal SIGABRT (Abort)

[benbridts]

I'm not sure if this belongs here, as it's an OSX Catalina / homebrew python issue. I assume people will look here when they run into this error, so maybe it's something to document.

If you run cfn init outside of a virtualernv on OSX Catalina with python3.7 (installed via homebrew), you get this behaviour and error:

~$: cfn init --verbose
Initializing new project
What's the name of your resource type?
(Organization::Service::Resource)
>> MyOrg::Foo::Bar
Select a language for code generation:
[1] python36
[2] python37
(enter an integer):
>> 2
fish: 'cfn init --verbose' terminated by signal SIGABRT (Abort)

Looking at the error report that is generated, this seems to be an issue related to pyhton3 and libcrypto:

Application Specific Information:
/usr/lib/libcrypto.dylib
abort() called
Invalid dylib load. Clients should not load the unversioned libcrypto dylib as it does not have a stable ABI.

I googled for a solution and I there is a clean workaround (besides running cfn in a virtualenv:

# Install openssl, if it's not installed already
brew install openssl
# Use the openssl libraries
DYLD_LIBRARY_PATH=/usr/local/opt/openssl/lib:$DYLD_LIBRARY_PATH cfn init

[tobywf]

ouch, good trouble-shooting! doesn't seem like anything we can work around in the code, but definitely worth adding to the README

[benkehoe]

Could this situation at least be detected and reported, so that the user knows what action to take?

[tobywf]

none of us are running Catalina, so it's hard to reproduce and test. loads of people are hitting this though in all kinds of situations:

• https://stackoverflow.com/questions/58272830/python-crashing-on-macos-10-15-beta-19a582a-with-usr-lib-libcrypto-dylib
• https://forums.developer.apple.com/thread/119429
• pip3 aborts immediately on Catalina Release version Homebrew/homebrew-core#44996
• [RC1 Sodium] salt fails on macOS Catalina, due to loading unversioned /usr/lib/libcrypto.dylib saltstack/salt#55084

particularly, the first and last issue seem to indicate upgrading the asn1crypto package helped. problem is, we don't pull that in directly or indirectly. i assume this is why you don't hit this in a virtual environment. and hacking around broken system dependencies is a bit out of scope. it's unlikely we'll address this any further than pinning and keeping the issue open (for now).