DMG Notarization


Marco S Hyman
 

A user informed me that he couldn’t install my app on the Catalina beta. I believe the issue is that even though my app is notarized, the dmg file is not. Does anyone have experience in getting a dmg notarized? Any pointers?

I’ve found some instructions on doing the job using xcrun altool which could, I think, be easily integrated into my dmg build script except for three things:

1) I need to provide a --primare-bundle-id. Is this something I make up for the dmg or the bundle ID of the included app?

2) and 3) is there a way to provide username and password without storing them in the script?


TIA,

Marc


Leo
 

 -Sign your app for notarization, but do NOT notarize it 
-Copy the signed app to your dmg master
-Convert to read-only dmg 
-Notarize and staple the dmg as you would an app  

--primary-bundle-id is just an arbitrary string, you can use anything.


Marco S Hyman
 

Thank you. I’ll give that a try.

Marc


Jack Brindle
 

Marco;

Be sure to read the three notes that Apple has at the developer site on Notarization. The one on “Customizing the Notarization Workflow” should answer many of your questions after a few reads.

Once you understand it, Notarization is pretty simple. It runs down the application tree in your app (installer in your case), and notarizes every app inside. This means that you pretty much only need to notarize the top level item (the dmg in your case), and the tool will work its way down the stack.

There is another thing that was kind of hidden for me. Enabling hardened runtime is very important for anything built after June 1, but there is more than one way to accomplish this. In Mojave, codesign can add the hardened runtime requirements, meaning you do not need to set them in the Xcpde project. This is very important for those of us that also use other configuration systems (like cmake) for our projects.

After you go through the process a time or two you will get the hang of it. Seeing and figuring out the source of the various errors can be a bit of a surprise, but things become obvious pretty quickly.

Good luck with the process!

Jack

On Aug 3, 2019, at 7:44 PM, Marco S Hyman <marc@snafu.org> wrote:

Thank you. I’ll give that a try.

Marc


Leo
 

...and while we're on it, may I add a rant:

That Apple's documentation on the subject is total DISGRACE.

There's next to ZERO amount of info on how to notarize apps distributed on dmg - which is the most common method of distribution of Mac apps.

I spent tons of time trying to follow Apple's instructions - which only lead to dead-end scenarios that had nothing to do with real-world development process.

Thankfully, other developers posted various info on their blogs, which eventually helped connecting the dots and creating successful notarization workflow. But it took enormous time. And we, independent developers, are not getting paid by the hour - so Apple's inadequate documentation translates directly into monetary losses.

I did submit an official bug to Apple notifying them that their documentation is next to useless.


Also, regarding notarizing an installer: notarizing the dmg with installer will not be enough. First, we need to notarize the installer’s payload (that is, everything the installer will install). After that we need to place the notarized (and stapled) items into the installer, and then notarize the installer itself (or the dmg with installer).

Best,
Leo


Gary L. Wade
 

Did you make mention that your particular case for DMG notarizing could use a section?  Doing that helps the team know better what you need.

On Aug 4, 2019, at 12:23 AM, leo.r@... wrote:

I did submit an official bug to Apple notifying them that their documentation is next to useless.


Leo
 

Hi Gary,

My case of dmg distribution is not special in any way (if that's what you meant). I distribute apps on dmg just the same way other developers do.

When I submitted the bug, I still couldn't even figure out how to notarize dmgs. And that's exactly want I wrote to Apple:

"Distributing apps on dmg is THE MOST COMMON method of distributing Mac apps. Where in your documentation is clear, coherent, STEP-BY-STEP instructions on how to notarize apps on dmg?"


In my view, Apple had to have a clearly identifiable section: DISTRIBUTION ON DMG. Because that's what overwhelming majority of developers do.

Two main subsections: MANUALLY (via Xcode UI) and PROGRAMMATICALLY (via command line).

Then clear, concise, step-by-step instructions on what should be done.

It would save developers days (and weeks) of wasted time, frustration, countless trial-and-errors, Internet searches etc.


Don't get me wrong: I'm a Mac fan just like anyone else here, as well as long time user and developer. But Apple really dropped the ball here when it comes to guiding developers through the notarization implementation process.


Thanks,
Leo



On Sun, Aug 4, 2019 at 08:29 AM, Gary L. Wade wrote:

Did you make mention that your particular case for DMG notarizing could use a section?  Doing that helps the team know better what you need.
 


Marco S Hyman
 

Also, regarding notarizing an installer: notarizing the dmg with installer will not be enough. First, we need to notarize the installer’s payload (that is, everything the installer will install). After that we need to place the notarized (and stapled) items into the installer, and then notarize the installer itself (or the dmg with installer).
I don’t use an installer. Notarizing the app before adding it to the dmg was not necessary and was warned against in several of those helpful blog postings. The following seemed to work, i.e. a person running the Catalina Beta was able to install the program from the notarized dmg without the warnings he was getting from the un-notarized dmg. The un-notarized dmg did contain a notarized app.

Anyway:

1) Xcode: Archive app
2) Xcode: Distribute code signed app (not notarized)
3) Run a script to create a read-only dmg, code sign it, and upload it for notarization

hdiutil create -srcfolder ${DIR} -volname ${NAME} -format UDZO ${DMG}
codesign --deep --force --verify --verbose -s ${SIG} --options runtime ${DMG}
xcrun altool -type osx --notarize-app --primary-bundle-id "org.snafu.${NAME}” \
--username “my-user-name" --password "@keychain:Notarizing" --file ${DMG}

I created an app password on-line and stored it in my keychain.

4) Note the returned Request-UUID.
5) Optional: Check status using this command:

xcrun altool --notarization-info ${Request-UUID} \
--username “my-user-name" --password "@keychain:Notarizing”

6) Wait until that status is "Package Approved" -- or you get an email from apple
7) Staple the notarization ticket to the dmg

xcrun stapler staple -v ${DMG}

The issues I ran into:

* Running Xcode 10.3 with Xcode 11 command line tools still selected.
altool did not like that!
* misreading the doc and using the wrong password instead of creating an app password.

Marc


Sak Wathanasin
 



On 4 Aug 2019, at 21:40, Marco S Hyman <marc@...> wrote:

I don’t use an installer.   Notarizing the app before adding it to the dmg was not necessary and was warned against in several of those helpful blog postings.

We (my client) use Apple's installer and notarizing the app wasn't required either - I just zipped our .pkg and submitted it for notarization. I think the separate notarization step is only required when using a 3rd party installer. This seems reasonable to me - they can't cover every installer out there -, and the docs do warn you about this.

My beef with the notarization process is the async nature, which makes it hard to incorporate into our CI process. It's a requirement of my client's release procedure that the deployed pkg be taken from the CI server - manually massaging it afterwards isn't allowed, and therefore the "stapling" process causes issues.

I added a build step that, once the zip has been submitted to the notary service, sits in a loop and runs

sleep 60
xcrun altool --notarization-info uuid_from_notarization_step -u ... -p ...

then checks for "Status: success" to be returned (gives up after 30 attempts). On success, it then "staples" the ticket.

It works, but feels fragile to me. Any other ideas? We can't be the only ones using CI servers to build.


Regards
Sak Wathanasin
Network Analysis Limited           http://www.network-analysis.ltd.uk


Gary L. Wade
 

Definitely be checking the documentation available through the search field of Xcode’s Help menu, especially in the 11 betas. That’s an interesting workflow with your CI; which one do you use? Did you add an enhancement request for your workflow? 

On Aug 5, 2019, at 2:32 AM, Sak Wathanasin <sw@...> wrote:



On 4 Aug 2019, at 21:40, Marco S Hyman <marc@...> wrote:

I don’t use an installer.   Notarizing the app before adding it to the dmg was not necessary and was warned against in several of those helpful blog postings.

We (my client) use Apple's installer and notarizing the app wasn't required either - I just zipped our .pkg and submitted it for notarization. I think the separate notarization step is only required when using a 3rd party installer. This seems reasonable to me - they can't cover every installer out there -, and the docs do warn you about this.

My beef with the notarization process is the async nature, which makes it hard to incorporate into our CI process. It's a requirement of my client's release procedure that the deployed pkg be taken from the CI server - manually massaging it afterwards isn't allowed, and therefore the "stapling" process causes issues.

I added a build step that, once the zip has been submitted to the notary service, sits in a loop and runs

sleep 60
xcrun altool --notarization-info uuid_from_notarization_step -u ... -p ...

then checks for "Status: success" to be returned (gives up after 30 attempts). On success, it then "staples" the ticket.

It works, but feels fragile to me. Any other ideas? We can't be the only ones using CI servers to build.


Regards
Sak Wathanasin
Network Analysis Limited           http://www.network-analysis.ltd.uk


Sak Wathanasin
 



On 5 Aug 2019, at 15:48, Gary L. Wade <garywade@...> wrote:

Definitely be checking the documentation available through the search field of Xcode’s Help menu, especially in the 11 betas. That’s an interesting workflow with your CI; which one do you use?

The client has bought into the Atlassian eco-system: JIRA/Bitbucket/Bamboo, so I'm stuck with it. But whatever CI systen you use, you'll have the issue of knowing when the product is ready for stapling. If I had control of the email server, I could maybe trigger another build plan using procmail or something when the confirmation email arrives.

Did you add an enhancement request for your workflow? 

To Apple? Not sure what to ask for: the main issue is that the notarization doesn't complete till 10-20 mins later, and they are unlikely to change it. Although having altool --notarization-info return an error code instead of having to scan for text strings would be an improvement.

Regards
Sak Wathanasin
Network Analysis Limited           http://www.network-analysis.ltd.uk


Leo
 

On Sun, Aug 4, 2019 at 01:40 PM, Marco S Hyman wrote:
Notarizing the app before adding it to the dmg was not necessary
oh yeah absolutely. i mentioned it in my original message (sign but do not notarize). the part about installer was in response to Jack Brindle.

cheers,
Leo


Leo
 

On Mon, Aug 5, 2019 at 02:29 AM, Sak Wathanasin wrote:
I think the separate notarization step is only required when using a 3rd party installer
That's correct, I was describing a procedure for my own custom installer. I forgot to mention that.

Leo


Leo
 

On Mon, Aug 5, 2019 at 02:29 AM, Sak Wathanasin wrote:
I added a build step that, once the zip has been submitted to the notary service, sits in a loop and runs
 
sleep 60
xcrun altool --notarization-info uuid_from_notarization_step -u ... -p ...
 
then checks for "Status: success" to be returned (gives up after 30 attempts). On success, it then "staples" the ticket.
 
It works, but feels fragile to me. Any other ideas?
Unless I'm missing something, it's the standard procedure that all developers have to follow (if we automate the process programmatically):

Upload for notarization > Query for UUID > Query for success > Staple

I built my own notarization automation tool that does exactly the same.


Leo