OpenSSL won't load once app is notarized

To start, I recommend against using OpenSSL for TLS. There are two ways you can use it, and both have serious drawbacks:

• The OpenSSL library that’s available via the macOS SDK was deprecated many years ago. That’s because we can’t update the library without breaking binary compatibility. The library may get patched to fix really critical vulnerabilities, but it’s still way behind.

• The alternative is to build OpenSSL and include it with your app. There are multiple problems with this:

  • Your TLS won’t behave like other TLS implementations on the system.

  • You take on responsibility for fixing any security vulnerabilities that crop up.

It’s much better to use the system TLS, preferable via one of our TCP+TLS APIs (like Network framework).

Of course, this is not directly relevant to the problem you’re seeing. That problem is most probably related to library validation. Notarisation requires the hardened runtime, and the hardened runtime turns on library validation by default. With library validation on, your process can only load libraries signed by your team or signed by Apple. It seems likely that:

1. You’ve bundled a copy of the OpenSSL libraries in your code.

2. Those libraries are not signed by your team.

You should look at how your program is signed. Specifically, make sure that all the code that you ship is signed by your team. Technote 2206 macOS Code Signing In Depth has lots of good advice on this topic.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Quinn,

Thank you for your response.

As far as I can tell, everything bundled in the code is signed.

A little more detail - the module that actually calls the SSL library is an Indy IO Handler TIdSSLIOHandlerSocketOpenSSL. The documentation for that module says that it is not necessary to install an SSL library with the application, as the required libraries are already included with the operating system.

Specifically, it refers to libcrypto.dylib and libssl.dylib.

Without notarization, the project works fine without explicitly installing those libraries. What do I need to do differently to allow the libraries to be loaded by a notarized app?

Thank you for your help. This is currently a "stopper" for preparing for Catalina.

BTW, all of the Apple notices point to a mid-September release for Catalina, but one of our users claims that his system auto-updated to Catalina yesterday (and he is not aware of being in a beta program). Are users currently being migrated to Catalina?

Again, thank you.

Scott

Postage Saver Software

Specifically, it refers to

libcrypto.dylib

and

libssl.dylib

.

If you’re referring to

/usr/lib/libcrypto.dylib

/usr/lib/libssl.dylib

In addition, if you’re using OpenSSL for TCP+TLS, you have to worry about the TCP side of things. OpenSSL’s TCP client uses pretty standard BSD Sockets code, and thus will fail in various situations where iOS’s higher-level TCP APIs will work.

In in all, I think you’d be better off replacing this code with something that just calls the Network framework.

What do I need to do differently to allow the libraries to be loaded by a notarized app?

Despite the fact that they’re deprecated, those libraries are signed by Apple and should be usable from a notarised app. Are you sure you’re referencing them by absolute path? I’ve seen problems like this before when folks were referencing system libraries via an rpath. See this post for the details.

Are users currently being migrated to Catalina?

Not that I’m aware of.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Quinn,

Thanks. Embarcadero is working on this, as I have no access to how they are referencing the dylibs in their code, and, as I mentioned at the beginning, these are projects built in Delphi Fire Monkey.

Meanwhile, can you tell me:

1.) Assuming I have an OSX app that runs correctly when notarized (as our others do), is it reverse compatible with earlier OSX versions, or do we need to create separate non-notarized versions of any updates for users of legacy OSX? We currently advertise support back through Yosemite.

2.) We distribute in a .dmg installer (using DMG Canvas). Will that need to be notarized to be acceptable to Catalina, or just the actual package inside the installer? I know the can be notarized, but must they be?

Again, thanks. I have scoured the web but have not found definitive answers to these.

Scott

1) Notarization, and the hardened runtime, is just a metadata flag. The flag has no meaning on older versions of the OS and will be ignored. It sounds like your problem is getting older software running on Catalina, which is a different problem and has nothing to do with notarization directly. You will have to find a solution that works with Catalina and older software. Unfortunately, if you are dependent upon some 3rd party product that is not very macOS-savvy, your options are very limited.

2) What happend when you try to open the un-notarized DMG on Catalina? The final arbiter of any such question is the behaviour of the operating system itself, not what people say on some discussion forum.

Hi John,

Thanks for your comment.

Good to know about notarization not affecting the older OSX versions.

As to the .dmg issue, I've learned from the folks at DMG Canvas that this is a moving target from Apple, hence the conflicting posts that I have read (with, of course, nothing really official from Apple.) But in this case, even testing against a Catalina beta is of little help, as apparently the original betas required downloaded DMGs to be notarized, but the released version will not. But, of course, that's subject to change....

Again, thanks.

Catalina has not yet been released. Any statements about what it will or won't do should be ignored. No one outside of Apple, and perhaps even inside, knows what Catalina will do upon release. In the past, Apple has even skipped releasing the final build as a beta. Furthermore, there is no real distinction between "major" and "minor" releases beyond marketing. If you are releasing software under assumptions, any minor update may prove your assumptions wrong.

This means that you need to prepare for all eventualities. This may mean abandonning unnecessary complications like DMG files, or even installers altogether, if you can. If you can't, then go ahead and attempt to notarize everything that you can. If you notarize and it is not needed, there's no harm.

Assuming I have an OSX app that runs correctly when notarized (as our others do), is it reverse compatible with earlier OSX versions, or do we need to create separate non-notarized versions of any updates for users of legacy OSX?

Yes. I’ve personally run a notarised app back to 10.7, which is the oldest VM I have easy access to.

We distribute in a .dmg installer (using DMG Canvas). Will that need to be notarized to be acceptable to Catalina, or just the actual package inside the installer?

Our general advice is that you notarise the outmost container. Thus, if you have a

.app

.pkg

.dmg

.app

.pkg

.dmg

.dmg

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks.