I have a simple CLI app bundle that activates my system extension. When I sign it for development it works fine. However, once I sign it with my developer ID certificate for distribution, the network extension will not activate, getting stuck the activation request and completely killing any internet connectivity until I restart.
The only thing that I see is different is when I call systemextensionsctl list I get something like:
1 extension(s)
--- com.apple.system_extension.network_extension
enabled active teamID bundleID (version) name [state]
<TEAM_ID> com.company.networkExt (1.0/240116145656) - [validating by category]
* * <TEAM_ID> com.company.networkExt (1.0/240115061310) ProxyExtension [activated enabled]
Where the one specifying [validating by category] is the one that I'm trying to activate signed with the developer ID cert. The one that is [activated enabled] got there from a dev build.
The app was built and notarized and shows to be valid by any codesign -dv --verify --strict and spctl commands that I've found. The system extension is also valid according to codesign.
The entitlements are adjusted to use the -systemextension suffix to work with Developer ID certificates.
Is there another step required to make it work with a developer ID certificate?
Code Signing
RSS for tagCertify that an app was created by you using Code signing, a macOS security technology.
Posts under Code Signing tag
201 Posts
Sort by:
Post
Replies
Boosts
Views
Activity
Hi,
I have an app generated by using osacompile on an applescript file. The app works fine as expected.
However, when I try to sign it, I get two errors as in the screen shot below:
After some googling around, I deleted the _CodeSignature folder in the .app directory but still signing fails with the same error.
So, I would like to know two things:
Is it possible to sign .app files created using osacompile as in my case?
If yes, what am I missing and how to resolve my situation.
Thanks,
I’m developing this tvOS app, and it builds and runs fine locally in Simulator.
However, when I do Product > Archive (so I can upload it to app store later), it fails with error in the screenshot.
Looks like Xcode is trying to sign the app with a certificate, but could not find a valid profile to do so.
Since I don't have a physical Apple TV device, I'm unable to add an Apple TV to the Devices list on developer.apple.com, thus unable to create a profile.
Is the any way around this issue to archive my tvOS app?
I'm working on an app using entitlements. The entitlements are setup in its code signature and they are also applied in the corresponding provisioning profile.
I embed said provisioning profile in the app, but when I launch the binary it gets rejected by taskgated-helper (as seen in console.app it says "profile not found").
However, if I install the same embedded provision profile it will work! So I can only assume taskgated-helper is not looking in the Contents/embedded.provisionprofile file when I try to run the binary?
I can only imagine that the issue revolves around the binary not being the main bundle binary in the application, as that one works just fine without installing the profile.
I would simply install the profile to fix the issue, but it brings other problems when trying to install the application in a headless environment (as opening the profile to install in system settings requires user interaction).
Any ideas?
Hi,
I've ran into an issue which only seems to affect one of my macs.
It's currently running 14.2.1 but I first saw this issue in 13.6.
If I download the macOS Sonoma 14.2.1 installer (via App store) onto this particular machine, it will never execute the installer. It always reports that the installer is "damaged". Of course I did reasearch this online and you get the usual unhelpful posts which just say "re download it" and of course, I wouldn't be posting here had I not tried that.
This happens with any macOS installer I download using the softwareupdate --fetch-full-installer utility as well. The thing is, if I copy this .app to another (identical as far as I can tell) Mac - it will work. So far this also seems limited to macOS installers - other third party apps are fine. I'm convinced this is related to trusted execution and something has gone wrong in the environment. I've been looking at my router logs to see if any connections may have been blocked (I'm using OPNsense) and also looking to see what connections are being made via Little Snitch and so far it looks fine. Again, other machines on the network can run these just fine.
I've read through eskimo's excellent guide here: https://forums.developer.apple.com/forums/thread/706442 but I was wondering if anyone can give me some pointers to narrow this down further.
As it stands, I can't trust this machine for app development if I can't even get the official Apple installers to run sucessfully.
I develop an App for Mac and iPhone, and till now, I had no issue to test it on my iPhone.
but this morning, I have the following message, when I try to run it on my iPhone:
Failed to verify code signature .... (A valid provisioning profile for this executable was not found.)
Verify that the Developer App certificate for your account is trusted on your device. Open Settings on the device and navigate to General -> VPN & Device Management, then select your Developer App certificate to trust it.
I must precise that it works on the simulator.
the version of Xcode is 15.2 and the version of iPhone is 17.2.1
when I go on Settings/VPN -> Device Management (on iPhone), I don't see any section for Developper App Certificate
when I go to Devices and Simulators on Xcode, and list the Provisioning Profiles installed on my iPhone, I see the IOS Team Provisioning Profiled of my application
but it still not work.
What can I do?
I am looking for any help regarding an errSecInternalComponent error I am seeing when trying to archive my iOS app via my CI process. Specifically, this CI process is a GitHub Action running on a self-hosted M2 Pro Mini machine to which we have Screen Share access. I have followed the very helpful seminal post and have confirmed that I can run the necessary command in the local terminal via Screen Share, and I don't get any Keychain Access dialogs to pop up. When I try to run the same command via an SSH terminal from my local machine on that same machine, I get the following error:
/Users/{username}/Library/Developer/Xcode/DerivedData/{projectID}/Build/Intermediates.noindex/ArchiveIntermediates/{projectname}/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/{some name}NotificationServiceExtension.appex: errSecInternalComponent
I only get the error for that one service extension target. The project is only a couple years old, created with Xcode 14 or maybe 13. The signing has always been managed automatically with the provisioning profiles for all our targets being managed by Xcode.
Thanks in advance for any advice or suggestions as to what I may be missing or how to address this problem. I am more than happy to provide any more information I can to diagnose and solve the issue.
I help a lot of developers with macOS trusted execution problems. For example, they might have an app being blocked by Gatekeeper, or an app that crashes on launch with a code signing error.
If you encounter a problem that’s not explained here, start a new thread with the details. Make sure to add relevant tags — like Gatekeeper, Code Signing, and Notarization — so that I see your post.
IMPORTANT macOS 14 has a new tool, syspolicy_check, that was specifically designed to help diagnose problems like this. I plan to update this post once I have more experience with it. In the meantime, however, if you hit a trusted execution problem and it reproduces on macOS 14, please try out syspolicy_check and let us know how that pans out.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Resolving Trusted Execution Problems
macOS supports three software distribution channels:
The user downloads an app from the App Store.
The user gets a Developer ID-signed program directly from its developer.
The user builds programs locally using Apple or third-party developer tools.
The trusted execution system aims to protect users from malicious code. It’s comprised of a number of different subsystems. For example, Gatekeeper strives to ensure that only trusted software runs on a user’s Mac, while XProtect is the platform’s built-in anti-malware technology.
Note To learn more about these technologies, see Apple Platform Security.
If you’re developing software for macOS your goal is to avoid trusted execution entanglements. You want users to install and use your product without taking any special steps. If, for example, you ship an app that’s blocked by Gatekeeper, you’re likely to lose a lot of customers, and your users’ hard-won trust.
Trusted execution problems are rare with Mac App Store apps because the Mac App Store validation process tends to catch things early. This post is primarily focused on Developer ID-signed programs.
Developers who use Xcode encounter fewer trusted execution problems because Xcode takes care of many code signing and packaging chores. If you’re not using Xcode, consider making the switch. If you can’t, consult the following for information on how to structure, sign, and package your code:
Placing Content in a Bundle
Embedding Nonstandard Code Structures in a Bundle
Embedding a Command-Line Tool in a Sandboxed App
Creating Distribution-Signed Code for Mac DevForums post
Packaging Mac Software for Distribution DevForums post
Gatekeeper Basics
User-level apps on macOS implement a quarantine system for new downloads. For example, if Safari downloads a zip archive, it quarantines that archive. This involves setting the com.apple.quarantine extended attribute on the file.
Note The com.apple.quarantine extended attribute is not documented as API. If you need to add, check, or remove quarantine from a file programmatically, use the quarantinePropertiesKey property.
User-level unarchiving tools preserve quarantine. To continue the above example, if you double click the quarantined zip archive in the Finder, Archive Utility will unpack the archive and quarantine the resulting files.
If you launch a quarantined app, the system invokes Gatekeeper. Gatekeeper checks the app for problems. If it finds no problems, it asks the user to confirm the launch, just to be sure. If it finds a problem, it displays an alert to the user and prevents them from launching it. The exact wording of this alert varies depending on the specific problem, and from release to release of macOS, but it generally looks like the ones shown in Apple > Support > Safely open apps on your Mac.
The system may run Gatekeeper at other times as well. The exact circumstances under which it runs Gatekeeper is not documented and changes over time. However, running a quarantined app always invokes Gatekeeper.
Unix-y networking tools, like curl and scp, don’t quarantine the files they download. Unix-y unarchiving tools, like tar and unzip, don’t propagate quarantine to the unarchived files.
Confirm the Problem
Trusted execution problems can be tricky to reproduce:
You may encounter false negatives, that is, you have a trusted execution problem but you don’t see it during development.
You may also encounter false positives, that is, things fail on one specific Mac but otherwise work.
To avoid chasing your own tail, test your product on a fresh Mac, one that’s never seen your product before. The best way to do this is using a VM, restoring to a snapshot between runs. For a concrete example of this, see Testing a Notarised Product.
The most common cause of problems is a Gatekeeper alert saying that it’s blocked your product from running. However, that’s not the only possibility. Before going further, confirm that Gatekeeper is the problem by running your product without quarantine. That is, repeat the steps in Testing a Notarised Product except, in step 2, download your product in a way that doesn’t set quarantine. Then try launching your app. If that launch fails then Gatekeeper is not the problem, or it’s not the only problem!
Note The easiest way to download your app to your test environment without setting quarantine is curl or scp. Alternatively, use xattr to remove the com.apple.quarantine extended attribute from the download before you unpack it. For more information about the xattr tool, see the xattr man page.
Trusted execution problems come in all shapes and sizes. The remaining sections address the most common ones.
App Blocked by Gatekeeper
If your product is an app and it works correctly when not quarantined but is blocked by Gatekeeper when it is, you have a Gatekeeper problem. For advice on how to investigate such issues, see Resolving Gatekeeper Problems.
App Can’t Be Opened
Not all failures to launch are Gatekeeper errors. In some cases the app is just broken. For example:
The app’s executable might be missing the x bit set in its file permissions.
The app’s executable might be subtly incompatible with the current system. A classic example of this is trying to run a third-party app that contains arm64e code.
macOS requires that third-party kernel extensions use the arm64e architecture. In other circumstances, stick to arm64 for your shipping products. If you want to test arm64e code locally, see Preparing Your App to Work with Pointer Authentication.
The app’s executable might claim restricted entitlements that aren’t authorised by a provisioning profile.
Or the app might have some other code signing problem.
Note For more information about provisioning profiles, see TN3125 Inside Code Signing: Provisioning Profiles.
In such cases the system displays an alert saying:
The application “NoExec” can’t
be opened.
[[OK]]
Note In macOS 11 this alert was:
You do not have permission to
open the application “NoExec”.
Contact your computer or network
administrator for assistance.
[[OK]]
which was much more confusing.
A good diagnostic here is to run the app’s executable from Terminal. For example, an app with a missing x bit will fail to run like so:
% NoExec.app/Contents/MacOS/NoExec
zsh: permission denied: NoExec.app/Contents/MacOS/NoExec
And an app with unauthorised entitlements will be killed by the trusted execution system:
% OverClaim.app/Contents/MacOS/OverClaim
zsh: killed OverClaim.app/Contents/MacOS/OverClaim
In some cases running the executable from Terminal will reveal useful diagnostics. For example, if the app references a library that’s not available, the dynamic linker will print a helpful diagnostic:
% MissingLibrary.app/Contents/MacOS/MissingLibrary
dyld[88394]: Library not loaded: @rpath/CoreWaffleVarnishing.framework/Versions/A/CoreWaffleVarnishing
…
zsh: abort MissingLibrary.app/Contents/MacOS/MissingLibrary
Code Signing Crashes on Launch
A code signing crash has the following exception information:
Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid))
The most common such crash is a crash on launch. To confirm that, look at the thread backtraces:
Backtrace not available
For steps to debug this, see Resolving Code Signing Crashes on Launch.
One common cause of this problem is running distribution-signed code. Don’t do that! For details on why that’s a bad idea, see Don’t Run App Store Distribution-Signed Code.
Code Signing Crashes After Launch
If your program crashes due to a code signing problem after launch, you might have encountered the issue discussed in Updating Mac Software.
Non-Code Signing Failures After Launch
The hardened runtime enables a number of security checks within a process. Some coding techniques are incompatible with the hardened runtime. If you suspect that your code is incompatible with the hardened runtime, see Resolving Hardened Runtime Incompatibilities.
App Sandbox Inheritance
If you’re creating a product with the App Sandbox enabled and it crashes with a trap within _libsecinit_appsandbox, it’s likely that you’re having App Sandbox inheritance problems. For the details, see Resolving App Sandbox Inheritance Problems.
Library Loading Problem
Most library loading problems have an obvious cause. For example, the library might not be where you expect it, or it might be built with the wrong platform or architecture. However, some library loading problems are caused by the trusted execution system. For the details, see Resolving Library Loading Problems.
Explore the System Log
If none of the above resolves your issue, look in the system log for clues as to what’s gone wrong. Some good keywords to search for include:
gk, for Gatekeeper
xprotect
syspolicy, per the syspolicyd man page
cmd, for Mach-O load command oddities
amfi, for Apple mobile file integrity, per the amfid man page
taskgated, see its taskgated man page
yara, discussed in Apple Platform Security
ProvisioningProfiles
Here’s a log command that I often use when I’m investigating a trusted execution problem and I don’t know here to start:
% log stream --predicate "sender == 'AppleMobileFileIntegrity' or sender == 'AppleSystemPolicy' or process == 'amfid' or process == 'taskgated-helper' or process == 'syspolicyd'"
For general information the system log, see Your Friend the System Log.
Revision History
2024-01-12 Added a specific command to the Explore the System Log section. Change the syspolicy_check callout to reflect that macOS 14 is no longer in beta. Made minor editorial changes.
2023-06-14 Added a quick call-out to the new syspolicy_check tool.
2022-06-09 Added the Non-Code Signing Failures After Launch section.
2022-06-03 Added a link to Don’t Run App Store Distribution-Signed Code. Fixed the link to TN3125.
2022-05-20 First posted.
I recently built an update to one of our apps, which installs a driver extension.
The new version won't launch on my Mac, Finder says it "can't be opened".
I captured the logs, which say "no matching profile found":
error 2024-01-10 14:36:03.306061 -0800 taskgated-helper <app-bundle-id>: Unsatisfied entitlements: com.apple.developer.system-extension.install, com.apple.developer.team-identifier
info 2024-01-10 14:36:03.306279 -0800 amfid Requirements for restricted entitlements failed to validate, error -67671, requirements: '<private>'
error 2024-01-10 14:36:03.306287 -0800 amfid Restricted entitlements not validated, bailing out. Error: Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" UserInfo={NSURL=<private>, unsatisfiedEntitlements=<private>, NSLocalizedDescription=No matching profile found}
default 2024-01-10 14:36:03.306432 -0800 amfid /Applications/<app-bundle-id>/Contents/MacOS/<app-name> not valid: Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" UserInfo={NSURL=file:///Applications/C<escaped-app-name>/, unsatisfiedEntitlements=<CFArray 0x14f3041d0 [0x1dd7d39a0]>{type = immutable, count = 2, values = (
0 : <CFString 0x14f3055a0 [0x1dd7d39a0]>{contents = "com.apple.developer.system-extension.install"}
1 : <CFString 0x14f304130 [0x1dd7d39a0]>{contents = "com.apple.developer.team-identifier"}
)}, NSLocalizedDescription=No matching profile found}
default 2024-01-10 14:36:03.306514 -0800 kernel AMFI: bailing out because of restricted entitlements.
default 2024-01-10 14:36:03.306523 -0800 kernel mac_vnode_check_signature: /Applications/<app-bundle-id>/Contents/MacOS/<app-name>: code signature validation failed fatally: When validating /Applications/<app-bundle-id>/Contents/MacOS/<app-name>:
Code has restricted entitlements, but the validation of its code signature failed.
Unsatisfied Entitlements: com.apple.developer.system-extension.installcom.apple.developer.team-identifier
The thing is, when I run this command
codesign -v -vvv <path-to-app>
the app is valid on disk and satisfies its Designated Requirement
and these two commands:
codesign --display --entitlements - security cms -D -i <path-to-app>/Contents/embedded.provisionprofile
when run against the old app (which works) and the new app (which doesn't) have absolutely identical outputs. The certificates haven't expired yet.
Where else should we be looking to figure out where we've messed up? We know we changed the signing and notarization flow; the working build was made by a person using Xcode, the new app was built, signed and notarized using the command line tools (xcodebuild and notarytool).
We have started creating third-party applications and for that we required to apple certificate and initially created multiple certificate (application and installer), later on realises that one can be enough to approve multiple application.
Now we are not seeing any option to remove or revoke the certificates so that we can create new certificate. Support team also not able to help on this.
What should we do to create new certificate?
Hi, after many hours looking for a solution I hope to find one here :)
I am creating an ios application using flutter. Since updating my macbook to MacOs Sonoma it is impossible for me to launch an archive of the application on Xcode (the error below is displayed).
By searching I thought I understood that it could come from Icloud but even if I put my App in the Application folder, I got this error. I can launch my application on Simulator but not on a physical phone either.
error: Target release_unpack_ios failed: Exception: Failed to codesign /Users/etiennemary/Library/Developer/Xcode/DerivedData/Runner-hcgaysxersoeaugykishvsewlgps/Build/Intermediates.noindex/ArchiveIntermediates/Runner/BuildProductsPath/Release-iphoneos/Flutter.framework/Flutter with identity ......
/Users/etiennemary/Library/Developer/Xcode/DerivedData/Runner-hcgaysxersoeaugykishvsewlgps/Build/Intermediates.noindex/ArchiveIntermediates/Runner/BuildProductsPath/Release-iphoneos/Flutter.framework/Flutter: replacing existing signature
Warning: unable to build chain to self-signed root for signer "Apple Development: Etienne Mary (. )"
/Users/etiennemary/Library/Developer/Xcode/DerivedData/Runner-hcgaysxersoeaugykishvsewlgps/Build/Intermediates.noindex/ArchiveIntermediates/Runner/BuildProductsPath/Release-iphoneos/Flutter.framework/Flutter: errSecInternalComponent
Failed to package /Applications/aa/evento.
Hello
on MacOS, I use following codes to get the sign of an application
char app_path[PATH_MAX+1] = {0};
uint32_t size = sizeof(app_path);
int ret = _NSGetExecutablePath(app_path, &size);
if (ret)
return -1;
NSString *app_path_str = [[NSString alloc] initWithUTF8String: app_path];
NSURL* url = [NSURL URLWithString:app_path_str];
CFURLRef path = (__bridge CFURLRef)url;
SecStaticCodeRef static_code;
OSStatus status = SecStaticCodeCreateWithPath(path, kSecCSDefaultFlags, &static_code);
and find when the path includes a space char( for example: "/Users/username/Downloads/test A/test.dmg")
SecStaticCodeCreateWithPath will always return -4960(errSecCoreFoundationUnknown?)
and it works well when the path doesn't contain space,
could anyone give some help?
thanks very much
I'm trying to setup a new build machine and I can't seem to get the signing certificates detected by the security
tool with "0 valid identities found"
My id is linked to a team but my role is "app manager". In my console I can see the certificates but cant download
the developerID installer cert.
In Xcode no ceritifcates show up for that team ID in the list.
The certs were generated by the developer console.
I had to get the client to insecurely send me the certs because of this restriction. I imported them into the
keychain but the tool still won't show anything.
Is this another problem not having the correct root certificate installed ? I had all this setup in a VMWAre which
was working before I lost all data due to a crash so setting it up fresh on a mac mini.
I should be able to have just synced the certs through xcode and start signing installers. I researched hundreds
of pages and no answer for my problem.
I am new to macOS development and presently tearing my hair out trying to get a driverkit extension to build. I have tried following the instructions here:
https://developer.apple.com/documentation/driverkit/communicating_between_a_driverkit_extension_and_a_client_app
namely, disabling SIP, but I am still unable to get my extension to build. The instructions say to set the code signing identity to "Sign to Run Locally" for all three targets, but this is not listed as an option for the driver extension.
Hello, I am rather new at publishing apps for Iphone and I am facing some difficulties. Maybe someone could point me what I am not understanding.
I am having some issues handling the usage of the Development Certificate . I have created a CSR, supplied it at apple.developer system to get a development certificate. I downloaded such a certificate and installed it. When I try to use it I get this status saying it is not trusted :
The result is this when trying to use it:
"
/Users/eao/build/dev/aquila_companion.xcodeproj: error: Missing private key for signing certificate. Failed to locate the private key matching certificate "Apple Development: Tiago DAagostini (GDH9UYDL8A)" in the keychain. To sign with this signing certificate, install its private key in your keychain. If you don't have the private key, select a different signing certificate for CODE_SIGN_IDENTITY in the build settings editor. (in target 'appaquila_companion' from project 'aquila_companion')
"
What am I missing? Where this p12 key should be? And is that related to that image where the Certificate is deemed not trusted?
I am trying to sign a Java application, packaged in a disk image, via jpackage, invoked via Ant (so no XCode anywhere). The packaging itself works fine, but I am having trouble figuring out the signing parameters. In particular, it seems I will have to provide a parameter
--mac-signing-key-user-name
What value should I give to this parameter? I have an Apple Developer Account (well, obviously...), I have generated a certificate and quite a few other things, but I am confused as to what the "signing-key-user-name" should be.
The error message I currently get from jpackage is:
No certificate found matching [...] using keychain []
I am on MAC OS 12.6 and JDK 17.
Any help would be greatly appreciated.
I am trying to run something I built with the CLI versions of clang on my M3 MBP. The application is signed:
codesign -d -v /usr/local/bin/wine*
Executable=/usr/local/bin/wine
Identifier=org.winehq.wine
Format=Mach-O thin (arm64)
CodeDirectory v=20400 size=275 flags=0x0(none) hashes=3+2 location=embedded
Signature size=8972
Timestamp=Dec 15, 2023 at 10:35:06 AM
Info.plist entries=12
TeamIdentifier=L479DU3G63
Sealed Resources=none
Internal requirements count=1 size=176
Executable=/usr/local/bin/wineboot
Identifier=wineboot
Format=generic
CodeDirectory v=20200 size=168 flags=0x0(none) hashes=1+2 location=embedded
Signature size=9053
Timestamp=Dec 15, 2023 at 10:35:06 AM
Info.plist=not bound
TeamIdentifier=L479DU3G63
Sealed Resources=none
Internal requirements count=2 size=216
Executable=/usr/local/bin/winebuild
Identifier=winebuild
Format=Mach-O thin (arm64)
CodeDirectory v=20400 size=1933 flags=0x0(none) hashes=55+2 location=embedded
Signature size=8972
Timestamp=Dec 15, 2023 at 10:35:06 AM
Info.plist=not bound
TeamIdentifier=L479DU3G63
Sealed Resources=none
Internal requirements count=1 size=172
Executable=/usr/local/bin/winecfg
Identifier=winecfg
Format=generic
CodeDirectory v=20200 size=167 flags=0x0(none) hashes=1+2 location=embedded
Signature size=9053
Timestamp=Dec 15, 2023 at 10:35:07 AM
Info.plist=not bound
TeamIdentifier=L479DU3G63
Sealed Resources=none
Internal requirements count=2 size=216
Executable=/usr/local/bin/wineconsole
Identifier=wineconsole
Format=generic
CodeDirectory v=20200 size=171 flags=0x0(none) hashes=1+2 location=embedded
Signature size=9053
Timestamp=Dec 15, 2023 at 10:35:07 AM
Info.plist=not bound
TeamIdentifier=L479DU3G63
Sealed Resources=none
Internal requirements count=2 size=220
Executable=/usr/local/bin/winegcc
Identifier=winegcc
Format=Mach-O thin (arm64)
CodeDirectory v=20400 size=747 flags=0x0(none) hashes=18+2 location=embedded
Signature size=8972
Timestamp=Dec 15, 2023 at 10:35:07 AM
Info.plist=not bound
TeamIdentifier=L479DU3G63
Sealed Resources=none
Internal requirements count=1 size=168
Executable=/usr/local/bin/winedbg
Identifier=winedbg
Format=generic
CodeDirectory v=20200 size=167 flags=0x0(none) hashes=1+2 location=embedded
Signature size=9052
Timestamp=Dec 15, 2023 at 10:35:07 AM
Info.plist=not bound
TeamIdentifier=L479DU3G63
Sealed Resources=none
Internal requirements count=2 size=216
Executable=/usr/local/bin/winedump
Identifier=winedump
Format=Mach-O thin (arm64)
CodeDirectory v=20400 size=3052 flags=0x0(none) hashes=90+2 location=embedded
Signature size=8972
Timestamp=Dec 15, 2023 at 10:35:07 AM
Info.plist=not bound
TeamIdentifier=L479DU3G63
Sealed Resources=none
Internal requirements count=1 size=168
Executable=/usr/local/bin/winefile
Identifier=winefile
Format=generic
CodeDirectory v=20200 size=168 flags=0x0(none) hashes=1+2 location=embedded
Signature size=9053
Timestamp=Dec 15, 2023 at 10:35:07 AM
Info.plist=not bound
TeamIdentifier=L479DU3G63
Sealed Resources=none
Internal requirements count=2 size=216
Executable=/usr/local/bin/winegcc
Identifier=winegcc
Format=Mach-O thin (arm64)
CodeDirectory v=20400 size=747 flags=0x0(none) hashes=18+2 location=embedded
Signature size=8972
Timestamp=Dec 15, 2023 at 10:35:07 AM
Info.plist=not bound
TeamIdentifier=L479DU3G63
Sealed Resources=none
Internal requirements count=1 size=168
Executable=/usr/local/bin/winegcc
Identifier=winegcc
Format=Mach-O thin (arm64)
CodeDirectory v=20400 size=747 flags=0x0(none) hashes=18+2 location=embedded
Signature size=8972
Timestamp=Dec 15, 2023 at 10:35:07 AM
Info.plist=not bound
TeamIdentifier=L479DU3G63
Sealed Resources=none
Internal requirements count=1 size=168
Executable=/usr/local/bin/winemaker
Identifier=winemaker
Format=generic
CodeDirectory v=20200 size=169 flags=0x0(none) hashes=1+2 location=embedded
Signature size=9052
Timestamp=Dec 15, 2023 at 10:35:07 AM
Info.plist=not bound
TeamIdentifier=L479DU3G63
Sealed Resources=none
Internal requirements count=2 size=224
Executable=/usr/local/bin/winemine
Identifier=winemine
Format=generic
CodeDirectory v=20200 size=168 flags=0x0(none) hashes=1+2 location=embedded
Signature size=9052
Timestamp=Dec 15, 2023 at 10:35:08 AM
Info.plist=not bound
TeamIdentifier=L479DU3G63
Sealed Resources=none
Internal requirements count=2 size=216
Executable=/usr/local/bin/winepath
Identifier=winepath
Format=generic
CodeDirectory v=20200 size=168 flags=0x0(none) hashes=1+2 location=embedded
Signature size=9053
Timestamp=Dec 15, 2023 at 10:35:08 AM
Info.plist=not bound
TeamIdentifier=L479DU3G63
Sealed Resources=none
Internal requirements count=2 size=216
Executable=/usr/local/bin/wineserver
Identifier=wineserver
Format=Mach-O thin (arm64)
CodeDirectory v=20400 size=5838 flags=0x0(none) hashes=177+2 location=embedded
Signature size=8972
Timestamp=Dec 15, 2023 at 10:35:08 AM
Info.plist=not bound
TeamIdentifier=L479DU3G63
Sealed Resources=none
Internal requirements count=1 size=172
but I still get:
default 11:47:19.051342-0500 kernel ASP: Security policy would not allow process: 1501, /usr/local/bin/wine
Permissions:
ls -al wine*
-rwxr-xr-x 1 root wheel 28368 Dec 15 10:35 wine
-rwxr-xr-x@ 1 root wheel 1973 Dec 14 23:41 wineboot
-rwxr-xr-x 1 root wheel 245424 Dec 15 10:35 winebuild
-rwxr-xr-x@ 1 root wheel 1973 Dec 14 23:41 winecfg
-rwxr-xr-x@ 1 root wheel 1973 Dec 14 23:41 wineconsole
lrwxr-xr-x 1 root wheel 7 Dec 14 23:41 winecpp -> winegcc
-rwxr-xr-x@ 1 root wheel 1973 Dec 14 23:41 winedbg
-rwxr-xr-x 1 root wheel 388400 Dec 15 10:35 winedump
-rwxr-xr-x@ 1 root wheel 1973 Dec 14 23:41 winefile
lrwxr-xr-x 1 root wheel 7 Dec 14 23:41 wineg++ -> winegcc
-rwxr-xr-x 1 root wheel 91840 Dec 15 10:35 winegcc
-rwxr-xr-x@ 1 root wheel 95127 Dec 14 23:41 winemaker
-rwxr-xr-x@ 1 root wheel 1973 Dec 14 23:41 winemine
-rwxr-xr-x@ 1 root wheel 1973 Dec 14 23:41 winepath
-rwxr-xr-x 1 root wheel 747120 Dec 15 10:35 wineserver
xattr wine*
wineboot: com.apple.cs.CodeDirectory
wineboot: com.apple.cs.CodeRequirements
wineboot: com.apple.cs.CodeRequirements-1
wineboot: com.apple.cs.CodeSignature
winecfg: com.apple.cs.CodeDirectory
winecfg: com.apple.cs.CodeRequirements
winecfg: com.apple.cs.CodeRequirements-1
winecfg: com.apple.cs.CodeSignature
wineconsole: com.apple.cs.CodeDirectory
wineconsole: com.apple.cs.CodeRequirements
wineconsole: com.apple.cs.CodeRequirements-1
wineconsole: com.apple.cs.CodeSignature
winedbg: com.apple.cs.CodeDirectory
winedbg: com.apple.cs.CodeRequirements
winedbg: com.apple.cs.CodeRequirements-1
winedbg: com.apple.cs.CodeSignature
winefile: com.apple.cs.CodeDirectory
winefile: com.apple.cs.CodeRequirements
winefile: com.apple.cs.CodeRequirements-1
etc., etc...
Since this is a new machine, maybe something is missing? How do I debug this problem? The most common response to ASP would not allow progress is that there is an unsigned binary. If this is the case, how do I find what binary it is?
Thanks!
Gene R.
We have developed a secure desktop app using QT, we are developing and delivering this app for more than 2 years. While deploying app we perform codesigning and notarization of app and we use Ventura on build system. So the issue we observed is that if we install this app on any macOS version below Sonoma it works as expected and in Apparency we can see code signature is verified and also app in notarized. But if we install the same app on Sonoma and check in Apparency, it shows signature can't be verified.
I'm trying to run an app that has a .dylib listed in the configuration of the application as "Embed & Sign"
I can confirm it is correctly signed by inspecting the package using codesign -dv --verbose=4 lib_paths.dylib and it gives me the following:
Executable=/Users/blablabla/Debug-iphoneos/TestApp.app/Frameworks/lib_paths.dylib
Identifier=lib_paths
Format=Mach-O thin (arm64)
CodeDirectory v=20400 size=784 flags=0x0(none) hashes=16+5 location=embedded
VersionPlatform=2
VersionMin=917504
VersionSDK=1049600
Hash type=sha256 size=32
CandidateCDHash sha256=7eaecbb8e00114767c9de0ac9054213620052212
CandidateCDHashFull sha256=7eaecbb8e00114767c9de0ac90542136200522121105dd217b38bd27e1fda4de
Hash choices=sha256
CMSDigest=7eaecbb8e00114767c9de0ac90542136200522121105dd217b38bd27e1fda4de
CMSDigestType=2
Executable Segment base=0
Executable Segment limit=32768
Executable Segment flags=0x0
Page size=4096
Launch Constraints:
None
CDHash=7eaecbb8e00114767c9de0ac9054213620052212
Signature size=4795
Authority=Apple Development: myemail@address.com (XXXXXXXXX)
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Signed Time=13 Dec 2023 at 21:39:28
Info.plist=not bound
TeamIdentifier=XXXXXXXXXXX
Sealed Resources=none
Internal requirements count=1 size=180
But when trying to run the application, I am getting the following error:
Referenced from: '/private/var/containers/Bundle/Application/3142F1F2-547B-41B5-8EF4-239F4EAD2A4F/TestApp.app/FSVTestApp'
Reason: tried: '/usr/lib/system/introspection/lib_paths.dylib' (no such file),
'/usr/lib/swift/lib_paths.dylib' (no such file),
'/private/var/containers/Bundle/Application/3142F1F2-547B-41B5-8EF4-239F4EAD2A4F/TestApp.app/Frameworks/lib_paths.dylib' (code signature invalid (errno=1) sliceOffset=0x00000000, codeBlobOffset=0x0000C5E0, codeBlobSize=0x00004B50 for '/private/var/containers/Bundle/Application/3142F1F2-547B-41B5-8EF4-239F4EAD2A4F/TestApp.app/Frameworks/lib_paths.dylib'),
Note that I enabled the "Automatically manage signing" option, and using a Personal Team.
This seems to work fine for the application itself (otherwise it wouldnt even try to load the dylib).
What is going on ?
I spent some time cleaning up my TCC data. During that I learned that some TCC info is cached in “Mac OS X Detached Code Signature” files. Is there a way to dump their contents suitable for human consumption? The codesign tool doesn’t seem to do it (or I can’t figure out how to invoke it).