"Privilege separation" is one of the "two main reasons to use XPC services" given by https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html — With traditional applications, if an application becomes compromised through a buffer overflow or other security vulnerability, the attacker gains the ability to do anything that the user can do. To mitigate this risk, Mac OS X provides sandboxing—limiting what types of operations a process can perform. […] Each XPC service has its own sandbox, so XPC services can make it easier to implement proper privilege separation. The idea (iiuc) being that if the main process is compromised, the spicier operations have been separated out to a separate process space, and this improves the security of the system. But if the main process is compromised, and that main process is trusted by the more-privileged XPC service, is not the system still compromised in practice? That is rather than the exploit being: exploit some vulnerability gain arbitrary code execution do something naughty isn't the same still possible with just one extra step: exploit vulnerability arbitrary execution ask the XPC service nicely… …to do something naughty?

I am developing a suite of apps/helpers that get built into an installer package for deployment (outside The App Store). We have that release process ± working, except that most of the development team members are not admins/privileged on the team. They don't really need to publish on behalf of the team, and so we don't want to have debug builds also depend on being signed as "Developer ID Application". But that is running into problems… If I select instead "Sign to Run Locally" this results in an error for some of the build products along the lines of: [Build Target] requires a provisioning profile. Enable development signing and select a provisioning profile in the Signing & Capabilities editor. If I select "Apple Development" as the Code Signing Identity it leaves me with basically the same error as "Developer ID Application" does: Provisioning profile [Name of App/Helper] doesn't include signing certificate "Apple Development: [Name of Developer] ([TEAMID])" And finally, if simply set the Debug value for Provisioning Profile to "None" for the problematic products I get errors like: "[Name of app]" requires a provisioning profile. Select a provisioning profile in the Signing & Capabilities editor. I believe perhaps because some of the targets have an entitlements file granting access to various things (their own XPC services, their own shared preferences, as well as Outgoing Network Connections and com.apple.security.smartcard access…). In older versions of Xcode and/or macOS we didn't have trouble like this, local development could be done by basically any team member. Now it seems like maybe all developers need to have release-signing privileges to test/debug even on their own machines? Or is there a combination I'm missing, that would allow anyone on the team (or perhaps not even on the team) to build and debug the code locally, while still limiting who is able to actually sign notarized release builds on behalf of the team?

I am having trouble creating a CSR to renew a SecIdentity whose private SecKey is stored in slot 9d of a smartcard. For slot 9a, I am able to accomplish this by way of SecKeyCreateSignature using CertificateSigningRequest from a gently-modified fork of swift-certificates/swift-crypto to sort out all the details. But for the SecKey associated with slot 9d, the Security framework instantly returns an "algorithm not supported by the key" error when I call SecKeyCreateSignature, without even prompting for a PIN. I believe the difference is that kSecAttrCanSign is true for slot 9a but false for slot 9d. The value makes some sense for day-to-day usage because this identity is usually not used for signing, but if we are to occasionally sign a CSR for this key an exception would need to be made. Is there any way to basically force this exception with the Security framework? Again the actual private key material is not available so the only access as far as I'm aware is via the enumerated SecKey reference. Is there any way to SecKeyCreateWithData a secondary reference to the same underlying (but unexportable!) key but with allowed-usage attributes of my own choosing?

I have two ODRecord objects in Swift, and am trying to see if one is a member of the other. I tried: func myIsMember_attempt1(_ r: ODRecord, ofGroup g: ODRecord) -> Bool? { do { let isM = try g.isMemberRecord(r)     // -> Constant 'isM' inferred to have type '()', which may be unexpected return isM; } catch { print("Error: \(error)") return nil; } } Despite the discussion of "Return value" at https://developer.apple.com/documentation/opendirectory/odrecord/1427975-ismemberrecord it appears the ODRecord.isMemberRecord() function does not return any value!? [I'm guessing due to the idiosyncratic implementation of the underlying BOOL-returning NSError-taking method on the Objective-C side?] So noticing there was also a ODRecordContainsMember function available, I tried: func myIsMember_attempt2(_ r: ODRecord, ofGroup g: ODRecord) -> Bool? { let isM = ODRecordContainsMember(        Unmanaged.passUnretained(g).toOpaque() as! ODRecordRef,        Unmanaged.passUnretained(r).toOpaque() as! ODRecordRef,        nil      )      // -> Treating a forced downcast to 'ODRecordRef' as optional will never produce 'nil' [??https://bugs.swift.org/browse/SR-4209]      // -> crashes when run…! return isM; } so it seems that an ODRecordRef isn't just the raw pointer of an ODRecord? Is there any chance of the ODRecord.isMemberRecord() method getting fixed in Swift? Is there any way to use ODRecordContainsMember from Swift in the meantime?