-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RC1 Sodium] salt fails on macOS Catalina, due to loading unversioned /usr/lib/libcrypto.dylib #55084
Comments
Thanks for submitting! This may be an issue with Can you also provide the stack trace as well? |
The only way to get a stack trace is via setting
And the crash log from macOS:
I also have checked versions |
Is the same issue as with Homebrew/homebrew-core#44996 Apparently, some homebrew formulas are outdated and they must be updated in order to fix this issue. As @fxcoudert pointed out in wbond/asn1crypto#158 |
@cdalvaro I think it's vice versa. For example here it finds And exactly the same problem is reproducible on Please correct me if I'm wrong. |
Yes, you are totally right, @bayandin Another thing I noticed is that after upgrading macOS from Mojave to Catalina in my MacBook More even, I was able to copy that installation of |
I have the same issue, discussed in the thread at Homebrew/homebrew-core#44996 The problem can’t be solved at Homebrew’s end. |
After doing |
@jpmckinney we welcome a Homebrew pull request to update to the latest version! |
I can confirm that Homebrew/homebrew-core#45895 works on Catalina! |
Unfortunately, it doesn't work neither for me nor for homebrews CI: $ brew install https://raw.githubusercontent.com/Homebrew/homebrew-core/1fa258efcd1ae72e6ecb48d0d81bb338adb12ec3/Formula/salt.rb # Install salt 2019.2.2
$ salt --version
Abort trap: 6 I use Python 3.7.4 The same result for me if I installed this version from pypi. |
So this is my research... I have installed On the other hand, on my Mac Pro where Catalina was installed as a fresh installation, And last test, I have copied my rsync -aP --delete 2019.2.2_macOS_upgrade_installation/ /usr/local/Cellar/salt/2019.2.2/ You can find attached to this comment both salt installations in order to improve this research. ✅ 2019.2.2_macOS_upgrade_installation.tar.gz - macOS Catalina upgraded from Mojave ❌ 2019.2.2_macOS_new_installation.tar.gz - macOS Catalina fresh installation |
Workaround that actually worked so far:
You might need to use sudo for the link commands, wasn't needed in my case. More info |
Hey @xeacott, is there more information required for the issue? I'll be happy to provide it. Thanks! |
The problem is here: https://github.com/saltstack/salt/blob/master/salt/utils/rsax931.py#L38 A short reproducer on macOS Catalina:
Because unversioned |
The problem is still here. When I run command salt-ssh -i remotehost test.ping
|
It looks like it requires Have you installed |
@bayandin I've installed saltstack and openssl using
I've tryed to create symlinks #55084 (comment) but it hasn't worked. |
@sromanenko ah, probably I've misunderstood the original error message. Does this stacktrace come from the remote machine? |
@bayandin no, I suppose it comes from my macbook, because remote machine is linux host and I use
|
|
@rbobrovnikov trying to run pip also crashes with the same error, what does installing those packages actually do? Can they be installed the same way python was installed (brew for example)? Thanks! |
All: Probably look at this issue: wbond/asn1crypto#158 and comment: Homebrew/homebrew-core#44996 (comment) |
Thank you for updating this issue. It is no longer marked as stale. |
Still doesn't work for me neither versions 2019.2.3 or 3000.
I did everything what was suggested by community in this thread and nothing..... |
@arren-ru it happens when you use salt from homebrew on mac to connect to Linux remote machine (which doesn't have I'm removing the patch from homebrew (Homebrew/homebrew-core#51843) and letting salt folks to fix the problem if it still happens. |
I locally modified the patch to result into elif sys.platform == 'darwin':
return cdll.LoadLibrary('/usr/local/opt/openssl@1.1/lib/libcrypto.dylib')
else:
lib = find_library('crypto') Which still isn't ideal, but works for now. |
Same issue here and I'm not on Catalina. (Mojave instead) So this seems to have to do with some directory switching; If I run this on the python3 repl I can load it just fine:
|
I've encountered this issue as well, and based on Apple's Taking the SunOS/AIX exceptions (also in elif salt.utils.platform.is_darwin():
# Find versioned libraries in system locations, being careful to
# avoid the unversioned stub which is no longer permitted.
lib = glob.glob('/usr/lib/libcrypto.*.dylib')
if lib:
# Sort so as to prefer the newest version.
lib = list(reversed(sorted(lib)))
else:
# Find library symlinks in Homebrew locations.
lib = glob.glob('/usr/local/opt/openssl/lib/libcrypto.dylib')
lib = lib or glob.glob('/usr/local/opt/openssl@*/lib/libcrypto.dylib')
lib = lib[0] if lib else None This will attempt to use the system libcrypto libraries before falling back to Homebrew. If you haven't installed Anyway, I've not run it through any testing beyond confirming that the I can submit a Pull request if desired, but I'll need to find the contributor/developer docs. Edit: Also, I feel like I should probably note that I believe this is working as intended (on Apple's part.) They don't want people using unversioned libraries. |
I am having this issue with elif salt.utils.platform.is_darwin():
... I also added a check to the end for if the path exists. if not os.path.exists(lib):
lib = find_library('crypto')
if lib:
return cdll.LoadLibrary(lib)
raise OSError('Cannot locate OpenSSL libcrypto') |
else:
lib = find_library('crypto')
if not lib and salt.utils.platform.is_sunos(): Additionally, it would be pretty hard for the path in (Edit: I also corrected my above post to correct the name to |
@kaorihinata 38c38
< lib = find_library('crypto')
---
> lib = '/usr/local/opt/openssl@1.1/lib/libcrypto.dylib'
47a48,60
> elif salt.utils.platform.is_darwin():
> # Find versioned libraries in system locations, being careful to
> # avoid the unversioned stub which is no longer permitted.
> import glob
> lib = glob.glob('/usr/lib/libcrypto.*.dylib')
> if lib:
> # Sort so as to prefer the newest version.
> lib = list(reversed(sorted(lib)))
> else:
> # Find library symlinks in Homebrew locations.
> lib = glob.glob('/usr/local/opt/openssl/lib/libcrypto.dylib')
> lib = lib or glob.glob('/usr/local/opt/openssl@*/lib/libcrypto.dylib')
> lib = lib[0] if lib else None
55a69,70
> if not os.path.exists(lib):
> lib = find_library('crypto') |
@almoore I see. I suppose that's about what we can expect from them. I'll create a Pull Request right now so that we can be done with this. (Edit: I forgot to mention that the reason my solution is more complex is because I install salt from pip to avoid Homebrew's "fixes". My snippet will use Apple's installed OpenSSL libraries without complaint, and as can be seen in the function below |
macOS has been steadily moving towards requiring programmers to directly link against the library version they prefer and forbidding linking against unversioned libraries. With Catalina this has moved from simply logging a warning when a programmer links against an unversioned library (typically a stub) to outright crashing with a pretty clear error. In an effort to honor Apple's intentions but not completely reimplement their dlopen methods, this change takes advantage of Apple's library naming scheme to load the most recent versioned dylib while ignoring the unversioned stub. Fixes: #55084 Signed-off-by: Thomas J. Gallen <kaori.hinata@gmail.com>
Description of Issue
salt crashes on macOS Catalina (10.15).
I find out that the problem happens on loading
/usr/lib/libcrypto.dylib
library (https://github.com/saltstack/salt/blob/v2019.2.1/salt/utils/rsax931.py#L57).There is a similar issue with another python library: wbond/asn1crypto#158
Setup
Steps to Reproduce Issue
salt --version
, it will crash withAbort trap: 6
Versions Report
(Provided by running
salt --versions-report
. Please also mention any differences in master/minion versions.)The text was updated successfully, but these errors were encountered: