Hello Quinn, We wanted to followup on this topic of broken Local Network security access on macOS. This issue has been open on our side for a while and we're just starting to escalate it now. We haven't setup a VM yet. This issue reproduces 100%, immediately on new machines. We are aware of at least 10 systems that this reproduces on, including new systems and old systems. (100% of systems are broken) A fresh install is not necessary, and actually if someone were to have to install a fresh OS in order to use our software, that's unworkable too. Our existing working software simply broke in that macOS upgrade. We only have a single algorithm style for network communication, we haven't deployed experiments that might break the detection. We get this complaint regularly from Apple employees who use our products. We were hoping one of them would be able to get this fixed but they move on after launching via Terminal. On to the technical side: There may be two issues here. Our application sends a UDP broadcast successfully. Our device sends back a UDP response, which makes it back into our app. The response is corrupted though, so we don't get the full picture of the device state in order to proceed to the next step. This seems very broken. We shouldn't be able to send a message without authorization, and the popup never comes. How do we get this addressed? We can give you a link to our app and you can try it, it will send the message on your Ethernet connection. Thanks

Our engineers have thoroughly followed the practices outlined in TN3179. The apps have been tested on a variety of test systems (including clean installs) in our test lab. As the issue has also been reported by many end-user customers, we are confident that the behaviour is reproducible across all systems and test environments/setups. We can affirm that it is not specific to one system and its corrupted local network privacy state.

Hi @eskimo , The posted code is only an example to illustrate the behavior. We are not writing code like this by hand. These low-level binary structures come from a compiler in our toolchain. Clang generates structures that are identical to "Hello" through the built-in function _builtin__CFStringMakeConstantString(), referenced from the CFSTR() macro. The CFString structure must be a stable ABI since compiled binaries are compatible with any version of CoreFoundation. Since macOS versions prior to Sonoma accepted a 0 value in the isa field, we had no indication that the structure was different than Clang's output. We have resolved this and will be releasing updated software. Thanks again for your help in identifying the issue.

Hi @eskimo, Thank you for your time and elaboration on this ticket. Your investigations have helped us move forward. The shared cfstring_isa.c code (below) shows the working and crashing behavior on both x86_64 and ARM64. We are working on applying the updates suggested to our UI code, to make them compatible with Sonoma. Once again a big thanks for all the effort put in from your end. // // Compile with: // // clang --target=x86_64-darwin-macos11 -o cfstring_isa_x86 cfstring_isa.c -framework CoreFoundation // clang --target=arm64-darwin-macos11 -o cfstring_isa_arm cfstring_isa.c -framework CoreFoundation // #include <stdint.h> #include <stdio.h> #include <CoreFoundation/CFString.h> struct ConstString { void *isa; int32_t value; int32_t unused; char *asciiz; size_t length; } __attribute__((packed)); void ClassReference() asm("___CFConstantStringClassReference"); const struct ConstString Hello = { .isa = ClassReference, .value = 1992, .unused = 0, .asciiz = "Hello", .length = 5, }; const struct ConstString World = { .isa = 0, .value = 1992, .unused = 0, .asciiz = "World", .length = 5, }; int main (int argc, char *argv[]) { CFStringRef hello = (void *)&Hello; CFStringRef world = (void *)&World; printf("Works on Sonoma:\n"); printf("%s\n", CFStringGetCStringPtr(hello, kCFStringEncodingMacRoman)); printf("\n"); printf("Works on Ventura, crashes on Sonoma:\n"); printf("%s\n", CFStringGetCStringPtr(world, kCFStringEncodingMacRoman)); printf("\n"); return 0; }

Updated thread with corrected tags is at: https://developer.apple.com/forums/thread/739355

The info has also bee uploaded via macOS Feedback Assistant with ref Case ID FB13260830

Updated thread with corrected tags is at: https://developer.apple.com/forums/thread/739355