codesign

So, we actually need to stop right here: I'm using SMJobSubmit Stop using SMJobSubmit. That API was deprecated in 10.10 (seven years ago) and I believe we'd been recommending against it for several years. The modern replacement is SMAppService, introduced in macOS 13.0. Note that this is a modern replacement, in that it specifically supports privileged helper tools embedded inside app bundles. Keep in mind that doing this: The tool is embedded in the Contents/MacOS folder. ...is not safe with SMJobSubmit and never has been. SMJobSubmit is hard coding the executable path, which means the user renaming your app (or any other manipulation) will both break your job and create an opening which could allow an attacker to insert their executable in place of your job. If you need to support older systems, then the recommended approach would be to use SMJobBless as shown in EvenBetterAuthorization to install a privileged helper tool. The helper can then be used as the target for a launchd plist, which the privileged h

Hi, So, first off, there are actually three entitlements involved here that overlap each other to a significant extent: Increased Memory Limit -> com.apple.developer.kernel.increased-memory-limit entitlement. Increased Debugging Memory Limit -> com.apple.developer.kernel.increased-debugging-memory-limit Extended Virtual Addressing -> com.apple.developer.kernel.extended-virtual-addressing The first two (1 & 2) are fairly similar, with the difference being that, by design, the second (Debugging) variant will never be included in release builds. If you unintentionally used the second version, then that would immediately explain the failure you're seeing. In the interest of getting a response out I won't try to describe the difference between 1 & 3 beyond saying that the issues here are more complicated than get more memory. That leads to here: Used the same entitlement-enabled code and configuration for distribution. After installing the App Store version on the same device, we found the app now

Thank you for the suggestions, here are my results: Exporting In order to export my app archive through the organizer, I followed these steps: Xcode 16 -> Organizer -> Distribute App -> Custom -> Direct Distribution -> Export -> Automatically Manage Signing -> Export. Notarytool + Log After exporting, I followed Customizing the notarization workflow in order to run notarytool. You were right, the process was easier than I thought that it would be. After running notarytool, I was able to get the log file from the failed notarization by running xcrun notarytool log .... I have attached the log file below. Case Sensitive Volume I created a case sensitive volume using the disk utility app. After copying over and unpacking my app, I re-ran codesign --verify --strict --deep -vvv …, which produced different results than my original debugging session. The output was a lot shorter than my initial run (maybe from detecting the issue?). This seems to be the issue from the output: --prepared

It’s hard to answer this without a lot more details. In general, macOS and the notary service continue to tighten up their checking of code in order to close security holes. Some of those are big changes, when we tend to announce widely. I have a bunch of links to such things in Trusted Execution Resources and the other Resources posts that it links to. But some of them are relatively minor changes that don’t get widely advertised. And some changes are just implementation changes that happen to cause problems for code that’s not following the rules [1]. [quote='770552021, hamish258, /thread/770552, /profile/hamish258'] DMGs built, signed and notarised successfully are now failing codesign verification. [/quote] If you run syspolicy_check against such an app, what does it report? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Historically those rules were very poorly documented. That’s much better these days, but lots of code, a

[quote='817395022, wiedem, /thread/770409?answerId=817395022#817395022, /profile/wiedem'] I can understand if it's not actively supported, but I wouldn't call providing technical documentation 'active support'. [/quote] I think the current situation is instructive. Presumably you built your code signature parsing code back when the entitlements were stored as a property list. Doing that was unsupported. That code broke when we switched to ASN.1, and hence this thread. I’m trying to avoid repeating this cycle, where your code breaks again the next time we revise the code signature format. Remember, DTS’s goal is to help developers build products that work now and in the future. We don’t support things that run counter to that goal. [quote='817395022, wiedem, /thread/770409?answerId=817395022#817395022, /profile/wiedem'] Wasn't the codesign utility once open source? [/quote] I’m not sure if codesign was ever open source, but the core code signing infrastructure is. It lives within the Security

The approach I usually take is to export the app from the Xcode organiser and then use notarytool to attempt to notarise that. The advantage of that approach is that you end up with a notary log [1] and the exact file that was submitted to the notary service. You can then look at the file to see what’s what. I’ve found that using Xcode for notarisation is very convenient under normal circumstances, but it adds a layer of abstraction that I’d rather not have when I’m dealing with the weird stuff. Submitting with notarytool is pretty easy; see Customizing the notarization workflow for instructions. Once you have these two bits of info — the file you submitted and the notary log — there are two things I’d recommend you do: Unpack the file on a case-sensitive volume and see if that changes the result of the code signature verification (that is, the codesign --verify --strict --deep -vvv … command). Check the zip archive for extended attributes. You can list the archive’s content with unzip -l. You want t

[quote='817402022, DTS Engineer, /thread/770409?answerId=817402022#817402022'] So, yeah, DTS doesn’t support that. [/quote] I can understand if it's not actively supported, but I wouldn't call providing technical documentation 'active support'. There are several official Apple articles on the subject, but most of them are not very detailed. Wasn't the codesign utility once open source? Since the reorganisation of Apple's OSS pages, many things are not so easy to find. [quote='817402022, DTS Engineer, /thread/770409?answerId=817402022#817402022'] Please post your bug number, just for the record. [/quote] The Feedback Assistant ID is FB16077892 (But for some reason my feedback seems to have been deleted immediately? At least I don't seem to be able to access it anymore) Based on my experience over the last 15 years with this type of developer feedback for iOS development, it will be years before such a feature is available in iOS. If an implementation is considered at all. In the meantime, we need a pr