Sure. But at some point these things stop being technical questions and instead become a reflection of your policy. I agree/understand regarding the policy. I framed the question oddly, but I was really asking if that policy made sense (i.e., was there some other approach to do what I'm saying or is there anything unforseen that I'd encounter). I've already implemented it though and it seems to work out fine, so we'll stick with it. Yes. That is, in fact, the whole reason for a DR, in that it’s a cryptographically sound way for the code to identify itself, such that the system knows that version N+1 of your app is the ‘same code’ as version N. Ok, that's great. My concern was that what constitutes a DR (as emitted by codesign) could change in the future, and that "same code" meant the exact code the DR was computed for at the time it was run. This is obviously not the case since it is only reliant on certificate OIDs and such (so I'd assume if the signing certificate changes that would be the only thing that invokes a change in the DR). However, I wasn't sure if that was just the current policy from Apple and that in the future, there would be some type of hash added or something. Sounds like that's not the case, so that makes things quite a bit easier. Thank you again! D

Also, is it safe to assume we can reuse the same DR between builds of the production version of our app (assuming the developer ID cert never changes)?

Alright, a bit more pain but I agree with the approach of erring on the side of security. However, that creates a new challenge in that we want to run the local development AND release versions of the app (we want to develop and drink our own champagne i.e., use our product in tandem), and they both need the same permissions. My sense is that we should probably use a local prefix on the app bundle ID (and create a new app in our Apple Developer account), such as local.com.example.app. Then, use the "generalized" developer certificate CR for the policy we apply for the local.com.example.app. The production version (for both our staging/prod envs) would then just drop the local. prefix and use the DR since both envs use our Developer ID cert. Does that make sense? Thanks again for the help, D

Yeah, my biggest concern is that the OS has some requirements on the CR (specific fields being checked) even though the code requirement language seems generic. Sounds like that isn't the case. I've made a requirement that looks like this now, and it seems to work for both cases (note: there seems to be a weird bug in the forum that pushes code fence markdown to the end of the message): identifier "com.example.app" and anchor apple generic and certificate leaf[subject.OU] = ##TEAMID## However, I'm clearly not checking on the cert OIDs which you had, though I am checking on the apple generic anchor. Security wise, I assume the apple generic anchor is good enough (unless there's some other way to get an apple-signed certificate with our developer team ID in the OU that i'm not aware of). Else I think i'd have to use an OR condition in the CR that tests for the existence of the development cert OID(s) OR the developer ID cert OID(s). As always, thank you so much for your help. D

Has this issue been fixed? I'm calling xpc_listener_set_peer_code_signing_requirement but it doesn't seem to actually enforce the CR. It does fail to parse if i give it an invalid CR, but when it passes, it still accepts any session... Nevermind, xpc_listener_set_peer_code_signing_requirement works well -- just needed to start the listener in the inactive state. Someone has been busy solving something similar (go/xpc bindings): https://github.com/akerouanton/go-xpc/blob/main/pkg/xpc/listener.m

With XPC, yes. See Validating Signature Of XPC Process. Ok perfect, this is exactly what I was looking for. Thanks! If so, that’s fine. In this layout, A is the main executable for A.app and B is a ‘helper tool’. The location it’s in, Contents/MacOS, is one of the standard locations appropriate for helper tools, per the advice in Placing Content in a Bundle. The only reason you might need to be B into a bundle is if it needs a restricted entitlement. See Signing a daemon with a restricted entitlement. Spot on. I actually have services A, B and C (I omitted info about C because it wasn't extremely relevant, but I'll bring it up here to relate it to what you're saying). C does have a restricted entitlement (endpoint security), so I placed it into an app bundle under Contents/Frameworks. Sounds like I can move it under Contents/MacOS, and have A, B, and C all under there (with C being a bundle). Also sounds like it won't really make a difference at all if I don't (unsure if it being under Frameworks has any unforseen consequences but sounds like it would not, other than just being incorrectly classified in app bundle ontology). That’s not going to work. To listen on a named XPC endpoint, you must be started by launchd with a configuration that includes that endpoint name. I talk about this in a lot more detail in XPC and App-to-App Communication. Yeah this makes sense. I had briefly thought to do this, but wasn't sure if there was a different way that may be easier. Have your development daemon launch on demand. This is the default, but my experience is that lots of folks disable launch on demand by setting RunAtLoad or via the KeepAlive property. Ah perfect, yeah I have RunOnLoad set in the launchd config (doh). This makes sense. I think i'll try to use this approach over SMJobSubmit as it's a bit less effort to maintain config for our local development environment than an entirely new branch of code. Yep. My go-to tool for that is LOCAL_PEERTOKEN (see this thread) but it’s not as secure as XPC. Specifically, it tells you who created the socket, not who sent the message, and it’s the latter that really matters. Yeah I'll stick with XPC. I have it working (other than getting signing authN up). Thank you! D

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

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 internally in our app to validate configuration payloads came from us. We do this by using AWS KMS to gen/store the private key for our identity, then utilize their Sign/Verify APIs for code signing and verification (note i'm using code signing a little loosely here--what we do is not akin to what the codesign tool does). Because AWS KMS generates the key, we never have a developer touch it and it can never be extracted + we gain auditing on any uses of it. Mostly weighing options on how to make this as painless for our internal developers as possible. Thanks again!

Can't exactly say why, but this was likely a typo with the bundle id / domain I was using. It works as expected now.