.pkg Installers, Rosetta and SHA256 hashes
- KVRAF
- Topic Starter
- 1745 posts since 2 Jul, 2018
1) I am using a M1 Mac with Big Sur to build universal binaries (Intel+ARM).
2) Then I copy the .component and the .vst to my Intel Mac with Mac 10.14. Here I build the .pkg installer with Packages and run the Notarisation. I am using the old Mac to keep downward compatibility with older MacOS versions, as the Certificates on BigSur are SHA256 only.
Big Sur does not correctly sign pkg files using SHA1 which is required by El Capitan (10.11) and earlier (planed obscolescense?). Sierra (10.12) and later seem to correctly pickup the SHA256 signature.
Reference: https://developer.apple.com/forums/thread/664842
3) One customer reported that he was not able to run my .pkg installer, as it would 'just run under Rosetta' and he had uninstalled Rosetta on his system.
--------------------------------------------
Question1:
How do you handle the SHA1 issue with your installers?
Question2:
I am confused about the 'Rosetta issue' that the customer reported. Is the customer telling missinformation? If not what does happen with our old installers when Apple should drop Rosetta, especially those for soundsets. Does Rosetta affect .pkg installers at all?
Question3:
How do the .pkg installers work from the technical side. I thougth it would just be some kind of script that decompresses and copys files
2) Then I copy the .component and the .vst to my Intel Mac with Mac 10.14. Here I build the .pkg installer with Packages and run the Notarisation. I am using the old Mac to keep downward compatibility with older MacOS versions, as the Certificates on BigSur are SHA256 only.
Big Sur does not correctly sign pkg files using SHA1 which is required by El Capitan (10.11) and earlier (planed obscolescense?). Sierra (10.12) and later seem to correctly pickup the SHA256 signature.
Reference: https://developer.apple.com/forums/thread/664842
3) One customer reported that he was not able to run my .pkg installer, as it would 'just run under Rosetta' and he had uninstalled Rosetta on his system.
--------------------------------------------
Question1:
How do you handle the SHA1 issue with your installers?
Question2:
I am confused about the 'Rosetta issue' that the customer reported. Is the customer telling missinformation? If not what does happen with our old installers when Apple should drop Rosetta, especially those for soundsets. Does Rosetta affect .pkg installers at all?
Question3:
How do the .pkg installers work from the technical side. I thougth it would just be some kind of script that decompresses and copys files
- KVRist
- 60 posts since 17 Oct, 2012
Markus,
I believe the newer version of Packages builds as Universal Intel/Arm64:
http://s.sudre.free.fr/Software/Package ... notes.html
I am intentionally not notarizing pre-Mojave "legacy" versions of my plugins because I believe the notarization breaks something with packages on earlier versions of macOS besides the SHA1 - at least a few users weren't able to open the package installers on Sierra...
But if you are aiming to produce one installer package fore each plugin, It doesn't feel like it's possible to support notarization+Arm64+older versions of macOS . I think the best thing to do is just to have two versions of your plugins; one for 10.9-10.15 and one for 11+. In my case, I also have versions for Mojave and Catalina, as I feel like there are some differences there in the macOS system frameworks I am using.
I'm also still just product-signing/notarizing things on Catalina: I don't trust Apple not to break certain things like that in newer versions of macOs. I've heard about notarization issues on BigSur before and therefore avoid using it for this process unless it's for something that will be deployed only on BigSur/Monterey...
I believe the newer version of Packages builds as Universal Intel/Arm64:
http://s.sudre.free.fr/Software/Package ... notes.html
I am intentionally not notarizing pre-Mojave "legacy" versions of my plugins because I believe the notarization breaks something with packages on earlier versions of macOS besides the SHA1 - at least a few users weren't able to open the package installers on Sierra...
But if you are aiming to produce one installer package fore each plugin, It doesn't feel like it's possible to support notarization+Arm64+older versions of macOS . I think the best thing to do is just to have two versions of your plugins; one for 10.9-10.15 and one for 11+. In my case, I also have versions for Mojave and Catalina, as I feel like there are some differences there in the macOS system frameworks I am using.
I'm also still just product-signing/notarizing things on Catalina: I don't trust Apple not to break certain things like that in newer versions of macOs. I've heard about notarization issues on BigSur before and therefore avoid using it for this process unless it's for something that will be deployed only on BigSur/Monterey...
-
tasmaniandevil tasmaniandevil https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=62450
- KVRAF
- 1713 posts since 22 Mar, 2005 from a planet called u-he
We also overlooked this at first. We had our plugins running natively, but the installer itself was still running via Rosetta.Markus Krause wrote: ↑Fri Jun 03, 2022 7:40 am 3) One customer reported that he was not able to run my .pkg installer, as it would 'just run under Rosetta' and he had uninstalled Rosetta on his system.
I'm not very versed in the technical details (I'm not a developer), but Lady Gaia gave us a very helpful hint how to make the installer run natively.
Maybe this is useful for you as well: viewtopic.php?p=8085952#p8085952
- KVRAF
- 1872 posts since 13 Apr, 2011 from EU
I'll write here as well as someone may miss the other replies in the other thread.
If you are using Packages you need to specify in the advanced options, and then you might need to resign the PKG directly with productsign. Not sure if Packages has been updated to fix the re-signing thing, but that was the case one year ago.
Also, with Packages you need to double check if the notarization actually went through correctly. I remember sometimes we got a "Package Approved" but then checking with we would get something like "rejected".
I strongly suggest using pkgbuild instead of Packages, so you won't need to resign (if that's still the case) and will avoid other possible issues.
This is not necessary. Since Big Sur 11.3, we are building Universal 2 Binary plugins and PKGs with correct SHA1 and SHA256 signatures that can be opened from OS X 10.9 to macOS 12.x. No issues with notarizations or signatures.adammonroe wrote: ↑Sat Jun 18, 2022 10:03 pmI think the best thing to do is just to have two versions of your plugins; one for 10.9-10.15 and one for 11+.
If you are using Packages you need to specify
Code: Select all
hostArchtectures="x86_64,arm64"
Also, with Packages you need to double check if the notarization actually went through correctly. I remember sometimes we got a "Package Approved" but then checking with
Code: Select all
spctl -a -vvv -t install
I strongly suggest using pkgbuild instead of Packages, so you won't need to resign (if that's still the case) and will avoid other possible issues.
- KVRAF
- Topic Starter
- 1745 posts since 2 Jul, 2018
I don't use the signing of Packages, but sign it manually with command line. It is/was broken.
hostArchitectures="x86_64,arm64" is probably referring to pkgbuild syntax.
In Packages it works using 'arm64 x86_64' with a space.
---------------------------------------------
My build setup works this way:
1) Build and codesign with XCode on BigSur as M1/Intel universal binary on my M1 machine.
2) Copy the .component and .vst to my Intel Machine with MacOS 10.14. There I run some tests if the plugins work properly.
3) Run packages in MacOS 10.14 with hostArchitectures="x86_64 arm64".
4) productsign, notarize and staple on MacOS 10.14
hostArchitectures="x86_64,arm64" is probably referring to pkgbuild syntax.
In Packages it works using 'arm64 x86_64' with a space.
---------------------------------------------
My build setup works this way:
1) Build and codesign with XCode on BigSur as M1/Intel universal binary on my M1 machine.
2) Copy the .component and .vst to my Intel Machine with MacOS 10.14. There I run some tests if the plugins work properly.
3) Run packages in MacOS 10.14 with hostArchitectures="x86_64 arm64".
4) productsign, notarize and staple on MacOS 10.14
- KVRAF
- 1872 posts since 13 Apr, 2011 from EU
All I'm saying is that these steps are completely unnecessary if you want to automate your builds. All you need is a Silicon Mac with Big Sur 11.3+ and Xcode 12.5, and you can support from OS X 10.9 to macOS 12.Markus Krause wrote: ↑Mon Jun 20, 2022 9:32 am2) Copy the .component and .vst to my Intel Machine with MacOS 10.14. There I run some tests if the plugins work properly.
3) Run packages in MacOS 10.14 with hostArchitectures="x86_64 arm64".
4) productsign, notarize and staple on MacOS 10.14
If you like to do things manually, juggling plugins around two computers, sure...
- KVRAF
- 7868 posts since 12 Feb, 2006 from Helsinki, Finland
Does that build for i386 too (32-bit)? On my M1 running macOS 12.4 with latest command-line tools 13.4.0.0.1.1651278267 (latest I think) I can build just fine like this:audiothing wrote: ↑Mon Jun 20, 2022 10:36 am All I'm saying is that these steps are completely unnecessary if you want to automate your builds. All you need is a Silicon Mac with Big Sur 11.3+ and Xcode 12.5, and you can support from OS X 10.9 to macOS 12.
If you like to do things manually, juggling plugins around two computers, sure...
Code: Select all
-arch x86_64 -arch arm64 -mmacosx-version-min=10.9
Code: Select all
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSViewController.h:248:39: error: unknown type name 'NSExtensionContext'; did you mean 'NSAnimationContext'?
@property (nullable, readonly,retain) NSExtensionContext *extensionContext API_AVAILABLE(macos(10.10));
Personally I don't really care about 32-bit .. so whatever .. but any idea if this is xcode 13 issue, or did it break earlier and I just never noticed?
- KVRAF
- 1872 posts since 13 Apr, 2011 from EU
We have dropped support for 32bit in 2018, so I have no idea, to be honest.
- KVRAF
- 7868 posts since 12 Feb, 2006 from Helsinki, Finland
After some Google:audiothing wrote: ↑Mon Jun 20, 2022 11:11 amWe have dropped support for 32bit in 2018, so I have no idea, to be honest.
So looks like it's a much older issue and I just never noticed... oh well...The macOS 10.14 SDK no longer contains support for compiling 32-bit applications. If developers need to compile for i386, Xcode 9.4 or earlier is required. (39858111)
- KVRAF
- Topic Starter
- 1745 posts since 2 Jul, 2018
We did not get a single complain when we dropped 32bit support on Mac last year. I don't think it makes sense to waste development time with this.
- Banned
- 4021 posts since 7 Sep, 2002
- Banned
- 4021 posts since 7 Sep, 2002