Bugzilla

This bug is very complex (involving, as it does, third party applications/utilities, possibly several of them at once). And there doesn't (yet) seem to be a clear path to dealing with it by unilaterally disabling one or more of those third party apps. But there is one clear rule that must always be followed -- *never* allow `/usr/lib/libcrypto.dylib` to be loaded on macOS and OS X systems. Going back many years, the code that loads this dylib also crashes it -- the `___report_load` function, to which the first pointer in its `__mod_init_func` section points.

Apple's justification for this is that, if you use Apple's "crypto" functions, you should really be using versioned copies, like those found in `libcrypto.0.9.7.dylib`, `libcrypto.0.9.8.dylib`, `libcrypto.35.dylib`, `libcrypto.41.dylib`, `libcrypto.42.dylib`, `libcrypto.44.dylib` and so forth.

This rule does *not* apply to `libcrypto.dylib` from any other vendor than Apple. It's almost certain that the third party apps that trigger these crashes are trying (and failing) to use a non-Apple `libcrypto.dylib` located somewhere else than `/usr/lib` .

But the files in `/usr/lib` are system files -- which means they're Apple files. It's always been difficult to replace these with non-Apple files. And since macOS 11 this has basically been impossible. So it's safe to assume that `/usr/lib/libcrypto.dylib` is always an Apple system file, and must never be allowed to load.

This bug is very complex (involving, as it does, third party applications/utilities, possibly several of them at once). And there doesn't (yet) seem to be a clear path to dealing with it by unilaterally disabling one or more of those third party apps. But there is one clear, simple rule that must always be followed -- *never* allow `/usr/lib/libcrypto.dylib` to be loaded on macOS and OS X systems. Going back many years, the code that loads this dylib also crashes it -- the `___report_load` function, to which the first pointer in its `__mod_init_func` section points.

Apple's justification for this is that, if you use Apple's "crypto" functions, you should really be using versioned copies, like those found in `libcrypto.0.9.7.dylib`, `libcrypto.0.9.8.dylib`, `libcrypto.35.dylib`, `libcrypto.41.dylib`, `libcrypto.42.dylib`, `libcrypto.44.dylib` and so forth.

This rule does *not* apply to `libcrypto.dylib` from any other vendor than Apple. It's almost certain that the third party apps that trigger these crashes are trying (and failing) to use a non-Apple `libcrypto.dylib` located somewhere else than `/usr/lib` .

But the files in `/usr/lib` are system files -- which means they're Apple files. It's always been difficult to replace these with non-Apple files. And since macOS 11 this has basically been impossible. So it's safe to assume that `/usr/lib/libcrypto.dylib` is always an Apple system file, and must never be allowed to load.

This bug is very complex (involving, as it does, third party applications/utilities, possibly several of them at once). And there doesn't (yet) seem to be a clear path to dealing with it by unilaterally disabling one or more of those third party apps. But there is one clear, simple rule that must always be followed -- *never* allow `/usr/lib/libcrypto.dylib` to be loaded on macOS and OS X systems. Going back many years, the code that initializes this dylib also crashes it -- the `___report_load` function, to which the first pointer in its `__mod_init_func` section points.

Apple's justification for this is that, if you use Apple's "crypto" functions, you should really be using versioned copies, like those found in `libcrypto.0.9.7.dylib`, `libcrypto.0.9.8.dylib`, `libcrypto.35.dylib`, `libcrypto.41.dylib`, `libcrypto.42.dylib`, `libcrypto.44.dylib` and so forth.

This rule does *not* apply to `libcrypto.dylib` from any other vendor than Apple. It's almost certain that the third party apps that trigger these crashes are trying (and failing) to use a non-Apple `libcrypto.dylib` located somewhere else than `/usr/lib` .

But the files in `/usr/lib` are system files -- which means they're Apple files. It's always been difficult to replace these with non-Apple files. And since macOS 11 this has basically been impossible. So it's safe to assume that `/usr/lib/libcrypto.dylib` is always an Apple system file, and must never be allowed to load.