Search results for

codesign

3,113 results found

Post

Replies

Boosts

Views

Activity

Reply to codesign error - No such file or directory
Thanks for that. I downloaded your app and was able to sign it just fine: % sw_vers ProductName: macOS ProductVersion: 15.2 BuildVersion: 24C101 % % codesign -s - -f ALP_Document_Factory_II .app ALP_Document_Factory_II .app: replacing existing signature The one thing I noticed is that your app name contains weird characters. Note the ‘gaps’ in the shell completed name above. Now consider this: % ls | xxd 00000000: 414c 505f 446f 6375 6d65 6e74 5f46 6163 ALP_Document_Fac 00000010: 746f 7279 5f49 49c2 a0c2 a02e 6170 700a tory_II.....app. 00000020: 414c 505f 446f 6375 6d65 6e74 5f46 6163 ALP_Document_Fac 00000030: 746f 7279 5f49 49c2 a0c2 a02e 7a69 700a tory_II.....zip. Each c2 a0 sequence is a U+00A0 NO-BREAK SPACE. Did you add those deliberately? If not, I recommend that you remove them. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Topic: Code Signing SubTopic: General Tags:
Jan ’25
Reply to dlopen on development iPhone codesign issue
One curious thing I am seeing is that: codesign -vv -d --verbose testlibrary-ios.dylib outputs: Executable=/Users/joe/sources/Curiosity/hotreload/cmake-build-debug/testlibrary-ios.dylib Identifier=testlibrary-ios Format=Mach-O thin (arm64) ... It surprised me that my dylib has an Executable= with the path to the dylib. Is this expected and could it be related to my problem?
Topic: Code Signing SubTopic: General Tags:
Jan ’25
Reply to codesign entitlements syntax error
I know this is a very old post but I just ran into the same problem (for an iOS app) and I think I figured it out. This is not an invalid XML so the error is misleading, and that's why plutil has no trouble with it. The problem is datetime format: 2038-01-31T11:46:58Z This is a fully-qualified ISO date but it looks like the codesign tool chokes on it. I was able to work around this by truncating the time part and keeping just the date: 2038-01-31 With this change, I was able to sign and deploy my app to my physical device.
Jan ’25
codesign entitlements syntax error
Hey, I'm trying to code sign my Mac OS X app. I generate entitlements file, but during execution of the command: codesign -f -s DeveloperName -o runtime --timestamp ./App.app --entitlements app.entitlements it gives me the next error: Failed to parse entitlements: AMFIUnserializeXML: syntax error near line 12 In the file I have a date value field on the line 12: ExpirationDate 2038-01-31T11:46:58Z If I move the date on the other line, codesign shows the error line number according to the new line number. If I removed I used plutil commands from the Apple article - https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution/resolving_common_notarization_issues?language=objc, and the utility show that everything is ok, but it make no sense for codesign. Mac OS X version: 10.15.7 How can fix it and sign the app with entitlements file?
2
0
3.9k
Dec ’20
Reply to codesign error - No such file or directory
[quote='773118021, dickL45, /thread/773118, /profile/dickL45'] Yours baffled [/quote] This is a weird error. I’ve seen in before [1] but I’ve not yet worked out exactly how to trigger it. Problems like this are almost always the result of folks not following the rules described in Placing Content in a Bundle. However, it’s hard to debug this with just the error message you’re getting from codesign. Two things: If you add more -v flags to codesign, does the verbose logging reveal anything? If not, are you willing to share a copy of the ALP_Document_Factory_II.app? If so, zip it up and reply here with the URL. ps I recommend you have a read of Quinn’s Top Ten DevForums Tips. Specifically tip 5’s info about preformatted text and tip 14 about posting URLs. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] For example, here.
Topic: Code Signing SubTopic: General Tags:
Jan ’25
Reply to Auditing code signatures
So I also asked about this internally and have something I’d like you to try. If you dump a code signature with enough -v options, you eventually get to the CMSDigest field. Does that line up with your signing operations? % codesign -d --arch arm64 -vvvvv /Applications/Pages.app … CMSDigest=4380386763a016bee5fbfbf362f7c9c05bb1a5ea2d5ed9535b371fb36223e3e6 … % codesign -d --arch x86_64 -vvvvv /Applications/Pages.app … CMSDigest=d4d89d97cc94daa5437f14f02490a4a9efd9eece7ca22150d807df344c36d3c9 … Note that it’s different for each architecture. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Topic: Code Signing SubTopic: General Tags:
Jan ’25
Unable to use XCode Auto-sign for a project with network + system extension
Hi, We are developing software that configures a network extension via a system extension on MacOS. The host application (run as service) enables network extension and system extension capabilities. It registers the network extension. The network extension has network extension capabilities and configures an app-group to be bundled into the service. What we have built is already working, i.e. we build, sign, notarize and ship the code (it's already running on hundreds of SIP enabled customer devices in production). But, we are currently falling back to manual profile management (i.e. download and import the profile) so that Xcode accepts the entitlements suffixed with -systemextention. Recently we are testing deployment on iOS devices. For iOS profiles we cannot overcome the issues with setting the profile manually, XCode complains about mismatching networkextension entitlements even when manually importing the profile. So I thought I get to the bottom of why automated signing is not working and hopefully ove
1
0
504
Jan ’25
Disappearing External link account entitlement
I've got a Flutter app that is a “reader” app. The External Link Account Entitlement has already been requested and granted. It is already added as an Additional Capability to the App ID. The com.apple.developer.storekit.external-link.account entitlement is already present in the .entitlements file. Also SKExternalLinkAccount key is added to the Info.plist file with the correct URL. ExternalLinkAccount.open() is invoked via a MethodChannel call handler and things work perfectly in debug mode. The modal appears as expected and opens the link in the external browser. Xcode archive is also sucessful and the entitlement seems to be in place when inspecting the app with: codesign -d --entitlements :- ./path/to/app But when trying to distribute the app via Xcode the entitlement disappears. Other entitlements are not affected by this issue, eg.: com.apple.developer.associated-domains for universal links. This happens with automatically managed singing and a manually selected provisioning profile as well. Wh
3
0
770
Jan ’25
Reply to The staple and validate action failed! Error 65.
Error 65 means that there is no ticket for the thing you’re trying to staple. The usually means that your notarisation failed but, as you’ve shown here, the notarisation actually succeeded. So either you’re stapling something that you didn’t notarise or the notary service didn’t recognise all of your code, and thus failed to include the relevant value in your ticket. Before you start debugging this specific problems, there are two parts to your process that you need to fix. The first is this: [quote='772807021, PeteMinus, /thread/772807, /profile/PeteMinus'] codesign --deep --force --options runtime … [/quote] Don’t sign code with --deep. See --deep Considered Harmful for an explanation as to why that’s bad. For advice on how to sign and package your code, see: Creating distribution-signed code for macOS Packaging Mac software for distribution The second fix relates to this: [quote='772807021, PeteMinus, /thread/772807, /profile/PeteMinus'] ditto -c -k --sequesterRsrc --keepParent dist/mac-arm64/Mode
Jan ’25
Reply to ICDeviceBrowser, PTP tethering, not working in macOS 14.2?
Hello, have you solved this issue? I also use ImageCaptureCore to develop digital cameras tether software. During the development process, I found that the software uses temporary signatures and ICDeviceBrowser can search for devices, but after using formal signatures, it cannot search for any devices. Use the following two commands to temporarily sign: codesign --remove-signature codesign --sign - hope to get your reply! BR,
Topic: App & System Services SubTopic: Core OS Tags:
Jan ’25
Reply to How to count the number of signed files
[quote='821436022, mariocst, /thread/772549?answerId=821436022#821436022, /profile/mariocst'] We execute the codesign inside a CI pipeline. [/quote] So you want to generate this report at build time on a machine you control? If so, you could do this by parsing the CodeResources file within the signed bundle. See TN3126 Inside Code Signing: Hashes. WARNING Don’t do this on the user’s device. Quoting TN3126 “The structure of a code signature has changed numerous times in the past and may well change again in the future.” However, doing this on your CI machine should be fine because, if it breaks, only you are affected. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Topic: Code Signing SubTopic: General
Jan ’25
自签名证书到期对SDK的影响
我们开发了一款SDK,并用自签名证书对SDK进行了签名,我们的证书会在2025年1月30日到期,到期后对已发布至appstore的app会有影响吗? 用户在2025年1月31日打开app时,会因为自签名证书到期而闪退吗?有不少app集成了我们的SDK,这个问题对我们来说非常紧急和重要,麻烦尽快回复,谢谢! 以下是我们的签名步骤: 自签名步骤:self-signed certificate xcframework 1、钥匙串创建:证书助理-创建证书-自签名根证书+代码签名 2、自行签名根证书修改信任设置 3、对已经打包好的xcframework进行签名 (官方命令示例)codesign --timestamp -v --sign 证书名字 ~/Desktop/MySDK.xcframework
2
0
370
Jan ’25
Reply to 自签名证书到期对SDK的影响
The impact of self-signed certificate expiration on the SDK. We have developed an SDK and signed it with a self-signed certificate. Our certificate will expire on January 30, 2025. After it expires, will there be any impact on apps that are already published on the App Store? If a user opens the app on January 31, 2025, will the app crash due to the expired self-signed certificate? Many apps have integrated our SDK, and this issue is very urgent and important for us. We kindly ask for your prompt reply. Thank you! Here are the steps we followed for signing: Self-signing steps: self-signed certificate xcframework Keychain creation: Certificate Assistant - Create Certificate - Self-signed Root Certificate + Code Signing Modify trust settings for the self-signed root certificate Sign the already packaged xcframework (Official command example) codesign --timestamp -v --sign Certificate Name ~/Desktop/MySDK.xcframework
Jan ’25