Notarizing Dmg with an unsigned element

Why not sign everything and notarize? That solves the problem completely.

It is not a problem to re-sign a binary. That fundamental aspect of signatures. Deliver signed and notarized content to your customers. That way, they have a guarantee that your content is legitimate. Then can build their own content and then re-sign and re-notarize it for their own customers. That's not problem. That's how the App Store works in fact.

You might want to investigate other options that Apple provides for business-to-business software distribution. I'm not familiar with those, but I know they exist.

Our product is a developpement tool that can be simply used as a database.

Some customers will sign their customized binaries and some will not.

If they do not then the problem is that they will still distribute a damaged signed (with our certificate) package because the signature will be damaged due to customization.

We do not want to provide, by design, a means to create product with wrong signature.

If it's a development tool, then it's not your problem. I think we all know by now that Xcode can be used to create a prodocut with a damaged or wrong signature. 🙂

Going forward, it shouldn't be that big of a deal. Apple is going to stop running unsigned binaries altogether "in a future version" of macOS. Your customers won't have any option, other than disabling SIP or similar.

john daniel wrote:

Why not sign everything and notarize?

That’s my take on this as well. Life is going to be a lot easier if you just notarise your whole package and then have the client re-sign anything as part of their distribution flow. My recommendation is that you work to make this easier, rather than try to walk a narrow path through the notarisation system.

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

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

ps DTS is closed 21 Dec through 1 Jan.

Hello,

thank you both for your answers and the advices you have provided.

To sum up here is how I understand your answers to my questions :

1. So far, we can mount unnotarized DMG (downloaded through internet). Will this continue to work on 2020?

As signing DMG is not mandatory (https://developer.apple.com/news/?id=12232019a), this will continue to work but Apple recommend to have the dmg at least signed.

2. I have read it is recommended to notarize at dmg level. Is it because it is easier or are things are going to change preventing us to do it as we does currently ?

I am not sure about this one : it is easier to just notarize everything as recommended so we want have issues if Apple changes the behavior in the future.

3. Will every warning in the notarization log will be turned into an error on 2020 and the whole notarization request in the dmg will be rejected, or will the notarization process will create ticket for each top component of a given DMG ?

Every warning will be turned into error starting Feb 3rd 2020 and the whole package will be rejected as it use to be in Catalina beta (before september 2019).

4. Do you have any advice of what we should be doing instead ?

Yes, make it simple. Even your small customers should subscribe to Apple developper program, get a certificate and notarize the built application. If they do not, then signature will be broken but this is not our problem.

Do you agree with all that ?

Thank you all for your help. I hope this discussion will help other users too.

Kind regards.

1. So far, we can mount unnotarized DMG (downloaded through internet). Will this continue to work on 2020?

I can’t answer questions about The Future™.

2. I have read it is recommended to notarize at dmg level.

Correct. Our general advice is that you notarise your outermost container. For example, if you have an app inside an installer package inside a disk image, you’d sign everything but only notarise the disk image.

Is it because it is easier … ?

Yes.

or are things are going to change preventing us to do it as we does currently

See my answer to question 1.

3. Will every warning in the notarization log will be turned into an error on 2020 … ?

I expect that the notary service will still treat some issues as warnings after the upcoming change back to treat-warnings-as-errors mode. It’s hard to comment further without the details on the specific warning you’re concerned about. However, I will note that notarising an unsigned disk image does not currently generate a warning.

4. Do you have any advice of what we should be doing instead ?

If folks are shipping the resulting app, they will need to sign and notarise that. If they don’t, their users are going to run into Gatekeeper problems.

If folks are only running the app locally, they should still be signing it. To start, at WWDC 2019 we announced that “in a future version of macOS, unsigned code will not run by default anymore”. However, unsigned code causes problems on current versions of macOS. For example, the system uses the app’s code signature to determine its access to keychain items.

If necessary these folks can use ad hoc signing (in Xcode 11 this is shown as Sign to Run Locally). However, it’s better if they use a stable code signing identity based on their Apple ID. Note that this does not require that they pay to join the developer program. Xcode allows any Apple ID to be used for local signing (Xcode 11 shows this as a Personal Team).

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

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

> notarise your whole package and then have the client re-sign anything as part of their distribution flow.

Quinn,

At the risk of wandering off-topic, can you clarify a point about signing? Is it true that signing should always over-write any existing code-signing?

I ask because I've had a recent case where this was done in SD Notary. The signing (of a framework) succeeded and notarization succeeded, although the app then failed when it tried to load the framework. I checked the logFileURL and there was an issue saying the framework was not signed.

I repeated the exercise, this time starting with an un-signed version of the framework, and all went well. (I have no idea how the previous version was signed -- it was from a user).

At the risk of wandering off-topic …

I’m going to recommend that you start a new thread here; this one is long enough already (-:

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

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

Hello,

ok, I understand. Thank you so much for your help.

regards,

Migad