“codesign”

In the meantime, I've discovered a few more facts, which I'll detail here. I'll also file some bugs and attach their numbers here. Perfect, thank you. I did manage to get a PCI driver to match and install on a victim machine. I used an Xcode-generated profile that includes our own PCI entitlement, but installed the driver on a machine with entitlement checks turned off. Yep, that will work. It's not something I can really recommend (for obvious reasons), but it is intentional that this does work. Moving to here: I then tried making a USB driver for development (for a vendor ID we don't have an entitlement for). On my usual Mac, the driver won't load because the entitlement in my provisioning profile is for a specific vendor ID - I can't choose the development USB transport capability. First, as a quick clarification, the term capability is basically a term Xcode invented for its own UI because what it's actually showing is a mix of: Entitlements Other stuff (like Info.plist keys) which are NOT in fact entitle

[quote='852386022, VBFSDEV, /thread/795578?answerId=852386022#852386022, /profile/VBFSDEV'] they will have access to all certificates, as you cannot grant selective certificate access. [/quote] I think you’re confused by the terminology here (an industry-wide problem, alas). It’s fine to give anyone access to a certificate. It only contains a public key. To sign code you need a digital identity, aka a code-signing identity, which is a certificate and the private key that matches the public key in that certificate. So, there’s no issue with your freelancer being able to access your Developer ID certificate [1]. What you have to protect is the matching private key. I discuss this terminological confusion in more detail in TN3161 Inside Code Signing: Certificates [quote='852386022, VBFSDEV, /thread/795578?answerId=852386022#852386022, /profile/VBFSDEV'] there is no solution to perform our signing process without granting the freelancer access to our app store connect account, correct? [/quote] It’s not that ther

When I look at the available capabilities I can add to an app identifier on the Developer portal, I see com.apple.developer.driverkit.transport.usb, which is development only. There's no development only capability for PCI. Yes, and please file a bug about this and post the bug number back here. I don't know WHY there isn't a development only entitlement (I wasn't involved with DriverKit at the time), but it's a decision I'd like to revisit. And yes... Does this mean it isn't possible to develop even a proof-of-concept PCI driver without being first granted the DriverKit PCI (Primary Match) entitlement? ...that's exactly what it means. You could do this by disabling SIP (and possibly AMFI), but you can't use the more elegant flow the development entitlements allow. In addition: When adding capabilities to a driver, the list of available capabilities shown in Xcode has one DriverKit PCI (Primary Match) entry, but if I double-click it, two such entries appear in the Signing and Capabilities tab for my driver ta

CloudKit uses your app’s com.apple.developer.icloud-container-environment entitlement to discover whether you’re using a Development or Production version of your provisioning profile, as documented in Testing Your Code Using the Development Container. Apps running on simulators use the Development environment; apps running on a device with Xcode by default use the Development environment as well. If that is the way you run your app to populate the data, the data will go to the the Development environment. TestFlight and App Store apps by default use the Production environment, and so I am wondering if you unintentionally change the entitlement to have your app use the Development environment. You can verify by running the following command line: $ codesign -d --ent :- The output should contain something like this: aps-environment production If you see that the value of the key is development, that will explain why your app writes to the Development environment, and you can double check if you chang

We don't typically use Xcode for development of this app (our build environment uses CMake and Ninja for the most part), but adding --identifier org.mozilla.macos.FirefoxVPN to the codesign arguments to the daemon binary seems to have gotten the service to run successfully across the upgrade.

[quote='852314022, VBFSDEV, /thread/795578?answerId=852314022#852314022, /profile/VBFSDEV'] do you mean adding the freelancer to my app store connect account? [/quote] Yes. Just like you would do for iOS. [quote='852314022, VBFSDEV, /thread/795578?answerId=852314022#852314022, /profile/VBFSDEV'] which role would you recommend … ? [/quote] That’s a balance between what authority you want to grant them and how much time you want to spend servicing their requests for credential manipulation. Although, having said that, I’ll note that this is no different than it is for iOS. IMPORTANT There’s one thing to watch out for here. If you make them an Admin, don’t explicitly allow them to created Developer ID certificates. See the “Create cloud-managed Developer ID certificates” row in Developer > Support > Articles > Program Roles. [quote='852314022, VBFSDEV, /thread/795578?answerId=852314022#852314022, /profile/VBFSDEV'] You also say that we should not grant access to any certificates [/quote] There are multi

Hi Quinn, Thanks for your reply, yet I'm still a little confused, as mentioned all I've done so far is to release mobile apps through automated signing via XCode for iOS (iPhones and iPads). I am also not sure if the freelancer developed the app within XCode. Can you maybe be more precise regarding: Regarding 1., do you mean adding the freelancer to my app store connect account? If not, where? If so, which role would you recommend, according to the principle of least needed access? You also say that we should not grant access to any certificates, so I'm a little confused by this proposition. Regarding 2., are we supposed to provide that Apple Developer Identity to him? Regarding 5., do yo mean sign codesign the app with the developer ID I generated and then notarize the app? If I understand things correctly, these two things have to be done also in the future before releasing any update, correct ?

I followed the instructions in the link you provided: Exporting a Developer ID Network Extension: https://developer.apple.com/forums/thread/737894 However, when I try to open the application, I receive a popup error: The application can’t be opened. When I check the macOS console log, I see the error: Unsatisfied entitlements Specifically: error 12:01:34.578205+0700 taskgated-helper com.xxx.xxx: Unsatisfied entitlements: com.apple.developer.system-extension.install, com.apple.developer.networking.networkextension, com.apple.developer.team-identifier However, when I inspect the application using the terminal command: codesign -d --entitlements I see that my application is signed and contains all the necessary entitlements, including: com.apple.developer.system-extension.install com.apple.developer.networking.networkextension with the value content-filter-provider-systemextension com.apple.developer.team-identifier = 63D4662568 Can you please help me resolve this issue?

This was never resolved properly. My Developer ID Certificates exist in two places within KeychainAccess: (correct) from login in MyCerticates (incorrect) from system in Certificates I tried to clean this up, but found that from the GUI, when you say to delete the Certificate in the incorrect location, it also deletes the one in the correct location. I accepted the status quo (2 copies of Certificate). The Codesign tool (embedded within the jpackage script) gives a warning two copies found of the certificate, choosing to use the fist one. Because of that failsafe feature, I was able to complete all my codesigning. With that, this thread is closed.

POSSIBLE CLUE: This feedback from: codesign --display --verbose=2 indicates a valid Developer ID signature is attached, (not an adhoc signature) pierrebierre@Pierres-iMac ~ % codesign --display --verbose=2 ~/DFG2D_MacOS_Manufacturing/JogAmpSignedJar/jogamp-fat/natives/macosx-universal/libnewt_head.dylib Executable=/Users/pierrebierre/DFG2D_MacOS_Manufacturing/JogAmpSignedJar/jogamp-fat/natives/macosx-universal/libnewt_head.dylib Identifier=libnewt_head Format=Mach-O universal (x86_64 arm64) CodeDirectory v=20400 size=912 flags=0x0(none) hashes=23+2 location=embedded Signature size=9047 Authority=Developer ID Application: Pierre Bierre (SL7L4YU8GT) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Aug 4, 2025 at 11:36:17 AM Info.plist=not bound TeamIdentifier=SL7L4YU8GT Sealed Resources=none Internal requirements count=1 size=172 The codesign --verify --verbose command gives: pierrebierre@Pierres-iMac ~ % codesign --verify --verbose ~/DFG2D_Mac

I have a valid Developer ID certificate and key. When I codesign, I'm prompted to enter my system pw. codesign gives absolutely ZERO feedback that it isn't using the Developer ID I reference in the codesign command line. It just says it's signed in response to --verify. You haven't told me anything specifically actionable, like how would I verify during code signing that it's using my Developer ID vs. adhoc. Is there a way to tell, short of the long, exasperating feedback loop leading to Notarization testing?

The immediate cause of your problem is you have code that’s not signed: % file /Volumes/DataflowGeometry2D/DataflowGeometry2D.app/Contents/app/DFG2D_Mac_x86_313.jar /Volumes/DataflowGeometry2D/DataflowGeometry2D.app/Contents/app/DFG2D_Mac_x86_313.jar: Java archive data (JAR) % mkdir DFG2D_Mac_x86_313 % cd DFG2D_Mac_x86_313 % unzip /Volumes/DataflowGeometry2D/DataflowGeometry2D.app/Contents/app/DFG2D_Mac_x86_313.jar Archive: /Volumes/DataflowGeometry2D/DataflowGeometry2D.app/Contents/app/DFG2D_Mac_x86_313.jar … inflating: lib/jogamp-fat/jogamp-fat.jar … % mkdir jogamp-fat % cd jogamp-fat % unzip ../lib/jogamp-fat/jogamp-fat.jar Archive: ../lib/jogamp-fat/jogamp-fat.jar … inflating: natives/macosx-universal/libjocl.dylib … % file natives/macosx-universal/libjocl.dylib natives/macosx-universal/libjocl.dylib: Mach-O universal binary with 2 architectures… … % codesign -d -vvv natives/macosx-universal/libjocl.dylib … CodeDirectory v=20400 size=1606 flags=0x20002(adhoc,linker-signed) … … The notary service

My latest process is still failing Notarization, saying 10 .dylib files (located in the jog amp MacosX Universal Binaries folder) are unsigned. My process: Unarchive jogamp-fat.jar (command line too jar xf) codesign --timestamp all 10 .dylib files confirm all signed reJar the jog amp-fat.jar codesign the jar, and confirm signed add signed jar back into Eclipse Java project as an external library Export app jar use jpackage tool to sign app jar , build .dmg, and sign that test run install and launch submit .dmg to Notarization Will try to email the .dmg to Quinn

I have played around a bit more with the code: I tried passing pointers to the functions themselves Making sure the callbacks are called from the mainthread But nothing seems to work. I did stumble into this page though https://developer.apple.com/documentation/xcode/investigating-memory-access-crashes#Use-VM-Region-Info-to-locate-the-memory-in-your-apps-address-space And it's useful to understand the crash logs. My full crash is: Exception Type: EXC_BAD_ACCESS (SIGKILL) Exception Subtype: KERN_PROTECTION_FAILURE at 0x0000000000000000 Exception Codes: 0x0000000000000002, 0x0000000000000000 VM Region Info: 0 is not in any region. Bytes before following region: 4307271680 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 100bbc000-100bc0000 [ 16K] r-x/r-x SM=COW /var/containers/Bundle/Application/D7CA13B9-71D1-467E-882D-317F9AF57049/OpacityPod_Example.app/OpacityPod_Example Termination Reason: CODESIGNING 2 Invalid Page So it's clearly a pointer exceptio