As always, thanks @eskimo and please pass my thanks along to JohnM, whom I don't think I know.

An update: this is fixed. While going through and collecting information for the TSI, I went through Keychain Access looking at all my Development certificates. And this time, it said they were all revoked! It did not say this before, and security said I had a bunch of them. So what the heckfire? However! I am able to build for development locally, which was the sob-inducing problem, so I can relax. And build again. Now to figure out how to get the Developer ID one working.

I have now filed a TSI request, because I am at my wit's end.

Well unfortunately that makes sense, so now I'm back to frustrated sobbing. It's still giving me this: I started logging everything, then launched Xcode. I have this log message which may be important? 2023-11-15 10:12:20.099861+0000 0xe0958 Debug 0x1ab38b 409 0 trustd: [com.apple.securityd:reject] non ev score: 111 lower than 1107 <SecCertificatePathVC certs: <cert(0x7f973b00a400) s: Software Signing i: Apple Code Signing Certification Authority> >

Unfortunately, fixing that doesn't fix the problem: Valid identities only 1) 769F003C52AC6942DAF0C5240B3824199F039C1E "Apple Development: Sean Fagan (8S9ZGBEAV3)" 2) 227FA0FB4088D4DD3984EF98D12C8EBB2E28A5D1 "Developer ID Application: Sean Fagan (7C43638LX4)" 3) B07B2C2AB9482E41ACE9868C1E74218AA7027FEA "Apple Development: Sean Fagan (8S9ZGBEAV3)" 4) A4A8B5E37FC91C456E8333DB2ADB32FF1C225536 "Developer ID Application: Sean Fagan (7C43638LX4)" 5) 7B1DE3A19E5EC6B80A8A07AA57887E446BF512C5 "Apple Development: Sean Fagan (8S9ZGBEAV3)" 6) C93D0A9C57506C93B7D5A20925E40E5FD035C09D "Apple Development: Sean Fagan (8S9ZGBEAV3)" 7) B5C7997E7231AB5AF3E86F84D42FA72B60501B13 "Apple Development: Sean Fagan (8S9ZGBEAV3)" (CSSMERR_TP_CERT_REVOKED) 8) 2BDFA67CFF67D25E8CED067446F5D1B6E89CD60B "Apple Development: Sean Fagan (8S9ZGBEAV3)" 8 valid identities found The developer ID seems to be wrong, however? I don't know why it's 8S9ZGBEAV3 for most of them, and 7C43638LX4 for the Developer ID Application ones.

Welp, this certainly looks like a problem: sef% security find-identity -p codesigning Policy: Code Signing Matching identities 0 identities found Valid identities only 0 valid identities found

So I did all that, got the certificate from my backed up login keychain, and... once imported, Keychain Access tells me it's been revoked. The web portal does not say so. And I still have no idea how to get Xcode-managed signing working.

Do you have an independent backup of your Developer ID signing identity? I should. I have an entry in 1Password that has the passcode and the .p12 file. And for the one I created yesterday, as I said, I used openssl specifically so that I would have everything it generated, and I stashed that in a tarball and attached it to the same 1Password note. Your article doesn't tell me how to deal with the fact that I can't build anything -- Xcode revokes my certificate but does not create a new one, or if it does it can't find it.

I am now in this state and I am beyond frustrated.

No, doing it from a UI app, as an agent, which is the containing app in /Applications. So... yes, still having issues. 😄 ETA: I am sure it is my code that's doing something wrong, but I can't figure out what. Before we had two extensions, the flow was: app startup -> activate system extension -> load preferences -> find manager -> load preferences from manager -> set isEnabled to YES -> save preferences. The new flow is largely the same, except that I'm also using notifications to tell when the configuration changes, because trying to do both extensions at the same time fails with permission denied; this means that when one of the extensions is activated and enabled, it sets a property which then checks the other one's state, and if it hasn't been set to YES then it starts that process. So, clearly (to me, anyway) that's where it's happening. But what I don't understand is why.

I tracked this one down too -- and filed a FB for it. After filing a TSI. The issue seems to be that, for whatever reason, if they are both trying to access the preferences (the VPN manager and the filter manager), it fails. I changed my code to in addition, listen for notifications about changes to the VPN and filter, and when one completed, try the other one if it hadn't been enabled yet.

I eventually tracked this down: one of my @Models had a (Codable) enum in it. I removed that, and it didn't crash. (I may have had to also reset everything programmatically? I forget.)

I wasn't, but I changed it to match what was in the entitlements file, and it still segfaults the same way at the same place.

My current implementation seems to deal with this -- if I get an error during the save preferences, I use dispatch_after for 1 second, and try again.

In practice, I was using completion to do the context.save() so I can deal with workarounds. But it... seems to totally defeat the purpose of @Bindable and requiring a context.save() if you can't get back to an earlier state.