[Openmcl-devel] Monterey: crash loading library (libcrypto)

Gary Palter palter at clozure.com
Wed Oct 27 10:49:42 PDT 2021


I have no problem loading websocket-driver via Quicklisp on macOS Monterey.

The error below is caused by cl+ssl trying to load libcrypto without a specific version which is no longer allowed by macOS. Apparently, cl+ssl was updated a while back to explicitly try specific versions to avoid this. So, check to make sure that all your distributions are up-to-date (ql:update-all-dists).

  - Gary Palter
    Principal Software Engineer
    Clozure Associates



> On Oct 27, 2021, at 10:06 AM, Christopher Stacy <cstacy at dtpq.com> wrote:
> 
> On 10/26/21 4:44 PM, Christopher Stacy wrote:
> >   System Version:    macOS 12.0.1 (21A559)
> >   Kernel Version:    Darwin 21.1.0
> >   System Integrity Protection:    Disabled
> >
> > Clozure Common Lisp Version 1.12 (v1.12) DarwinX8664
> > ; Loading "websocket-driver"
> > ? WARNING: /usr/local/src/ccl/dx86cl64 is loading libcrypto in an unsafe way
> > Process inferior-lisp abort trap:
> > 6
> 
> I suspect this may be a code-signing issue.
> 
> MacOS has a feature to prevent "DLL hijacking" called "Library Validation". This cannot be disabled without a kernel patch (and you don't want to do that).
> 
> 
> Starting in iOS 8 and macOS 10.10, the system offers library validation as a policy for the dynamic libraries that a process links against. The policy is simple: A program may link against any library with the same team identifier in its code signature as the main executable, or with any Apple system library. Requests to link against other libraries are denied.
> 
> The team identifier is the 10-character alphanumeric string, such as YH9SZ5LKR4, associated with your developer account, and recorded in your Apple-issued signing certificate.
> 
> I didn't see this issue at all in the last version of Big Sur. But when I installed Monterey I get the above error right away when I tried to load the CCL program I was working on (fine) before the OS reboot.
> 
> The protection is supposed to be enabled at the app level by a codesign option. (Since I'm running the same binaries, I don't know why this wasn't a problem before. Something to do with the new OS obviously.)
> 
> I might be off-track with this, because the sample error message for failing this doesn't look like the one I am getting from CCL. (Maybe that has something to do with CCL using an older API or something, though. I have no idea what I am talking about.)
> 
> The error string includes the name of the process, the pid, and the path to the dynamic library. For example, the process ls with pid 528 trying to load the library /private/tmp/libncurses.5.4.dylib generates the following output:
> 
> AMFI: ls(pid 528) - [deny-mmap] mapped file does not have a matching team identifier: /private/ tmp/libncurses.5.4.dylib
> 
> AMFI: ls(pid 528) - [deny-mmap] process has team identifier BGHDFMN54X: /private/tmp/ libncurses.5.4.dylib
> 
> AMFI: ls(pid 528) - [deny-mmap] mapped file has team identifier GDASFLKMKO: /private/tmp/ libncurses.5.4.dylib
> 
> Does anyone know what's actually going on and how to work around it?
> 
> I am just trying to use quicklisp to load the web drivers I need.
> 
> Dead in the water.
> 
> As I guess everyone is who upgrades to Monterey.
> 
> Btw, Monterey seems quite zippy on this 2014 Mini!
> 
> 
> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20211027/75447f31/attachment.htm>


More information about the Openmcl-devel mailing list