DSI Studio Mac App Issues

[uurazzle]

Hi:

Thanks for contributing and making DSI Studio available to the community.

There are some issues with the DSI Studio Mac application.

First, the application releases are signed or notarized.

All apps from the App Store are signed by Apple. This signing is designed to ensure that they haven’t been tampered with or altered. Apple signs any apps provided with Apple devices.

In macOS 10.15, all apps distributed outside the App Store must be signed by the developer using an Apple-issued Developer ID certificate (combined with a private key) and notarized by Apple to run under the default Gatekeeper settings. Apps developed in-house should also be signed with an Apple-issued Developer ID so that users can validate their integrity.

Notarize your macOS software to give users more confidence that the Developer ID-signed software you distribute has been checked by Apple for malicious components. Notarization of macOS software is not App Review. The Apple notary service is an automated system that scans your software for malicious content, checks for code-signing issues, and returns the results to you quickly. If there are no issues, the notary service generates a ticket for you to staple to your software; the notary service also publishes that ticket online where Gatekeeper can find it.

https://support.apple.com/guide/security/app-code-signing-process-sec3ad8e6e53/web
https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution

Second, there isn't a CFBundleIdentifier it's empty...

<key>CFBundleIdentifier</key>
<string></string>

https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleidentifier

Third, there isn't a CFBundleVersion or CFBundleShortVersionString to identify the version or release.

<key>CFBundleVersion</key>
<string></string>

<key>CFBundleShortVersionString</key>
<string></string>

https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleversion

https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleshortversionstring

Also, I thought this post from Quinn “The Eskimo!” @ Developer Technical Support @ Apple would be good to share with you and others contributing to the Mac development:

Resolving Gatekeeper Problems | Apple Developer Forums:

The post titled "Resolving Gatekeeper Problems" on the Apple Developer Forums, written by Quinn "The Eskimo!" from Developer Technical Support at Apple is a comprehensive guide addressing common issues related to Gatekeeper on macOS. Gatekeeper is a security feature designed to ensure that only trusted software runs on a user's Mac, and the post focuses on helping developers troubleshoot and resolve issues that may arise in this context.
The post identifies four common Gatekeeper problems that developers may encounter:

1. App blocked by a dangling load command path.
2. Broken code signature.
3. Lack of notarization.
4. Command-line tool blocked by Gatekeeper.

For each of these issues, the post provides detailed steps and guidance on how developers can resolve them. The emphasis is on the importance of passing Gatekeeper checks to maintain customer trust and avoid potential loss of customers.

Key points covered in the post include:

• Verification of Code Signature: Developers are advised to use the codesign tool to verify that their code is signed correctly. The post provides examples of command-line usage to check for issues such as missing or invalid sealed resources.
• Notarization Issues: Gatekeeper requires that apps be notarized, and the post guides developers on how to identify and resolve notarization problems. It includes information on checking system logs for specific entries related to notarization issues.
• Hash Mismatch: In cases where there's a hash mismatch, the post provides guidance based on the file type (e.g., zip archive, signed disk image, installer package) and recommends specific actions to address the problem.
• Command-line Tool Blocking Bug: A known bug in macOS is acknowledged, where double-clicking a command-line tool in Finder may lead to it being blocked by Gatekeeper. Workarounds, such as embedding the tool in an application or using an installer package, are suggested.

Throughout the post, there are references to Apple's documentation and resources related to code signing and notarization, providing developers with additional information for a deeper understanding.

[frankyeh]

This is a known issue, and I did not approach it because there is too much work. In comparison, "enable run permission" is a quick workaround and won't take a minute.

…

On Fri, Mar 29, 2024 at 6:17 PM Richard Glaser ***@***.***> wrote: Hi: Thanks for contributing and making DSI Studio available to the community. There are some issues with the DSI Studio Mac application. First, the application releases are signed. All apps from the App Store are signed by Apple. This signing is designed to ensure that they haven’t been tampered with or altered. Apple signs any apps provided with Apple devices. In macOS 10.15, all apps distributed outside the App Store must be signed by the developer using an Apple-issued Developer ID certificate (combined with a private key) and notarized by Apple to run under the default Gatekeeper settings. Apps developed in-house should also be signed with an Apple-issued Developer ID so that users can validate their integrity. Second, there isn't a CFBundleIdentifier it's empty... <key>CFBundleIdentifier</key> <string></string> https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleidentifier Third, there isn't a CFBundleVersion or CFBundleShortVersionString to identify the version or release. <key>CFBundleVersion</key> <string></string> <key>CFBundleShortVersionString</key> <string></string> https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleversion https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleshortversionstring Also, I thought this post from Quinn “The Eskimo!” @ Developer Technical Support @ Apple would be good to share with you and others contributing to the Mac development: Resolving Gatekeeper Problems | Apple Developer Forums: The post titled "Resolving Gatekeeper Problems" on the Apple Developer Forums, written by Quinn "The Eskimo!" from Developer Technical Support at Apple is a comprehensive guide addressing common issues related to Gatekeeper on macOS. Gatekeeper is a security feature designed to ensure that only trusted software runs on a user's Mac, and the post focuses on helping developers troubleshoot and resolve issues that may arise in this context. The post identifies four common Gatekeeper problems that developers may encounter: 1. App blocked by a dangling load command path. 2. Broken code signature. 3. Lack of notarization. 4. Command-line tool blocked by Gatekeeper. For each of these issues, the post provides detailed steps and guidance on how developers can resolve them. The emphasis is on the importance of passing Gatekeeper checks to maintain customer trust and avoid potential loss of customers. Key points covered in the post include: • Verification of Code Signature: Developers are advised to use the codesign tool to verify that their code is signed correctly. The post provides examples of command-line usage to check for issues such as missing or invalid sealed resources. • Notarization Issues: Gatekeeper requires that apps be notarized, and the post guides developers on how to identify and resolve notarization problems. It includes information on checking system logs for specific entries related to notarization issues. • Hash Mismatch: In cases where there's a hash mismatch, the post provides guidance based on the file type (e.g., zip archive, signed disk image, installer package) and recommends specific actions to address the problem. • Command-line Tool Blocking Bug: A known bug in macOS is acknowledged, where double-clicking a command-line tool in Finder may lead to it being blocked by Gatekeeper. Workarounds, such as embedding the tool in an application or using an installer package, are suggested. Throughout the post, there are references to Apple's documentation and resources related to code signing and notarization, providing developers with additional information for a deeper understanding. — Reply to this email directly, view it on GitHub <#85>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACDI4KYCY5WFTH67U6XLZDY2XSBHAVCNFSM6AAAAABFO7PPGSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGIYTMMBUHA3DMMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[uurazzle]

Sure, understand and the software is open source.

But, keep in mind that in some environments this is one of many software programs that add additional burden to manage and distribute doesn't follow Apple developer best practices, and requires additional steps to manage and distribute.

Please consider it in the future when you do have bandwidth or when you can follow Apple developer best practices for building applications.

[frankyeh]

Thanks for the suggestion. I will keep this issue open until I fix it.
Frank

[uurazzle]

Hi:

Sorry, I also noticed you are using release versions like "Chen" vs using version numbers like 0.0.1 (MAJOR.MINOR.PATCH) which would make it much easier to monitor versions of your software installed or across a fleet of the system and in turn automate updates with tools like open source AutoPKG https://github.com/autopkg/autopkg or Installomator https://github.com/Installomator/Installomator or commercial solutions like Jamf Pro patch management, etc.

The "Semantic Versioning" website introduces rules for assigning version numbers: increment the MAJOR version for incompatible API changes, the MINOR version for backward compatible functionality additions, and the PATCH version for backward compatible bug fixes.

https://semver.org