codesign

In addition,app recently encountered a dyld crash similar to this crash on iOS15.5, which looks somewhat similar to the current crash. Not sure if it's the same, but it looks similar.See if it helps the analysis.I have a file bug,number is FB15719846 (iOS 15.5 dyld Crash),hope it helps.Thanks. Hardware Model: iPhone14,5 Process: XxxxxxXXX [265] Path: /private/var/containers/Bundle/Application/DAC8B886-80BB-48DB-916D-DBB854B69DFD/XxxxxxXXX.app/XxxxxxXXX Identifier: com.XxxxxxXXX.XxxxxxXXX Version: 8.1.3 (81300) AppStoreTools: 15F31e AppVariant: 1:iPhone14,5:15 Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: com.XxxxxxXXX.XxxxxxXXX [409] Date/Time: 2024-08-20 11:59:31.9614 +0800 Launch Time: 2024-08-20 11:37:02.3165 +0800 OS Version: iPhone OS 15.5 (19F77) Release Type: User Baseband Version: 1.61.00 Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGKILL - CODESIGNING) Exception Subtype: UNKNOWN_0x32 at 0x00000001048d0000 Exception Codes: 0x0000000000000032, 0x00

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. First, I had changed the bundle ID of my dext to what it should be, after learning that the bundle ID ought to be an extension of the owning application's bundle ID. This is common practice and what Xcode does by default, but I don't believe the system actually requires it, as it needlessly restricts/complicates what's possible without any real benefit. It's been

I found this topic while trying to solve pretty much the same issue in my project, and since I've found a solution, I was thinking to share it in case it would help someone else in the same situation. Turns out the framework in the build folder is not signed, so it couldn't be loaded properly. At the same time the framework located in the resulted application bundle is signed properly, but it was not used for some reason. You can check the signature of the framework with codesign -d -r - Shared.framework command. I was able to solve the issue by adding following properties to the build settings, hope it will help someone LD_RUNPATH_SEARCH_PATHS = @executable_path/Frameworks LD_RUNPATH_SEARCH_PATHS[sdk=macosx*] = @executable_path/../Frameworks Essentially it loads frameworks from the expected location for the iOS build and the other location for the macOS build (the bundle structure is different depending on the destination).

[quote='768005021, CynthiaSun, /thread/768005, /profile/CynthiaSun'] Are there any restrictions regarding this? [/quote] Yes. [quote='768005021, CynthiaSun, /thread/768005, /profile/CynthiaSun'] Is there a way to bypass these restrictions? [/quote] No. App bundles are read-only by design. This isn’t a new requirement [1], but recent changes in macOS’s trusted execution system mean that it’s more important to follow the rules. To quote Embedding nonstandard code structures in a bundle: A bundle is a read-only structure. All Apple platforms except the Mac enforce this requirement at runtime. On iOS, for example, any attempt to modify your app’s bundle at runtime will fail with an error. The Mac may or may not enforce this requirement at runtime, depending on the context, but modifying your app’s bundle isn’t supported because it breaks the seal on the app’s code signature. So your current goal, having the app modify itself, is unsupported, likely to cause problems today, and even more likely to cause problems i

This is clearly a bug. There should always be an audit token because some process must’ve started the flow. The next time you see this, please trigger a sysdiagnose log as soon as you see it, and then file a bug with that log. And once your done, I’d appreciate you posting the bug number here, just for the record. If you’re doing this on a ‘victim’ machine then you should enable additional NE logging via the VPN (Network Extension) for macOS instructions on our Bug Reporting > Profiles and Logs page. If you’re doing this on a real machine, you can enable that extra logging, but please consider the privacy impact. [quote='767822021, terransw, /thread/767822, /profile/terransw'] Not sure if relevant, but codesign with -dv showed different flags in CodeDirectory when compared to chrome: [/quote] That’s definitely not relevant. Chrome is opting in to some additional security checks, but Firefox gets most of those anyway because it’s enabled the hardened runtime (shown as runtime in that output). If yo

The system applies the same code signing and library validation checks regardless of whether you import the library or load the library dynamically. I agree with Etresoft that importing the library is the better option, but if you can’t change that then it’s not a showstopper. As to why LLDB is hanging, I don’t have an easy answer to that. I suspect it’s some sort of code signing or library validation issue. I’m disinclined to chase that because: LLDB isn’t a great tool for debugging code signing and library validation issues. It has enough on its plate being a debugger. Once you work out what’s going wrong with the library loading, it’s likely that LLDB will just start working again. Anyway, just to get us on a firm footing, I decide to run a test: On macOS 14.7.1 using Xcode 16.1, I created a new macOS app project. I downloaded the disk image from your first post and extracted the OpenSSL libraries. I modified them to be rpath-relative, per the docs I referenced above. I’ve put the exact commands at the end

I thought an example of the command line output might be useful, so here is the output of my specific test app: Command: codesign -dvvv --ent :- HIDKeyboardApp.app Entitlement block at end of output: .... com.apple.application-identifierVKPFXJZWAV.com.appledts.kevine.KeyboardAppcom.apple.developer.system-extension.installcom.apple.developer.team-identifierVKPFXJZWAVcom.apple.security.app-sandboxcom.apple.security.files.user-selected.read-only Command: security cms -D -i HIDKeyboardApp.app/Contents/embedded.provisionprofile Entitlement block at end of output: .... Entitlements com.apple.developer.system-extension.install com.apple.application-identifier VKPFXJZWAV.com.appledts.kevine.KeyboardApp keychain-access-groups VKPFXJZWAV.* com.apple.developer.team-identifier VKPFXJZWAV ExpirationDate 2042-10-07T18:15:36Z Name Mac Team Direct Provisioning Profile: com.appledts.kevine.KeyboardApp ProvisionsAllDevices TeamIdentifier VKPFXJZWAV TeamName Kevin Elliott TimeToLive 6570 UUID 339032ce-3f1c-4b56

Stepping back for a moment, I think it's important to understand what's actually going on here. The starting point here is that there are two sets of data at work here: (1) Your Xcode project has a set of data about your app, particularly the entitlement list, which are embedded in the codes signature of your app. That data can actually be viewed with the command: codesign -dvvv --ent :- (2) The developer portal has a set of data about apps bundle ID, particularly the entitlement list, which is used to generate a provisioning profile which will be embedded inside your apps bundle. That data can actually be viewed with one of the following commands*: *iOS and macOS use slightly different names and locations, a fact which is annoying when you jump back and forth between platforms. I wrote a script years ago which simply tried all 4 possibilities and am now working hard to not remember which is which. security cms -D -i /embedded.mobileprovision security cms -D -i /embedded.provisionprofile security cm