Move macOS and iOS releases from zip to dmg

[ofTheo]

I think this will solve the Project Generator issue as you would move the whole of_release_xxx folder out of the mounted dmg to your filesystem. That would remove the translocation protection without having to do any obscure / weird steps as we currently have to do now.

[artificiel]

+1 and I remember Reaper took a while to find the foolproof "recipe" which was to sign the DMG as well.

also, semi-related but it reminds me I've been working on a refactor of ofDataPath stuff, notably to solve the problem of delivering assets with an app (ends up copied "inside" the .app on macOS) yet allow a conventional "user data" directory, by allowing multiple data directories to be used without a hard relation reference to the app, in a transparent manner using traditional ofDataPath() calls. (so you can place an OF app in /Applications while having another data directory in ~/Documents/AppName or /Users/Shared/AppName/ressources or whatever makes sense (ultimately the user could choose, it becomes a GUI+prefs persistence problem)).

i will wrap things and submit a coherent bundle so it can be more easily discussed.

[jvcleave]

in case it helps I found this app useful in creating signed dmgs

https://www.araelium.com/dmgcanvas

[ofTheo]

I did a quick test and signing a dmg of the whole of_v2023.... folder didn't seem to fix translocation. I think maybe because you are not moving the app directly out of the dmg, but the folder structure it is in?

That or maybe I need to notarize the dmg too?

[dimitre]

@ofTheo I'm just guessing now but as projectGenerator is being created in another action, in another machine, maybe this is the release that should be a dmg instead of zip: https://github.com/openframeworks/projectGenerator/releases

[artificiel]

(hey I did not know about the PG nightlies...)

maybe this forum post helps https://developer.apple.com/forums/thread/128166, it states:

If you’re using a nested container format, only notarise the outermost container. For example, if you have an app inside an installer package on a disk image, sign the app, sign the installer package, and sign the disk image, but only notarise the disk image.

[ofTheo]

Thanks @artificiel and @dimitre !

I wonder if the magic / voodoo / super hard to track down / apple rule that works: is a notarized dmg for the whole OF download.

I'll def try that next but I have a sneaking suspicion that moving an OF_ROOT folder out of a disk image doesn't count as moving the app and is not enough to remove translocation.

This stuff is so frustrating though as Apple often doesn't consider these use cases and generally just makes it as difficult as possible to do anything outside their App Store model.

[ofTheo]

more discussion about the translocation stuff here: https://github.com/openframeworks/projectGenerator/issues/376

[danomatika]

For what it's worth, I spent a bunch of time on this a year ago and have some info + helper Makefile I reuse for various projects: https://github.com/zkmkarlsruhe/mac-dist-helper#description

[dimitre]

@ofTheo maybe if only projectGenerator is a dmg, so the OF download doesn't need to be? Great info @danomatika ! it would be great if you could help in this process of notarizing PG.

[danomatika]

I'd still recommend to try packaging everything into a dmg. I distribute a number of different apps with resources files and it works fine. Zirkonium3, for instance, is distributed as a folder with 3 apps and some readmes. I build each app separately with makefiles, then copy everything together into a release folder which is then turned into a dmg and notarized. The relevant part of the distribution makefile is:

##### dist

mac.dist.name = Zirkonium
mac.dist.version := $(shell \
	cat Zirkonium3/Zirkonium3.xcodeproj/project.pbxproj | \
	grep -m 1 MARKETING_VERSION | tr -d ";" | awk '{print($$3)}' \
)
mac.dist.apps = $(ZIRKONIUM3) $(SPEAKERSETUP) $(ZIRKVIDEOPLAYER)

# additional files to add to distribution
mac.dist.include = Zirkonium3/LICENSE.txt Documentation/Manual.pdf \
                   README_ZIP.txt RELEASE.txt

# add link to /Applications in dmg
mac.dmg.appslink = true

# codesign identity, usually a Developer ID Application string
mac.codesign.identity = ZKM | Zentrum fuer Kunst und Medientechnologie Karlsruhe

MACDISTHELPER_DIR=.
include $(MACDISTHELPER_DIR)/Makefile-mac-dist.mk

# set this so verify succeeds by using non mac.dist.subdir paths
mac.notarize = $(mac.dist.apps) $(mac.dist.dmg)

# rename readme
postdistdir::
	mv $(mac.dist.subdir)/README_ZIP.txt $(mac.dist.subdir)/README.txt

The dist makefile has targets for each of the apps which just call make -C on the app makefiles. In the end, my distribution process is:

make
make dist-dmg

One issue for OF is how to distribute the pre-compiled libraries. I am not sure if they need to be signed and notarized as well. I believe they would be if included in the dmg. I would suggest trying and see what the signature is in the returned dmg.

[danomatika]

@ofTheo maybe if only projectGenerator is a dmg, so the OF download doesn't need to be?

Last I tried, this will not work as the notarization of the apps inside will be invalidated by distributing the containing folder as a zip. Zip files do not support the built-in signing & notarization.

[dimitre]

I thought (maybe wrongly) dmg container would preserve the needed attributes, even inside a zip file

[ofTheo]

@danomatika do you think if the whole OF download for macOS is a signed notarized dmg like: of_0.12.0_osx_release.dmg Would moving the contents of OF out of the dmg to the HD remove the App transloction in OF/projectGenerator/projectGenerator.app ?

Or does the projectGenerator.app itself have to be moved ( not folders containing it ).

[danomatika]

@danomatika do you think if the whole OF download for macOS is a signed notarized dmg like: of_0.12.0_osx_release.dmg Would moving the contents of OF out of the dmg to the HD remove the App transloction in OF/projectGenerator/projectGenerator.app ?

Yes. If 1. the app is distributed in a signed & notarized dmg and 2. the app loads libs and resources only inside it's bundle (aka they are also signed), it should run fine.

Or does the projectGenerator.app itself have to be moved ( not folders containing it ).

No. The apps within the distribution dmgs I have made work fine. The main thing is they need to be built with a hardened runtime for the notarization to succeed.

[ofTheo]

the app loads libs and resources only inside it's bundle (aka they are also signed), it should run fine. Okay great! that is currently the case.

So I think if I understand it:

• PG app has to be signed with a hardened runtime ( but not notarized as the dmg handles that )
• DMG has to be signed and notarized

[danomatika]

Yeah. If the app is built and signed, the notarization process is then applied to the contents of the dmg when it is notarized.

[dimitre]

I was checking new notarization feature in Chalet build system and it seems notarizing a zip is possible ?

• https://github.com/chalet-org/chalet/issues/319
• https://github.com/chalet-org/chalet/issues/304

[danomatika]

That is just for the submissions of the app to Apple in order to get a ticket which you staple the app with later on. The zip itself is not notarized and distributing the notarized app within another zip will still invoke various security actions like translocation. I tested this last year.

[danomatika]

My overview notes are here: https://github.com/zkmkarlsruhe/mac-dist-helper#notarization-process

You can submit either a zip or a dmg for notarization, but only the dmg container will be signed as well as it's contents. The zip container itself cannot be notarized. You then staple the dmg and can distribute it, as needed. That would be my recommendation and this is all automated by the mac-dist-helper Makefile.

[danomatika]

In any case, you can try both:

• notarize just PG submitted in zip, then package OF tree with PG in zip
• notarize entire OF tree + PG in dmg

In all cases so far, I have moved to distributing things in dmgs.

[danomatika]

Thinking about it this morning, I will set up a test Makefile to try both options out. If it works, then we can see if/how to integrate it into OF's build structure so the CI builds can also produce notarized images. This is what we do with Pure Data.

[danomatika]

I did a test by wrapping the existing zip contents into a DMG and notarization failed:

• libfmod.dylib needs to be signed
• projectGenerator.app has invalid signature

Since I didn't build the PG, I probably need to re-codesign the app so the signature matches that of the dmg itself. I'll look into modifying the process in the next test as the makefiles were initially designed around building & notarizing a single app.