“codesign”

Making progress here: Upgraded to Sequoia 15.3.1, Xcode 16.2 Codesigning executable returns 'satisfies its Designated Requirement' using: codesign --force --verify --verbose=4 --options runtime --timestamp --entitlements '/Users/chip/Desktop/PATHmanager.entitlements' --sign 'Apple Distribution: Chip Castle Dot Com, Inc. (BXN9N7MNU3)' '/Users/chip/Desktop/distribution/PATHmanager.app/Contents/MacOS/PATHmanager' Productbuild .pkg file returns successfully using: productbuild --sign '3rd Party Mac Developer Installer: Chip Castle Dot Com, Inc. (BXN9N7MNU3)' --identifier 'com.chipcastle.pathmanager' --version '1.15' --component '/Users/chip/Desktop/distribution/PATHmanager.app' /Applications '/Users/chip/Desktop/PATHmanager.pkg' Verifying signature returns 'satisfies its Designated Requirement' using: codesign --verify --verbose=4 '/Users/chip/Desktop/distribution/PATHmanager.app/Contents/MacOS/PATHmanager' Transporter uploads successfully. Running Verify via Transporter returns error:

I’ve learnt a new trick so I wanted to expand on the steps I posted yesterday. I started off by running the steps up to “My next step was to add an app group to the app” point. From there I did this: On the Development website, I confirmed that the target app group ID, group.eskimo1.test, was allocated to my team. In Xcode, I navigated to the build settings for my app target. I clicked the add (+) button and added a custom build setting of REGISTER_APP_GROUPS with a value of YES. This enables the iOS-style app groups UI on Xcode 16.2. I navigated to Signing & Capabilities and added the App Groups capability. Under the group list I clicked the add (+) button. This presents the iOS-style UI. In that UI, I entered my group, group.eskimo1.test, and click OK. Xcode’s automatic code signing machinery kicked in and updated my profile. No muss, no fuss! I chose Product > Build. I dumped the signing state of the development app: % codesign -d --entitlements - Test775022E.app … [Dict] [Key] com.apple.ap

One of my goals for today was to explore how Xcode 16.2 handles the app group changes we recently introduced. So I sat down and ran some tests. As a first step, I created a new app that does need a provisioning profile but doesn’t use an app group. The goal here is to cause Xcode to create and stash the development and distribution profiles for that app. Here’s what I did: Using Xcode 16.2 on macOS 15.3.1, I created a new app from the macOS > App template. I gave it a new, unique bundle ID, com.example.apple-samplecode.Test775022D, to make sure I’m starting from scratch. Note Note the D suffix. It took me 4 tries to get this right (-: In the Signing & Capabilities editor, I set the Team popup and confirmed that automatic signing was enabled. I added the iCloud capability. This forces Xcode to allocate an App ID and generate a profile for that App ID. Without that, Xcode uses my wildcard App ID, which just confuses things. I left the iCloud setup blank. I don’t need this app to use iCloud. I chose Produ

An EtreCheck report tells that my app is not signed, while codesign -dv /Applications/***.app returns a valid signature. I'm lost... EtreCheck isn't designed to be used with developer builds of apps. It only considers Developer ID and App Store builds as valid. You should consider spctl the authoritative result. Years ago, I used to use codesign more and I would test a Developer ID build with codesign -vv -R=anchor apple generic /path/to/app. However, you also mentioned TestFlight. I've never used TestFlight, but isn't that an App Store thing? So are you doing developer-signed builds? EtreCheck has no idea about that. Never attempt to disable Gatekeeper on your developer machine. That would be a bad idea. Thankfully, Apple recently added an extra hoop to jump through that saved you. I'm sure your Sequoia install is fine. It's the app that's corrupt. I was confused at first when you were talking about Monterey and App Store. You need at least Ventura/Xcode 15 for App Store submission

[quote='775159021, adminTC, /thread/775159, /profile/adminTC'] The installer contains a flat file [/quote] Is that a Mach-O executable? Or something else? Because, in general, the notary service only requires that you sign the code within your installer package. If it contains data, you have to sign the package but you don’t have to sign the data that the package installs. Still, the most likely cause of your problem is a misunderstanding about how to sign installers. Installers are not code, and thus: You don’t sign them with codesign, but rather with installer-specific tools. You don’t use your Developer ID Application code-signing identity, but rather your Developer ID Installer signing identity. Packaging Mac software for distribution has all the details. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks again. I ended up just following your advice from the original post and heavily documenting how to create developer (NOT distribution) certificates for my developers to use. Our distribution certificate is now just hooked into CI (and only there). Seems to work for our use cases! There are still a few fun things to determine, like computing a developer or distribution 'code requirement' so we can enable the full disk access TCC config for our app (codesign -dr - foo.app wants to pin the CR to the developer's CN). However I think i'll just post separately about that at some point. Thanks again! D

[quote='826188022, aehlke, /thread/758358?answerId=826188022#826188022, /profile/aehlke'] looks like this behavior has changed in the last day or two for macOS? [/quote] Yes! It makes me very happy to say that there’s been a significant improvement in this space. It’s now possible to create a macOS provisioning profile that authorises the use of an iOS-style app group. I’ve made a quick update to App Groups: macOS vs iOS: Fight! just now, but at some point I’ll go back to that post and update it properly with all the details. I tested this today with Xcode 15.4b1 running on macOS 15.3.1. Here’s a regular macOS app [1], created from the macOS > App template, using automatic signing, signed for development with an iOS style app group: % codesign -d -vvv Test721701.app … Authority=Apple Development: Quinn Quinn (7XFU7D52S4) … % codesign -d --ent - Test721701.app … [Dict] … [Key] com.apple.security.application-groups [Value] [Array] [String] group.eskimo1.test … % security cms -D -i Test72170

I was able to solve the self-update problem with Quinn's advice regarding codesigning with designated requirements. AssociatedBundleIdentifiers still doesn't work as documented, so I have opened a feedback ticket: FB16563823. Thanks for the help Quinn!

We were missing a step where we were not embedding the provisioning profile in our app, so we created one with default entitlements using our developer account and downloaded that. Then we provided this provisioning profile and the entitlements to the electron build process which embedded the provisioning profile in our app. We also checked the provisioning profile with the commands provided in the link. The app you uploaded to the bug is properly signed. The output of: codesign -dvvv --ent :- Lists these entitlements: com.apple.security.cs.allow-dyld-environment-variables com.apple.security.cs.allow-jit com.apple.security.cs.allow-unsigned-executable-memory com.apple.security.cs.disable-library-validation com.apple.security.device.usb While the output of: security cms -D -i /Contents/embedded.provisionprofile Is this: Entitlements com.apple.application-identifier __TEAM ID__.__BUNDLE ID___ keychain-access-groups __TEAM ID__.* com.apple.developer.team-identifier __TEAM ID__ Once again, please ta

Thank you. I did a little more digging after writing this post yesterday, and better understand the difference now between certificate categories (distribution/development). So the complexity with the developer build process is it seems like xcode manages all of this and is the easy way to do things. However, our project is primarily Go with some embedded objective-c. In other projects within our org, we have sort of a standard way of setting things up (using makefiles). For example, to get a development environment up for a specific project, we just clone and run make dev for consistency and sanity. I'm not ultra familiar with xcode, so I'm not sure if it's worth the hassle to have it run the go build, and i'm unsure of whether we can use CI if we do. Somewhat related follow-up question: Is there a way to avoid touching the private key for the precious developer certs (i.e., have a hardware security module / HSM generate and store the key and use an audited service? We use code signing certificates internall

[quote='774923021, chipcastle, /thread/774923, /profile/chipcastle'] Is the .app directory and file structure/naming sufficient? [/quote] It looks reasonable enough. A good place to start with this stuff is Placing Content in a Bundle. If you need more info then create a test project in Xcode, build it, and see what it did. [quote='774923021, chipcastle, /thread/774923, /profile/chipcastle'] how do I lint this file … ? [/quote] You can lint it with plutil. Indeed, I recommend you do that. Actually, my general advice is that you use plutil to convert it to the XML format, which means it’s not just technically correct but in the canonical format. [quote='774923021, chipcastle, /thread/774923, /profile/chipcastle'] and determine if it contains all of the necessary key/value pairs? [/quote] It’s hard to answer that, because it depends what you app does. However, a good place to start is with the above-mentioned Xcode project. [quote='774923021, chipcastle, /thread/774923, /profile/chipcastle'] is codesigning