.dmg notarising and 'future' macOS

Tested on a ‘future’ macOS version.

When creating, codesigning and notarising a .dmg file always results in prompting ‘Unidentified Developer’ and you cannot open the .dmg (after you downloaded the .dmg file). .pkg works fine.

Anyone else have tried to do this for a ‘future’ macOS version?

BTW I tried manually doing everything in the Terminal or with AppWrapper. Both returns the notarising was successful.

Two things are possible:

  • It’s still a bug in the first ‘future’ macOS version. Although other downloaded .dmg files do not prompt this message.
  • I’m (and AppWrapper) doing something wrong to make it work for a ‘future’ macOS version.

If someone else can do some tests but don’t know how-to. Here are the steps to code sign and notarise.

STEP 1:
Codesigning on Mojave gives an error in most cases: “resource fork, Finder information, or similar detritus not allowed”
To fix this, you first need to clear the attributes:

xattr -rc </Path/to/your.app>

STEP 2:
Now you can code sign your .app, including making it ready for notarising.

codesign --force --options runtime --deep --sign "Developer ID Application: <DeveloperIDNameHere>” </Path/to/your.app>

STEP 3:
Now create a .DMG file and code sign the .DMG file. I use DMG Canvas for this. It’s one of the best in its class. Make sure the option to code sign the .dmg

STEP 4:
Now we are going to request a RequestUUID number. It will upload the .DMG file and do some magic stuff. This can take a while so be patient.

xcrun altool -t osx -f </Path/to/your.dmg> --primary-bundle-id <APPBUNDLEID>  --notarize-app --username <DeveloperIDNameHere>

After this is finished, you will see the requested UUID. It looks something like 5ecb3409-c20e-2fe5-5672-ebe6ff85c7

STEP 5:
It’s time to notarize everything with the UUID.

xcrun altool --notarization-info <RequestUUID> -u <DeveloperIDNameHere> -p @keychain:"Application Loader: <DeveloperIDNameHere>"

Now you will see a long log of data:

No errors getting notarization info.

RequestUUID: 5ecb3409-c20e-2fe5-5672-ebe6ff85c7
Date: 2018-10-20 14:07:30 +0000
Status: success
LogFileURL: https://osxapps-ssl.itunes.apple.com1540239093_56223396SXIEQYl87MG%2FezN30%3D
Status Code: 0
Status Message: Package Approved

STEP 6:
Last step, we need to staple the .DMG file.

xcrun stapler staple -v </Path/to/your.dmg>

You will see a long log but it should end with:
The staple and validate action worked!

Congratulations … you apps has now been code signed and notarised.

After you installed the app (from the .dmg) you can double check if everything is working:

spctl -a -v </Path/to/your.app>

I tried everything but the notarised .dmg files keeps popping up the ‘unidentified developer’. :frowning:
It seems I have to switch to .pkg (which does work when it is notarised).

Anyone else tried this?

Are you sure the beta 1 is not broken in this regard?

That may be the case. Although I did download .dmg files that do not show this popup. It’s an odd issue for sure.

Another possibility is that Appwrapper and I do some things wrong to make notarising work. That’s why it would be great if other try this too.

One thing I did not try it is to codesign and notarise everything from within macOS10.15 - maybe that’s a solution.

Following the steps above I get the UUID, but when I submit this

xcrun altool --notarization-info -u -p @keychain:"Application Loader: "

I get the error

*** Error: Unable to validate your application. Sign in with the app-specific password you generated. If you forgot the app-specific password or need to create a new one, go to appleid.apple.com

I have an app-specific password, but I don’t see a place to use it…

Followup: based on a post I found on Stack Overflow I tried this:

xcrun altool --notarization-info <UUID. -u -p

And this time there was a response. Unfortunately, it was

Status: invalid
LogFileURL: https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma113/v4/05/b9/58/05b95883-fb1e-5a8f-aaf2-71443daa54bc/developer_log.json?accessKey=1560287095_5119711709131422822_nWNQdGWjttX8VoTo%2B53hMWCVnUB%2F%2BaNHX0%2BiJPJhYoWaDZoM2O51RoMHIZgoLL8YWV3bWr35MT8AOKJSxG1VWlGhb4yIlCImob%2FBxhRmyzVy0GbszstK2C4anBphGOMZYkbLpXkJK%2FAk2kUu5PYISudZsJlLeRJexiGyPcHbOHs%3D
Status Code: 2
Status Message: Package Invalid

[quote=440699:@Christoph De Vocht]I tried everything but the notarised .dmg files keeps popping up the ‘unidentified developer’. :frowning:
It seems I have to switch to .pkg (which does work when it is notarised).

Anyone else tried this?[/quote]
This was my experience too. I have been distributing apps lately as .pkgs for this reason. I’d rather ship DMGs but I couldn’t get them notarised and I had to move on.

No need to create an app specific password. But if you want to do this, you need to use the app specific password instead of the ID developer password.

Do the same steps described as above but replace step 4 and 5 with the below steps.

request a RequestUUID number:

xcrun altool -t osx -f </Path/to/your.dmg> --primary-bundle-id <APPBUNDLEID> --notarize-app --username <DeveloperIDNameHere> -p xxxx-xxxx-xxxx-xxxx

notarize everything with the UUID.

xcrun altool --notarization-info <RequestUUID> -u <DeveloperIDNameHere> -p xxxx-xxxx-xxxx-xxxx

Change “xxxx-xxxx-xxxx-xxxx” into the app specific password.

[quote=440711:@Jonathan Ashwell]Followup: based on a post I found on Stack Overflow I tried this:

xcrun altool --notarization-info <UUID. -u -p

And this time there was a response. Unfortunately, it was

Status: invalid
LogFileURL: https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma113/v4/05/b9/58/05b95883-fb1e-5a8f-aaf2-71443daa54bc/developer_log.json?accessKey=1560287095_5119711709131422822_nWNQdGWjttX8VoTo%2B53hMWCVnUB%2F%2BaNHX0%2BiJPJhYoWaDZoM2O51RoMHIZgoLL8YWV3bWr35MT8AOKJSxG1VWlGhb4yIlCImob%2FBxhRmyzVy0GbszstK2C4anBphGOMZYkbLpXkJK%2FAk2kUu5PYISudZsJlLeRJexiGyPcHbOHs%3D
Status Code: 2
Status Message: Package Invalid[/quote]

When i took a look at the Logfileurl, it seems to show


“issues”: [
{
“severity”: “error”,
“code”: null,
“path”: “Bookends2.dmg/Bookends.app/Contents/Frameworks/v4rb_cocoa_64.dylib”,
“message”: “The binary uses an SDK older than the 10.9 SDK.”,
“docUrl”: null,
“architecture”: “x86_64”
},

The v4rb framework is using an older SDK and seems to have caused the submission to be invalid.

“that which shall not be named” :slight_smile:
a really old SDK could cause them a lot of issues as you see

[quote=440732:@Norman Palardy]“that which shall not be named” :slight_smile:
a really old SDK could cause them a lot of issues as you see[/quote]

Isn’t 2019R1.1 using SDK 10.9? If I am not mistaken, you definitely need to use 2019R1.1 to make notarising work.

BTW I did all may testing with compiled apps using 2019R1.1 and every-time I got it notarised successfully (including receiving a mail from Apple the app is ready for deployment). Still it shows the ‘Unidentified Developer’ for the .dmg file. The app itself or the .pkg file is not showing the popup. Again, it’s only the .dmg file.

Thanks, very informative. I am using 2019R1.1, BTW.

There are other issues.

One is that the app isn’t hardened. Is there a straightforward way to do this via the .plist?

Another is the lack of secure timestamp. I’ve read that XCode will add that for you. But of course we’re not using that.

No. We updated to the 10.14 SDK in 2018r4.

No. It’s done as a code signing step. You’ll need to add two options to your codesign call.

––timestamp ––options=runtime

…and fwiw, you need to do this on 10.13.6 or above.

No
run

otool -l
against a binary and you should find a load command like

Load command 10
      cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.10
      sdk 10.14

what this command tells you is the SDK version linked against (10.14) and the lowest deployment version supported (10.10)

If you follow the above steps, the app will be hardened and timestamps are added.

When code signing you should already be using this; I seem to recall that Apple recent ‘forced’ this option on without the need for the option to be specified. However it could be they reversed this decision at some point.

A quick test is to try code signing with no internet connection; no matter what I try I get a code signing failure because it can’t connect to Apple (for the secure time stamps). It also means that you can’t fiddle with your system clock, otherwise that causes failures and even fails to verify the code signature.

@Edwin Lau: which version of Valentina did you use for signing? If it’s the current version did you inform the Valentina folks?

@Beatrix Willius I think you mean me. I’m using Valentina 8.2.1. I posted an inquiry about the current version of Valentina on the Paradigmasoft forum.