“codesign”

[quote='829245022, chipcastle, /thread/774923?answerId=829245022#829245022, /profile/chipcastle'] ran my codesigning script which signs in the following order [/quote] Step 2 is unnecessary here. Using the terms from Creating distribution-signed code for macOS, your app is bundled code. That means you only need to sign the bundle. If you sign the PATHmanager executable separately, that signature is just overwritten when you sign the PATHmanager.app. [quote='829245022, chipcastle, /thread/774923?answerId=829245022#829245022, /profile/chipcastle'] so I continue to be puzzled [/quote] That error is misleading, in that there are two potential causes: The executable is missing this entitlement. The executable’s code signature is broken, which means that App Store Connect is unable to check that the entitlement is present. I suspect you’re hitting the second case. If you unpack the installer [1] and check the app’s code signature like so: % codesign --verify -vvv PATHmanager.app what does it repor

Thanks for the suggestion. I was able to extract libui.dylib by running bundle install with the following configuration: cat ~/code/ruby/pathos_macos/.bundle/config --- BUNDLE_PATH: vendor/ BUNDLE_WITHOUT: development:test This created vendor/ruby/3.3.0/gems/libui-0.1.2-arm64-darwin/vendor/libui.dylib, which I ditto'd over to ~/Desktop/distribution/PATHmanager.app/Contents/Frameworks/libui.dylib I bumped version (as described previously) and ran my codesigning script which signs in the following order (under /Users/chip/Desktop/distribution/PATHmanager.app/): Contents/Frameworks/libui.dylib Contents/MacOS/PATHmanager PATHmanager.app directory After uploading the .pkg file using Transporter, I get this old error: Validation failed (409) App sandbox not enabled. The following executables must include the com.apple.security.app-sandbox entitlement with a Boolean value of true in the entitlements property list: [( com.chipcastle.pathmanager.pkg/Payload/PATHmanager.app/Contents/MacOS/PATHmanager )] Refer

I think I'm closing in on a solution. Here's what I did to get here: 1. Removed all development gems from Gemfile & bundled bundle install --without development test This removed the date gem, which was the original complaint by macOS, along with other gems (i.e., psych, rdoc, debug). 2. Created executable tebako clean && tebako press --root=/Users/chip/code/ruby/pathos_macos --entry-point=/Users/chip/code/ruby/pathos_macos/bin/pathos_macos -o ~/Desktop/pathos 3. Copied over executable to .app folder cp ~/Desktop/pathos ~/Desktop/distribution/PATHmanager.app/Contents/MacOS/PATHmanager 4. Fixed ownerships (needs further investigation) chown -R chip:staff ~/Desktop/distribution 5. Bumped version number manual file edit in Info.plist & appstore.rb (codesigning script) 6. Ran codesigning script ~/code/ruby/pathos_macos/assets/appstore.rb 7. Uploaded package via Transporter Located at (~/Desktop/PATHmanager.pkg) 8. Test with TestFlight I had to remove myself from QA/Testers on App

[quote='828419022, chipcastle, /thread/774923?answerId=828419022#828419022, /profile/chipcastle'] PATHmanager.app: invalid Info.plist (plist or signature have been modified) [/quote] Well, that’s not good. The most obvious cause of this problem is that your Info.plist has changed after the code was signed, which breaks the seal on the code signature. For example: % codesign -v --deep --strict QProcessDock.app % plutil -insert Greeting -string 'Hello Cruel World!' QProcessDock.app/Contents/Info.plist % codesign -v --deep --strict QProcessDock.app QProcessDock.app: invalid Info.plist (plist or signature have been modified) In architecture: arm64 It’s possible that you might see this for other reasons — like codesign being confused by whether the item you’re signing is a bundle or not — but that seems unlikely given that your bundle structure seems reasonable based on the info you’ve posted upthread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmai

Hi Kevin We tried creating a notarized build after this fix. However, we are facing a prompt on macOS while opening our Application. Attaching screenshot. To debug this, we reverted our code to a release which was not giving us this prompt(removed the fix as well for now). We then created a notarized dmg again. With this, the prompt started showing up here as well. When we directly run the dmg in the dev machine, it does not give us the prompt. But if we download it from somewhere and run, the prompt comes up even in dev machine. We executed some commands to verify the notarization: spctl --assess -vv /Applications/Refresh Pro.app On the dev machine, the output was accepted but on other machine, it was rejected. Output as follows: /Applications/Refresh Pro.app: rejected source=Notarized Developer ID origin=Developer ID Application: Prograde Digital Incorporated (*******) xcrun stapler validate /Applications/Refresh Pro.app On dev machine, we executed this command and the output is as follows. Processing: /App

Thank you for the update. Here's the output: λ codesign -v --deep --strict PATHmanager.app PATHmanager.app: invalid Info.plist (plist or signature have been modified) In architecture: arm64 /tmp λ codesign -d --entitlements - PATHmanager.app Executable=/private/tmp/PATHmanager.app/Contents/MacOS/PATHmanager [Dict] [Key] com.apple.application-identifier [Value] [String] BXN9N7MNU3.com.chipcastle.pathmanager [Key] com.apple.developer.team-identifier [Value] [String] BXN9N7MNU3 [Key] com.apple.security.app-sandbox [Value] [Bool] true It looks like the entitlement is ok. I'm still wrestling with what is specifically making Info.plist invalid, though.

[quote='828135022, chipcastle, /thread/774923?answerId=828135022#828135022, /profile/chipcastle'] Transporter reports sandbox error [/quote] Probably like this are usually caused by one of two things: The program is not actually sandboxed. It has a broken code signature that prevents App Store Connect from checking its entitlements. You posted the .entitlements file but that’s not what matters here. It’s source code, and App Store Connection is checking your binary. You need to verify that, after installation, the program’s code signature is valid and that it includes the App Sandbox entitlement. So, something like: % codesign -v --deep --strict PATHmanager.app % codesign -d --entitlements - PATHmanager.app Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

By default, macOS is set up so that processes running platform binaries [1] have library validation enabled by default. However, in some cases that’s not appropriate. In this example, an authorisation plug-in host needs to be able to load authorisation plug-ins. We get around this by signing the host with an entitlement that explicitly opts out of this implicit library validation: % codesign -d --entitlements - /System/Library/Frameworks/Security.framework/Versions/A/MachServices/SecurityAgent.bundle/Contents/XPCServices/SecurityAgentHelper-arm64.xpc … [Dict] … [Key] com.apple.private.security.clear-library-validation [Value] [Bool] true … % codesign -d --entitlements - /System/Library/Frameworks/Security.framework/Versions/A/MachServices/authorizationhost.bundle/Contents/XPCServices/authorizationhosthelper.arm64.xpc … [Dict] [Key] com.apple.private.security.clear-library-validation [Value] [Bool] true … I’ve never seen this fail; my authorisation plug-ins always load just fine on stock syst