I just bumped into the following article... https://developer.apple.com/library/archive/documentation/Security/Conceptua...
and the section "Ensuring Proper Code Signatures for Nested Code" made me remember some reports of corrupted signatures when installing Pharo/Squeak.
Particularly interesting were... * "Starting in macOS 10.9, the code signing tool records nested code." * "Store ...shell... script files and other non-Mach-O executables in your app's Contents/Resources directory. While it's possible to sign such executables and store them in Contents/MacOS, this is not recommended. This is because code signing uses extended attributes to store signatures in non-Mach-O executables such as script files. If the extended attributes are lost, the program's signature will be broken. Many file transfer techniques do not preserve extended attributes, nor are they preserved when uploading to the Mac App Store."
I'm not familiar with the bundle arrangement and don't have a Mac running to check this, so pinging those more intimate with the MacOS bundle to advise whether the article may impacts us.
cheers -ben
I don't think we have any scripts for the macOS VMs. Squeak All-in-ones for example come with a launcher script for Windows and Linux. So I'm not too concerned about our macOS code signatures. I'm more concerned about the notarization process [1] which I believe will be mandatory at some point.
Cheers, Fabio
[1] https://developer.apple.com/documentation/security/notarizing_your_app_befor...
On Fri, Apr 19, 2019 at 3:07 AM Ben Coman btc@openinworld.com wrote:
I just bumped into the following article...
https://developer.apple.com/library/archive/documentation/Security/Conceptua...
and the section "Ensuring Proper Code Signatures for Nested Code" made me remember some reports of corrupted signatures when installing Pharo/Squeak.
Particularly interesting were...
- "Starting in macOS 10.9, the code signing tool records nested code."
- "Store ...shell... script files and other non-Mach-O executables in
your app's Contents/Resources directory. While it's possible to sign such executables and store them in Contents/MacOS, this is not recommended. This is because code signing uses extended attributes to store signatures in non-Mach-O executables such as script files. If the extended attributes are lost, the program's signature will be broken. Many file transfer techniques do not preserve extended attributes, nor are they preserved when uploading to the Mac App Store."
I'm not familiar with the bundle arrangement and don't have a Mac running to check this, so pinging those more intimate with the MacOS bundle to advise whether the article may impacts us.
cheers -ben
vm-dev@lists.squeakfoundation.org