New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move macOS and iOS releases from zip to dmg #7563
Comments
+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. |
in case it helps I found this app useful in creating signed dmgs |
I did a quick test and signing a dmg of the whole of_v2023.... folder didn't seem to fix translocation. That or maybe I need to notarize the dmg too? |
@ofTheo I'm just guessing now but |
(hey I did not know about the PG nightlies...) maybe this forum post helps https://developer.apple.com/forums/thread/128166, it states:
|
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. |
more discussion about the translocation stuff here: |
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 |
@ofTheo maybe if only projectGenerator is a dmg, so the OF download doesn't need to be? |
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
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. |
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. |
I thought (maybe wrongly) dmg container would preserve the needed attributes, even inside a zip file |
@danomatika do you think if the whole OF download for macOS is a signed notarized dmg like: of_0.12.0_osx_release.dmg Or does the projectGenerator.app itself have to be moved ( not folders containing it ). |
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.
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. |
So I think if I understand it:
|
Yeah. If the app is built and signed, the notarization process is then applied to the contents of the dmg when it is notarized. |
I was checking new notarization feature in Chalet build system and it seems notarizing a zip is possible ? |
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. |
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. |
In any case, you can try both:
In all cases so far, I have moved to distributing things in dmgs. |
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. |
I did a test by wrapping the existing zip contents into a DMG and notarization failed:
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. |
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.
The text was updated successfully, but these errors were encountered: