Notarization warnings being treated as errors when the notarized app is bundled in another

A "me too" post.

As for Nilesh, my app notarizes fine but with warnings about embedded binaries using an older SDK.

But if I try to notarize a .pkg containing my app, all those same warnings get turned into errors and the notarization fails.

Do I actually need to notarize the .pkg, or can I simply notarize the app first then build the .pkg from that?

Do I actually need to notarize the

.pkg

… ?

Let me make sure I have this right:

• You have an app.

• You wrap that app in an installer package.

• You distribute that installer package to your customers.

Correct?

If so, the standard approach is:

1. Sign the app.

2. Build the package.

3. Sign the package.

4. Notarise the package.

That is, you only notarise your outermost container.

Putting a notarised app inside a non-notarised package is likely to cause problems.

As to your bigger picture problem — the fact that the errors-are-warnings mode on the notarisation servers isn’t crossing the package boundary — I have not looked into that in depth but it certainly seems bugworthy to me.

Please post your bug number, just for the record.

Having said that, your actual problem is that you’re using libraries built with an ancient SDK, and you will eventually need to grasp that nettle. It might be better to spend your time on that rather than on this.

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

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

Thanks Quinn for clarifying about needing the .pkg signed. I gathered as much after reading other responses from you on this forum.

I have entered a bug -- FB7457705 -- for the errors not being treated as warnings in the package. For the record, our app is in a package, which is in a disk image. Eventually we will want to notarize the disk image. But I was trying this as an intermediate step.

As for the actual problem, the libraries in question are an embedded Java 8 JRE from Azul Systems, built with the 10.8 SDKs. We do have plans to move to a more recent Java JRE. Their Java 11 JRE is built with the 10.9 SDK and their Java 12 JRE is built with the 10.13 SDK. But the architectural changes required to move to a later Java are too great for us to roll out just yet. And it is not feasible for us to wait to notarize our app until we can switch Javas.

Xcode 6.2 runs on Mac OS 10.9. I have a VM with Mavericks and Xcode 6.2. I used it recently in a little project to demonstrate how easy notarization really is. I built and notarized an ancient version of GhostScript for 64-bit so that it would run on Catalina. Probably the most difficult part was fixing a crazy macro in GhostScript that never should have been done in the first place.

Hi,

Sorry for the late response. Let me clear my scenarios if it sounded ambiguous in the first place.

1. Get A.pkg successfully notarized with a warning "The binary uses a SDK older than the 10.9 SDK.” for a file(say SampleFile).

2. Create B.pkg with A.pkg bundled in it (A.pkg treated as a file).

3. Notarize B.pkg. The notarization fails with severity error for a file(SampleFile) that was originally reported with a warning in step 1.

Anyways, I was able to successfully notarize B.pkg by resolving all the warnings of A.pkg and bundling A.pkg which was notarized without any warnings/errors.

A.pkg is our new product and B.pkg is our legacy product. I need to bundle A.pkg in B.pkg until B.pkg is completely deprecated.

Regards,

Nilesh