Well. I updated a laptop to macOS 12, and Keychain Utility doesn't complain when I evaluate the certificate.

security tells me 4 valid identities found. Trying to sign: % codesign -s 'myidentifier' -f /tmp/mytrue /tmp/mytrue: errSecInternalComponent so it doesn't match. When I run the build on CircleCI, then codesign says it's a self-signed root and it refuses to do. When I look at the certificate in Keychain Utility, and evaluate it, on one machine it says it's fine, on another it says it's missing a root. I have compared the fingerprints of each of the intermediate certificates on the good machine to the certificates that are in the keychain on the machines that don't work, and those match. NB, I create a separate keychain for the certificates:

No ideas from anyone? I filed FB11963917 as a result. :(

My signing certificates do not have roots. On another machine, they do. I have no idea what's different between them.

As usual, Quinn was immensely helpful in the TSI (and, I assume, various other engineers -- please thank them for me, especially if I know them 😄), and determined the root cause: a flow could not have more than 128k of data pre-macOS 12.3. This doesn't seem to have been documented, and instead of returning an error in the .write method, it closed the file descriptor. ooops. In 12.3 and later, it breaks the data into chunks to keep it working; I had, based on Quinn's analysis, added code to do the same (but at 48k chunks, since I didn't know what the limit was at that point). (And I just changed the code to use #available(macos 12.3, *) to set the limit, and it's going through QA now.)

I apparently typed too soon, and something is wrong -- I can build, but circleci can't, and I have no idea what I'm missing. Probably a root or immediate certificate, but I'm not sure how to tell. sigh.

I did eventually find the private keys. This took me several hours yesterday, because they were on different machines and accounts. (The problem I ran into was that it needed to go into the login keychain -- but several of my machines have project-specific keychains, so I can test behaviour when the certificates or passwords aren't there.) I just filed FB11939267, begging for a way to at least identify them on the web portal.

Ah ha! 😄

The problem with that is that the extension is written in Swift is a network system extension doesn't close anything other than flows using the close*WithError methods has no idea what the flow divert file descriptor is I can tell, using lsof, that the last one is fd 5, but that is all I can tell. Unless I missed something, there is no way to tell, in the network system extension, which file descriptor is the control one, since all of the communication is done via methods.

FB11837553 -- the analysis (which, now that I know what to look for, makes sense) was that, for some reason, my extension does not have the com.apple.flow-divert socket(?) open, which of course would make it difficult for it to do any network proxying, transparent or otherwise ;).

I filed FB11861011 just now.

I at this time only care about macOS. 😄 How can you stream using OSLog though? (Specifically, during diagnostics generation, I want to grab the log stream --info --debug --predicate 'subsystem == "us"' equivalent for a few seconds.) Using the enumerator seems to give me up to a point in time, but then it ends. There is OSLogEntryActivity but I'm not sure that's the right thing. And I can't find any examples of it.

The reason I was using LIKE is because I couldn't do a case-insensitive query without. I still can't, despite the documenation. For example, it uses kMDItemAuthors ==[c] "Steve" and just below that explains that the [c] means it is case-insensitive. And yet: sef% mdfind 'kMDItemDisplayName == "Safari"' /Applications/Safari.app /Users/Shared/Previously Relocated Items 1/Security/System/Library/AssetsV2/com_apple_MobileAsset_MacSoftwareUpdate/f7b05c91052116c046919f72de2c03a86cabcf3e.asset/AssetData/payloadv2/ecc_data/System/Library/Templates/Data/Applications/Safari.app /Library/Application Support/Apple/Safari /Library/Apple/System/Library/Assistant/Plugins/Safari.assistantBundle/Contents/MacOS/Safari /Users/Shared/Previously Relocated Items/Security/Developer/SDKs/MacOSX10.6.sdk/System/Library/PrivateFrameworks/Safari.framework/Versions/A/Safari /Users/Shared/Previously Relocated Items/Security/Developer/SDKs/MacOSX10.7.sdk/System/Library/PrivateFrameworks/Safari.framework/Versions/A/Safari /Users/sef/Library/Application Support/SyncService/LastSync Data/Safari sef% mdfind 'kMDItemDisplayName ==[c] "Safari"' sef%  (Also, I thought that LIKE used the SQL wildcards.)

I thought of that, but I don't think that's going to be it -- the launchd.plist file for it sets the number of file descriptors to a million or so, and there's no messages about descriptors. More worryingly, though, the extension stops getting any network flows. While in this state, I had the engineer do printf foo | nc 127.0.0.1 88, returned immediately with a 0 exit status. And no logs in the extension.

Yay thank you Apple! I filed a new request last week or so, making it clear we needed the distributable one, not just the development one, and got the email today, and confirmed that it's there with the development certificate! Yay yay yay!