codesign

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

1. Unpack profile: security cms -D -i distribution/PATHmanager.app/Contents/embedded.provisionprofile -o profile.plist (attached profile.plist) profile.plist 2. Extract the cert chain: codesign --display --extract-certificates distribution/PATHmanager.app openssl x509 -in codesign0 -inform der -text > leaf (attached leaf) leaf 3. Serial number for leaf: λ head leaf Certificate: Data: Version: 3 (0x2) Serial Number: 4a:9a:24:59:ac:96:e8:e8:45:f6:71:ab:59:b8:69:32 Signature Algorithm: sha256WithRSAEncryption Issuer: CN=Apple Worldwide Developer Relations Certification Authority, OU=G3, O=Apple Inc., C=US Validity Not Before: Mar 1 00:37:19 2025 GMT Not After : Mar 1 00:37:18 2026 GMT 4. What part of the profile should I compare to the leaf serial number? λ shasum leaf ce0e2fc70a9bde62745332b843ef650a918a39dc leaf

Do you have a .entitlements file that includes com.apple.developer.in-app-purchase? If so, I recommend that you remove that. In-app purchase isn’t gated by an entitlement. If you search our docs for com.apple.developer.in-app-purchase, you’ll find no references to such an entitlement. Rather, in-app purchase is available to any app that uses an explicit App ID (as opposed to a wildcard App ID). Consider this: Create a new project from Xcode’s iOS > App template. In Signing & Capabilities, add the In-App Purchase capability. Select your device as a run destination. Choose Product > Build. Now dump the entitlements of the build app: % codesign -d --entitlements - Test775663.app … [Dict] [Key] application-identifier [Value] [String] SKMME9E2Y8.com.example.apple-samplecode.Test775663 [Key] com.apple.developer.team-identifier [Value] [String] SKMME9E2Y8 [Key] get-task-allow [Value] [Bool] true As you can see, there’s no com.apple.developer.in-app-purchase entitlement in play. Share and Enjoy — Q

Making progress here: Upgraded to Sequoia 15.3.1, Xcode 16.2 Codesigning executable returns 'satisfies its Designated Requirement' using: codesign --force --verify --verbose=4 --options runtime --timestamp --entitlements '/Users/chip/Desktop/PATHmanager.entitlements' --sign 'Apple Distribution: Chip Castle Dot Com, Inc. (BXN9N7MNU3)' '/Users/chip/Desktop/distribution/PATHmanager.app/Contents/MacOS/PATHmanager' Productbuild .pkg file returns successfully using: productbuild --sign '3rd Party Mac Developer Installer: Chip Castle Dot Com, Inc. (BXN9N7MNU3)' --identifier 'com.chipcastle.pathmanager' --version '1.15' --component '/Users/chip/Desktop/distribution/PATHmanager.app' /Applications '/Users/chip/Desktop/PATHmanager.pkg' Verifying signature returns 'satisfies its Designated Requirement' using: codesign --verify --verbose=4 '/Users/chip/Desktop/distribution/PATHmanager.app/Contents/MacOS/PATHmanager' Transporter uploads successfully. Running Verify via Transporter returns error: