Ok, so it's been a while: I did get it to work! I grepped the codesign commands from the build output, wrote a script that, given two source .app directories, copies one of them to a new bundle, and then runs codesign on each of the bundles (including, at the end, the whole enclosing bundle). I also (cleverly, I think) extract the entitlements using codesign rather than using the ones from the project directory, and apply those. It seems to work!
This is, I think, about the best I can do until and unless uSoft or MacPorts makes progress on their respective tools/environments. This is one of the reasons I always like being an OS engineer, so we don't have to (in general) rely on third party libraries/tools.
Now I got a hankering to write a copyfile class in Swift.
Post not yet marked as solved
I filed a TSI. I suspect that it'll end in an Enhancement Request rather than a solution, alas. I'd love to be wrong. 😄 (And I just filed FB10449617 anyway.)
Post not yet marked as solved
Oh: also, if I can do it anywhere in the OS, that's fine -- I can tell the provider to disable itself for a while, easily enough.
Post not yet marked as solved
Yeah, macOS, using Transparent Proxy Provider.
I tried using network reachability, but that didn't do it, alas.
But that gets back to my original question -- can I just grep the codesign commands from the build output, and do those again after the enfattening? Or do I need something different after that?
Post not yet marked as solved
So... if I do a case sensitive search (without the 'c'), it finds it. Weirdly, even if I ask it to find 'safari'.
What the what?
The way the build works -- and this isn't just us, it's standard with vcpkg and cmake building on macos -- is that you tell vcpkg the packages you need, it deals with all of the dependencis, and builds them. You then have CMakeLists.txt files that specify your targets, and what packages they link with (and, in my case, I ensured they were static libraries).
You then generate a builder (xcodeproj in this case) using CMake; this causes vcpkg to build everything, and then CMake goes and constructs an xcodeproj bundle that has all of the targets you specified, and has all the libraries/header files you said they need as external dependencies used for linking. Then you build, and this basically runs xcodebuild. The end result is the targets signed the way I told it to sign, put into bundles where applicable.
Because vcpkg does not support (yet?) universal binaries, I have to do it twice -- once for arm64, once for x86_64. These are completely separate build environments. So I don't have xcodebuild doing "the final step" -- it's actually building everything except the vcpkg-managed dependencies. And I then have one complete bundle for each architecture.
So what I want to do is then take those two bundles, and somehow merge them together. I assume this has to be done manually (well, scriptedly) using lio, and then signed again using codesign. I had (as stated originally) thought I'd just grep for the codesign commands from the xcodebuild output, and use those to re-sign after my script uses lipo to put everything together. (I do apparently need to also grab the processed entitlements files.)
If there's a way to get Xcode to do this (and this would be a separate xcodeproj bundle, I'm sure), that'd be great. I couldn't find one, since the inputs would be two different bundles.
Does that make my question, problem, and dilemma clearer?
Ha ha! Figured it out. Someone set the stderr and stdout in the plist to be a file in /tmp; the first time it's run, it gets created. With a mode of 0644. This was causing it to not launch.
(I figured this out by pre-creating the file and doing a chmod a+rw on it, then loading the agent via the previously-used launchctl commands. And then when I logged in as the second user, there was the agent, doing its agenty things.)
Ha ha!
If I were in your shoes I’d probably adjust your open source tooling to not do any signing — disable linker signing using -no_adhoc_codesign — then do a final signing step at the end.
The build system is xcodebuild driven by cmake; the only code signing is done at the end, and is done by xcodebuild (for each target of the project, which is a system extension, three app-structured daemons, and the containing app). The problem is that we currently have to do two completely-different builds, one for each architecture, due to the lack of support for universal builds by ... well, anything that isn't Xcode-driven, really. In particular, vcpkg, homebrew, and macports all fail at this in various ways. (And we can't use CocoaPods with cmake, and we can't use Swift Packages.)
Hm. I am also not sure if I notarized it afterwards.
The Apple Silicon and Intel builds are currently signed correctly -- they run on Macs of the appropriate architecture with SIPS enabled. (The various libraries are statically linked, not dynamic.)
But when I try to use lipo to combine them, it worked on my machine -- until I realized that it had SIPS disabled; when I re-enabled it, I start getting error 8. (Remember how I have now begged Apple for a code sign diagnostics tool? 😄)
(Does it matter that it's a single bundle with some contained app / extension bundles, and/or that they have entitlements?)
AH HA! M'ACCUSE!
Don't use modal. Then
self.passwordWindow.level = NSFloatingWindowLevel;
self.passwordWindow.hidesOnDeactivate = NO;
self.passwordWindow.floatingPanel = YES;
did in fact work.
My code is currently:
if (self.pvc == nil) {
self.pvc = [storyboard instantiateControllerWithIdentifier:@"passwordViewController"];
}
if (self.passwordWindow == nil) {
self.pvc.errorLabel.stringValue = @"";
self.passwordWindow = [NSPanel windowWithContentViewController:self.pvc];
}
self.pvc.passwordDelegate = (id<PasswordDelegate>)self;
self.passwordWindow.title = @"Unlock Password";
self.passwordWindow.level = NSFloatingWindowLevel;
self.passwordWindow.canHide = NO;
self.passwordWindow.hidesOnDeactivate = NO;
self.passwordWindow.floatingPanel = YES;
[self.passwordWindow orderWindow:NSWindowAbove relativeTo:0];
[self.passwordWindow makeKeyWindow];
[self.passwordWindow orderFrontRegardless];
self.passwordWindow.collectionBehavior = (
NSWindowCollectionBehaviorCanJoinAllSpaces |
NSWindowCollectionBehaviorTransient |
NSWindowCollectionBehaviorFullScreenAuxiliary
);
[self.pvc reset];
NSModalResponse response = [NSApp runModalForWindow:self.passwordWindow];
which is a mishmash of various things I've been trying, and still no luck. 😩
Oh oh oh oh. I think I see my problem, then: Int(nework_byte_order_short).bigEndian may be what's biting me bigly! Oooh.
I hadn't realized that the capacity was number of designated types, not byte length. Although now I'm surprised it didn't crash there. 😄
I do like your Swiftian consumption model a lot. However, I do think it's okay for me to stick with pointers in C, given my background.
At this point, I think I'm going to stick with the hybrid model (that is, it calls an ObjC class), but I am copying that Swift code and putting it into my Notes.
I rewrote the packet examination code in ObjC, and it works as expected.
I still have no idea what's going on with the Swift code -- the fact that case 0: didn't get caught, but the default: case showed it with a value of 0 just doesn't make any sense to me. 😩
