Changing the line to std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> > x; results in the same behaviour.

Because the more-c++-capable coworkers weren't able to give me a terribly small example, so I just used the pretty version of the undefined symbol. As I said, it works if I compile it on macOS 11 and run it on 11 and later, but if I compile it on macOS 12, it won't run on macOS 11. And I find this confusing.

Note that C++ is far far far from my strong suit, I'm just trying to figure out why our application no longer works on macOS 11 just because we started building it on macOS 12.

Ok, filed FB11970214.

But still doesn't work on CircleCI despite using macOS 12. sigh.

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 ;).