Search results for

“codesign”

3,223 results found

Post

Replies

Boosts

Views

Activity

Are these the .entitlements file or the output from codesign? They look like the former (because they’re missing a bunch of keys that I’d normally expect to see in the output from codesign), which is not good because you really need to check the entitlements of the built binary. Take another look at Debugging Entitlement Issues. It’d also be helpful if you answered the other questions from my previous post.Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

App & System Services Networking

Aug ’16

Reply to My Swift macOS App does not run from Xcode

I think that I solved it. The following article proved helpful: https://developer.apple.com/library/archive/technotes/tn2250/_index.html#//apple_ref/doc/uid/DTS40009933-CH1-TNTAG19 My problem was in chapter: How do I resolve the CodeSign error: CSSMERR_TP_NOT_TRUSTED? After downloading and installing the necessary Apple Certificates my App worked. I got the above mentioned error message when running: codesign -v Without debugger my app works, in Xcode I still get a secinit error that I still need to solve. But at least my apps can work now.

Developer Tools & Services Xcode

Nov ’21

Reply to Extensions not opening if they are signed using the command line tools

Hi there, Thanks for your quick reply! Unfortunately the file I provided to you was incorrect (we were testing some things with the signature before and left it in the script by accident). I have updated the file in the repository with the correct command (its essentially the same command as in the export_without_extension_signing.sh file) I’m not sure what codesign does in that case, but it’s unlikely to be good. With this codesign would not have run at all and therefore not sign anything. The problem mentioned in the original post still occurs even when the signing commands are all executed correctly.

Code Signing General

Oct ’22

kext for x86_64 + arm64e change into only x86_64 after codesign.

I have a kext in app, and I can run it well on Xcode, but I cannot successfully run kextload command after archive. According to the error message, I then use lipo -archs to check kext archs, I found some strange things. Checkout the result of app in Xcode product directory: The result of app in Archive directory: Is there a way to resolve this issue? Where might the mistake be? Or Can I just copy app and code sign, notarize the app, then provide it for others to use?

App & System Services Core OS Extensions macOS

598

Aug ’24

Reply to Command CodeSign failed with a nonzero exit code

Same here,in my caseios/Debug-iphonesimulator/Runner.app: resource fork, Finder information, or similar detritus not allowed Command CodeSign failed with a nonzero exit code

Code Signing Certificates, Identifiers & Profiles

Apr ’20

electron mac app crash on the testFlight [Namespace CODESIGNING, Code 2]

crash log ------------------------------------- Translated Report (Full Report Below) ------------------------------------- Process: OneKey [20876] Path: /Applications/OneKey.app/Contents/MacOS/OneKey Identifier: so.onekey.wallet Version: 3.16.2 (202211070943) App Item ID: 1609559473 Code Type: ARM-64 (Native) Parent Process: launchd [1] User ID: 501 Date/Time: 2022-11-07 17:32:42.4372 +0800 OS Version: macOS 12.5 (21G72) Report Version: 12 Anonymous UUID: Sleep/Wake UUID: 5E78A6FD-4E76-458B-B1F7-DC8CCC4497B6 Time Awake Since Boot: 80000 seconds Time Since Wake: 7078 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid)) Exception Codes: UNKNOWN_0x32 at 0x0000000148048a40 Exception Codes: 0x0000000000000032, 0x0000000148048a40 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: Namespace CODESIGNING, Code 2 VM Region Info: 0x148048a40 is in 0x148048000-0x14807c000; bytes after start: 2624

App & System Services Core OS macOS Code Signing

1.7k

Nov ’22

Reply to Manually lipoing and codesigning

But that gets back to my original question -- can I just grep the codesign commands from the build output, and do those again after the enfattening? Or do I need something different after that?

Developer Tools & Services Xcode

Jun ’22

Reply to My app is signed (verified with spctl and codesign) but it still "can’t be opened because it is from an unidentified developer."

I’m having this same problem! I don’t understand it – like you, the output from codesign and spctl both looks good and says it’s valid and accepted.Did you ever solve this?

Developer Tools & Services Developer Forums

Dec ’15

Reply to Developer ID signed app, system extension, mono with JIT

I don't think I'm code signing with --deep. My build process is to use xcode to build the system extension, letting xcode sign it, use visual studio to build the main C# app, copy the extension into the right place, and then let visual studio sign the main app. As far as I can tell that results in a set of commands that looks like: produced by xcode /usr/bin/codesign --force --sign --timestamp -o runtime --entitlements path/to/extension/entitlements --requirements path/to/systemextension produced by visual studio /usr/bin/codesign -v --force --timestamp --sign path/to/library1.dylib /usr/bin/codesign -v --force --timestamp --sign path/to/library2.dylib ... /usr/bin/codesign -v --force -o runtime --timestamp --sign --entitlements path/to/app/entitlements path/to/app I don't see a codesign invocation that uses --deep, outside of a verify produced automatically by visual studio: /usr/bin/codesign --verify -vvvv --deep path/to/app path/to/my.app: valid on

App & System Services Drivers

Sep ’20

Reply to You do not have permission to open the application “Eclipse”.

The speculation from @eskimo was very insightful, after installing several plugins code sign does indeed show many modified files (and the application refuses to start). In my case this was due to installing plugins from the eclipse marketplace. This does point the way towards an easier workaround: Verify seal is broken: codesign -v -vvv --deep /Applications/Eclipse.app /Applications/Eclipse.app: invalid Info.plist (plist or signature have been modified) In architecture: x86_64 Sign the modified Eclipse.app % sudo codesign --force --sign - /Applications/Eclipse.app /Applications/Eclipse.app: replacing existing signature Verify seal is restored: % codesign -v -vvv --deep /Applications/Eclipse.app/Eclipse.app /Applications/Eclipse.app/Eclipse.app: valid on disk /Applications/Eclipse.app/Eclipse.app: satisfies its Designated Requirement This is still a workaround, but beats reinstalling from scratch (and reinstalling eclipse plugins).

Code Signing General

Aug ’21

Reply to Allow DYLD Environment Variables Entitlement on OSX 10.13.6

I sure did misunderstand the Hardened Runtime. THANK you for your informative reply. I don't need this for an application of my own. I want all applications I am running through my bash shell to be able to see DYLD_* variables from the environment. (currently make gives me this problem). I believe make was installed by homebrew. And I guess other applications, like cmake may also behave similarly. But I guess it is too much of a hassle for me to codesign each and every executable that may need to read DYLD_* variables. The hassle being that on each upgrade of make I need to do the codesigns again for each executable. Unless I do : find /usr/local/bin -type f -exec codesign -d -vvv --entitlements - {} ; which is like the nuclear option really. I guess I need to disable globally this Hardened Runtime by disabling SIP (which I have refrained from doing over the last 7 years). Any other options? (Do I need to make a new post?) THANK YOU

Code Signing Entitlements

Sep ’22

Reply to Restrict XPC calls to a launch daemon

I put a bunch of info, and links to other documents, in TN3127 Inside Code Signing: Requirements. I suggest you start there. You can test test requirements using codesign. For example: % codesign -v -v -R =anchor apple /System/Applications/TextEdit.app …/TextEdit.app: valid on disk …/TextEdit.app: satisfies its Designated Requirement …/TextEdit.app: explicit requirement satisfied % codesign -v -v -R =anchor apple /Applications/Pacifist.app …/Pacifist.app: valid on disk …/Pacifist.app: satisfies its Designated Requirement test-requirement: code failed to satisfy specified code requirement(s) You can also compile them using csreq, which is a great way check just the syntax. Hopefully the above will speed up your efforts to craft the correct requirement. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

App & System Services Core OS

Dec ’23

Reply to codesign results in errSecInternalComponent

Thanks for the tips @eskimo I confirmed that copying the code with rsync bypassed the Gatekeeper and allowed the it to run. Since I do eventually want to have it downloadable by others, I followed your link and updated the Apple Worldwide Developer Relations Intermediate Certificate and reset the trust settings which I had been playing with. That has enabled me to codesign the application without any errors, so definitely a step forward - thanks. However after downloading the app with browser from a web site, the app still cannot run on another machine. Interestingly, using curl to download the same app from the same web site results in an app that runs normally. Checking both downloads with ls -l@ shows com.apple.macl -1 com.apple.metadata:kMDItemWhereFroms -1 com.apple.quarantine -1 for the version downloaded with a browser, so looks like there's more to do than just codesigning the app. I'll look into that some more. Since my question was about codesigning, I'll mark this as solv

Code Signing General

Apr ’22

Reply to AppStore submission for Ruby/Glimmer app on MacOS without Xcode

[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

Code Signing General

Mar ’25

Reply to PKG Generate

Hi, I still have the same error. Here is my procedure in detail Script editor: main.scpt save as application. I sign my code: codesign -s Developer ID Application -f --timestamp -o runtime /contents/Resources/Scripts/Main.scpt Error: Main.scpt: resource fork, Finder information, or similar detritus not allowed -xattr -cr Main.scpt I resign my code: codesign -s Developer ID Application -f --timestamp -o runtime /contents/Resources/Scripts/Main.scpt=OK CodeSign Main.scpt -vvvvvv = Main.scpt: valid on disk, Main.scpt: satisfies its Designated Requirement. Then I create the package with the tool : the macOS installer builder: https://medium.com/swlh/the-easiest-way-to-build-macos-installer-for-your-application-34a11dd08744 When the package is built, to execute it, I have to right click on it and open. The error message is displayed but I can execute package. I'd like no to display the error message :)

Code Signing Certificates, Identifiers & Profiles

May ’23

Reply to network extension did not call

App & System Services Networking

Replies
Boosts
Views
Activity: Aug ’16

Reply to My Swift macOS App does not run from Xcode

Developer Tools & Services Xcode

Replies
Boosts
Views
Activity: Nov ’21

Reply to Extensions not opening if they are signed using the command line tools

Code Signing General

Replies
Boosts
Views
Activity: Oct ’22

kext for x86_64 + arm64e change into only x86_64 after codesign.

App & System Services Core OS Extensions macOS

Replies: 1
Boosts: 0
Views: 598
Activity: Aug ’24

Reply to Command CodeSign failed with a nonzero exit code

Same here,in my caseios/Debug-iphonesimulator/Runner.app: resource fork, Finder information, or similar detritus not allowed Command CodeSign failed with a nonzero exit code

Code Signing Certificates, Identifiers & Profiles

Replies
Boosts
Views
Activity: Apr ’20

electron mac app crash on the testFlight [Namespace CODESIGNING, Code 2]

App & System Services Core OS macOS Code Signing

Replies: 5
Boosts: 0
Views: 1.7k
Activity: Nov ’22

Reply to Manually lipoing and codesigning

But that gets back to my original question -- can I just grep the codesign commands from the build output, and do those again after the enfattening? Or do I need something different after that?

Developer Tools & Services Xcode

Replies
Boosts
Views
Activity: Jun ’22

Reply to My app is signed (verified with spctl and codesign) but it still "can’t be opened because it is from an unidentified developer."

I’m having this same problem! I don’t understand it – like you, the output from codesign and spctl both looks good and says it’s valid and accepted.Did you ever solve this?