codesign

Sorry to hijack, but that didn't work for me. I'm trying a command-line utility, doing: static size_t get_thread_count(pid_t pid) { mach_port_t me = mach_task_self(); mach_port_t task; kern_return_t res; thread_array_t threads; mach_msg_type_number_t n_threads; res = task_for_pid(me, pid, &task); if (res != KERN_SUCCESS) { fprintf(stderr, Unable to get task for pid %d: %dn, pid, res); return 0; } res = task_threads(task, &threads, &n_threads); if (res != KERN_SUCCESS) { fprintf(stderr, Could not get threads: %dn, res); return 0; } res = vm_deallocate(me, (vm_address_t)threads, n_threads * sizeof(*threads)); // Ignore error return n_threads; }``` and using an entitlements plist of and using codesign --sign - --entitlements ./ent.plist --deep ./t3 --force to get it in there, but it fails with error 5. (Even when run as root. 😄) This could be how I'm codesigning it, of course; I was just doing a simple CLI tool test first.

That failed in the automatic process, though - it kept bringing in the old dext bundle ID, and it was only AFTER involving the Team Agent and registering a new dext bundle ID that I got the correct results So, the issue here is that automatic works by having Xcode modify the portal, so if you're account type can't modify the portal configuration, Xcode can't fix it. You can fix this in two ways: You can have the Team Agent log in to Xcode and configure the project, which will then cause Xcode to modify the portal. You can modify the portal configuration yourself so that it's configuration matches what it should. This is ultimately a business decision, but my personal experience has been that out development flow works MUCH better with admin accounts. With a large company (which obviously has concerns about legitimate app distribution), my own inclination would be to have two different accounts- a development account where all developers could be admins but which never actually shipped software and a company a

Hi Kevin, First, thank you for your patience on all of this. It turns out you can't do that from an Admin role. I kept looking at the output of the security command and seeing the older bundle ID showing up for com.apple.developer.driverkit.userclient-access., which was not the updated bundle ID I was developing now. FYI, this is one of the pitfalls of manual codesigning, as automatic codesigning will not allow that. That's actually the biggest issue with manual codesigning- it allows you to force configuration that won't actually work, so unless you understand EXACTLY why automatic is failing, you can easily end up replacing an error at signing with a different error somewhere else. That's the issue, though. I don't know EXACTLY why automatic codesigning is failing - at least with manual code signing I can look at what settings I am using and try something else. If I just press automatic and it doesn't work (it hasn't yet), there does not seem to be anything further I can

You're right, I'm not using XCode for development. I know why this issue didn't occur, and I hope it can be helpful for those who come across this blog in the future. But now I have encountered another problem and need your help The following entitlement is not set in my entitlement. plist file: The reason for this issue is that when using @ electron/osx sign for signing, some parameters in the old option were invalid, resulting in the execution of the default entitlement. plist file in the node_module package. But now, I have encountered a new problem and I hope you can help me take a look: When I submitted a new binary file for review, I received a response saying that the software could not be opened, and other phenomena included: Before I signed the app, it could run normally, but after I signed it, I found that the app package could no longer run. I submitted the version to Apple Connect, but even after downloading it through TestFlight, I couldn't open it. Even if I turn off sandbox mode in the entities

[quote='768573021, fraapaul, /thread/768573, /profile/fraapaul'] Is it correct that codesign only uses certificates from the local Keychain … ? [/quote] Correct. If you use the Xcode organiser to export a Developer ID signed app [1], you can look at Packaging.log to see how this works. codesign is used to generate the data to be signed and then to apply the signature, but the actual signing is done using a web service. AFAIK all of this is considered an implementation detail and not documented for third-party use (other than via Xcode and xcodebuild, of course). Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] You have to remove your Developer ID signing identity from the keychain in order to get cloud signing. I have mine in a separate keychain — I talk about that more in The Care and Feeding of Developer ID — so I just removed that keychain from the search list in Keychain Access.

[quote='813976022, dongkeqiang, /thread/768361?answerId=813976022#813976022, /profile/dongkeqiang'] Amazing, it worked. [/quote] Yay! [quote='813976022, dongkeqiang, /thread/768361?answerId=813976022#813976022, /profile/dongkeqiang'] But now I have encountered another problem and need your help The following entitlement is not set in my entitlement. plist file: [/quote] My understanding is that you’re not using Xcode to sign and package your app. Given that, there’s a limit to how much I can help you with. Your third-party tooling is probably based on Apple’s low-level tools, xcodebuild (perhaps), Clang, codesign, and so on. Those tools don’t add entitlement claims spontaneously. They only do that if you instruct them to. So you have two choices: Seek help from the support channel for the tools you’re using. Or take ownership of the tool, and work through the steps that it takes to create your package to see where it’s adding these entitlement claims. If you get to a point where you see an Apple tool

Building a notarized Perl app on a Mac using the command line? You're kind of fighting the whole world at once there, eh? 😄 In addition to the hardened runtime, you'll need some entitlements to relax said hardened runtime. Put those in an XML file and use the --entitlements flag with codesign. Make sure to completely test your installation with all kinds of funky edge cases. In addition to all the up-front notarization checks, there are certain checks that happen only at runtime, or only at runtime when you try to trigger something like dynamic loading or JIT execution. That is the part that trips up most people in your situation who get that far. I don't know which entitlements Perl will require - most likely all of them.

Dear Engineer, Thanks for your information. Actually, We use Qt to develop an application on the macOS platform, and we are attempting to perform code signing and notarization to ensure our the application is trusted by Apple. However, there are a few things that seem weird regarding your statement: App bundles are read-only by design. Let me provide more details for your reference. Currently, when our application starts, it needs to create folder (e.g. Temp) in the root directory of the executable For example: Myapp.app/Contents/MacOS/Myapp ---> Myapp.app/Contents/MacOS/Temp The folder is designed for storing runtime logs or config files for our application. In the past, users may also modify the settings inside target folder if needed. However, the strange thing is that after the application is codesigned and notarized. When we double-click the application Myapp (a.k.a Myapp.app) in Finder, it could successfully launch and create the Temp folder inside the Myapp.app/Contents/MacOS folder. Howeve

I tried using a third-party app (Pacivist) to open the app in pkg, nd export the app locally，then followed your instructions to perform the following actions: 1、 Run codesign against the results app to confirm that its signature is valid: % codesign --verify -vvv /path/to/your.app The results obtained: PS:I noticed an error message IFlytek heard. app: a sealed resource is missing or invalid File missing:/Users/pploo2/Desktop/icon/1/iFlytek heard. app/Contents/Resources/tj_S1/_MACOSX/ node_modules I don't know if this is the key to the problem ITMS-90926. 2. Run codesign again to check that you have App Sandbox enabled: % codesign --display --entitlements - /path/to/your.app The results obtained: You can see that there is sandbox=true here Now back to the first step, I performed operations on the app before packaging it as pkg and found that there were no missing related issues