Yes I discovered the problem with not being able to delete certificates the hard way. This is an epic failure on Apple's part, I still maintain. As is the inability to identify them in the portal. However: I created a request using Certificate Assistant; I uploaded it into the portal; I downloaded the certificate, and opened it via Finder. And it was unable to import it. I tried importing it on another machine. I think I was able to import it into the System keychain, which is not a good idea at all, but then it didn't have a matching key. I followed the instructions. It failed badly. I have no idea what to do next. Xcode revoked a bunch of certificates, it claims, but I have no idea which ones, and now I cannot build.

sigh. It ate my reply. Having horrible success with Apple today :(. Trying to rewrite it from memory: I can load the extension. I have another network extension in the app -- a transparent proxy provider, while this new one is a content filter provider. I can save the preferences for the TPP, but when I try to save it for the packet filter extension, I get permission denied (error 10). The application is in /Applications (thus allowing both extensions to load). Quinn's debug post does not cover that issue. I had a test program that worked, but after the issues (described elsewhere today) with my Developer ID Application certificate, I can't build it at all anymore. And Xcode keeps revoking my certificate because the private key isn't in a keychain, which does nothing, so it keeps trying to do that, and I can't get it back to building. sob

And I tried it again, and once again am hit by the fact that I can't delete a certificate once it's been created, so now I have two that are indistinguishable, and neither of the works. 😭

I will have to try that! That would simplify things greatly!

Found it -- DerivedFile directory was set to the same for both.

Ok, back to adding a second network extension I guess. (First one being a Transparent Proxy Provider, as oft mentioned. I know I can in fact put a packet filter into the same executable [although I have no idea if that's supported], but the management got annoyingly complicated.)

I asked here because we want to block a single udp port while our app is running, which means making a packet filter extension seems overkill. But I'm thinking that we may not have a lot of choice.

Wellllllll I fired up the Sonoma VM (which is some 5000 miles away from me), and it works there, therefore this seems to be a bug in macOS 13.

I did eventually get it working, but it's annoying. The sort is an @State 'cause I am playing around and experimenting, which is why this particular failure was frustrating.

It seemed so wrong to me that I wrote a test application, and FB13152737 with it attached.

That makes sense, but it also seems to make it difficult to tell where in a trace memory is being allocated -- we're trying to figure out why our memory footprint goes up by a lot in some cases, and this behaviour doesn't make Instruments particularly helpful in that regard, no?

And now, during automated tests, we're apparently not getting prompted to install a new root CA. Sometimes. This is being done via Installer/installer, and a post-install script that uses the security command to install the root CA as trusted. We're installing using /usr/bin/security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ${APP_SUPPORT_PATH}/root.crt and /usr/bin/security remove-trusted-cert -d ${APP_SUPPORT_PATH}/root.crt to remove it.

Ok, I created FB12959624 with the trace bundle attached.

Oh, that's very nice. What we ended up doing was to build twice -- once for x86_64 and once for arm64. After both builds finish, I then have a script go through the set of executables I expect, and use lipo and codesign to create a universal bundle.

I was so tired this weekend that I couldn't go into that; I know it's possible (using it at work for a couple of daemons), but I just couldn't think. 😄 I was trying to make a little CLI utility that could look at the data a SwiftUI app dealt with.