Code signature breaks micromamba in macOS application

Description

What steps will reproduce the problem?

Code signing has broken the micromamba executable in the macOS application. This means that the IPython Console will not work with external conda environments.

dyld: Library not loaded: @rpath/libc++.1.dylib
Referenced from: /Users/rclary/Applications/Spyder.app/Contents/Resources/lib/python3.9/spyder/bin/micromamba
Reason: image not found

Versions

• Spyder version: 5.3.2 1172bb467 (standalone)
• Python version: 3.9.5 64-bit
• Qt version: 5.15.2
• PyQt5 version: 5.15.7
• Operating System: Darwin 20.6.0

Dependencies

# Mandatory:
atomicwrites >=1.2.0                 :  1.4.1 (OK)
chardet >=2.0.0                      :  5.0.0 (OK)
cloudpickle >=0.5.0                  :  2.1.0 (OK)
cookiecutter >=1.6.0                 :  2.1.1 (OK)
diff_match_patch >=20181111          :  20200713 (OK)
intervaltree >=3.0.2                 :  3.1.0 (OK)
IPython >=7.31.1;<8.0.0              :  7.34.0 (OK)
jedi >=0.17.2;<0.19.0                :  0.18.1 (OK)
jellyfish >=0.7                      :  0.9.0 (OK)
jsonschema >=3.2.0                   :  4.7.2 (OK)
keyring >=17.0.0                     :  23.6.0 (OK)
nbconvert >=4.0                      :  6.5.0 (OK)
numpydoc >=0.6.0                     :  1.4.0 (OK)
parso >=0.7.0;<0.9.0                 :  0.8.3 (OK)
pexpect >=4.4.0                      :  4.8.0 (OK)
pickleshare >=0.4                    :  0.7.5 (OK)
psutil >=5.3                         :  5.9.1 (OK)
pygments >=2.0                       :  2.12.0 (OK)
pylint >=2.5.0;<3.0                  :  2.14.4 (OK)
pyls_spyder >=0.4.0                  :  0.4.0 (OK)
pylsp >=1.5.0;<1.6.0                 :  1.5.0 (OK)
pylsp_black >=1.2.0                  :  1.2.1 (OK)
qdarkstyle >=3.0.2;<3.1.0            :  3.0.3 (OK)
qstylizer >=0.1.10                   :  0.2.1 (OK)
qtawesome >=1.0.2                    :  1.1.1 (OK)
qtconsole >=5.3.0;<5.4.0             :  5.3.1 (OK)
qtpy >=2.1.0                         :  2.1.0 (OK)
rtree >=0.9.7                        :  1.0.0 (OK)
setuptools >=49.6.0                  :  63.1.0 (OK)
sphinx >=0.6.6                       :  5.0.2 (OK)
spyder_kernels >=2.3.2;<2.4.0        :  2.3.2 (OK)
textdistance >=4.2.0                 :  4.3.0 (OK)
three_merge >=0.1.1                  :  0.1.1 (OK)
watchdog >=0.10.3                    :  2.1.9 (OK)
zmq >=22.1.0                         :  23.2.0 (OK)

# Optional:
cython >=0.21                        :  0.29.30 (OK)
matplotlib >=3.0.0                   :  3.5.2 (OK)
numpy >=1.7                          :  1.22.4 (OK)
pandas >=1.1.1                       :  1.4.3 (OK)
scipy >=0.17.0                       :  1.8.1 (OK)
sympy >=0.7.3                        :  1.10.1 (OK)

# Spyder plugins:
spyder_terminal.terminalplugin 1.2.2 :  1.2.2 (OK)

[mrclary]

So, just for further explanation, I was able to build micromamba locally, using fully static linking. This did, indeed, change the libraries from

/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
/System/Library/Frameworks/Security.framework/Versions/A/Security
/usr/lib/libresolv.9.dylib
@rpath/libc++.1.dylib
/usr/lib/libSystem.B.dylib

to

/usr/lib/libresolv.9.dylib
@rpath/libc++.1.dylib
/usr/lib/libSystem.B.dylib

So it appears that the downloaded micromamba is a STATIC build rather than a FULL_STATIC build. Note that the first two libraries of the static case are core operating system libraries and therefore should not cause any problems as they should be available on every macOS system.

The real issue is the reference to @rpath in @rpath/libc++.1.dylib. Gatekeeper requires micromamba to be code signed with the hardened runtime option (-o runtime), which severely restricts the use of @rpath (https://developer.apple.com/forums/thread/118067). This is what is causing the problem.

However, I believe that libc++.1.dylib is actually included in the micromamba executable and the reference to @rpath is erroneous. I arrive at this conclusion because I am able to change the path to /usr/lib/libc++.1.dylib

>> install_name_tool -change @rpath/libc++.1.dylib /usr/lib/libc++.1.dylib micromamba

This can be signed with the hardened runtime option without breaking the executable.

So, bottom line: I think this is a bug in the micromamba build and it should not reference @rpath for static or fully static builds (it should probably be there for the dynamic build), but it seems to be a simple work-around without having to build micromamba ourselves.

Note that the micromamba executable included in Spyder is the static build, not the fully static build. I don’t think we need to include the fully static build, since, as mentioned above, the only difference is the two core macOS system libraries that should be available on all machines. FYI, the fully static build on my local machine is only 12.6 MB, while the static build is 10.9 MB; so not much difference in size.

[mrclary]

Okay, I think I’ve found a bug in the micromamba build: mamba-org/mamba#1795. The good news is that I’m pretty sure that this will be a simple work-around for by modifying our micromamba executable prior to code signing:

>> install_name_tool -change @rpath/libc++.1.dylib /usr/lib/libc++.1.dylib micromamba

I’ll try and put together a new patch this weekend, and perhaps we can just manually update the 5.3.2 release artifact. @ccordoba12, if you want to pm or zoom to discuss the best way to approach this, just let me know.