Hello, Quinn! Thanks a lot for your assist on this. I was struggling a bit with connecting to an AFP server. For some reason, it was rejecting all my connection attempts and no solutions I found online helped me. But I tried connecting to a SMB server and duplicating the file on a remote SMB server and this produces the same copyfile sys call. So it was a success in the end. I also managed to verify that our es_client instance correctly identifies this new event when I duplicate a file on a remote SMB server and handles it accordingly. So looks like it's working as designed. Our biggest worry was that this a somewhat recently added event and as soon as Monterey is dropped, we will be missing events that we need to evaluate. But it does not look that way so far. As far as I can see, the use case for this sys call is pretty narrow, isn't it? Best regards, Arthur

That's great news! We already subscribe to quite a wide range of events from Endpoint Security APIs including ES_EVENT_TYPE_AUTH_CLONE for file clone operations. But we are still planning to add ES_EVENT_TYPE_AUTH_COPYFILE support. But it just means that adding the support is not that critical to have as soon as Monterey is out as we initially thought. Thanks for your help and assistance (as always :) ) Regards, Arthur

a small update. Made a quick test by trying to make a network request to a http address from the daemon side. Got the following error log message: "The resource could not be loaded because the App Transport Security policy requires the use of a secure connection". So it looks like ATS is indeed operational when the daemon is making a network request using URLSession. So the only confusing part was the description of circumstances under which ATS is expected to be enabled.

Huh. That's curious because this is not what's happening according to our testing (my last comment above). This is what I am currently observing when a process that runs in the daemon context tries to perform a POST request to a HTTP address. 2022-03-03 11:51:55.384 E daemonnamed[1467:2af9] [subsystem:category] Error occurred while trying to send data: Error Domain=NSURLErrorDomain Code=-1022 "The resource could not be loaded because the App Transport Security policy requires the use of a secure connection." UserInfo={NSUnderlyingError=0x7ffbadf0ddd0 Unknown macro: {Error Domain=kCFErrorDomainCFNetwork Code=-1022 "(null)"}, NSErrorFailingURLStringKey=http://concealed, NSErrorFailingURLKey=http://concealed, NSLocalizedDescription=The resource could not be loaded because the App Transport Security policy requires the use of a secure connection.} So if I read this message correctly, ATS is restricting it from performing a network request due to an insecure connection. If I restore the URL to its original form (HTTPS), then the request is successful. is the comment about not having ATS protection in daemon context is about it being limited in some other way? So it's not the same as for user apps?

Indeed, this example allows insecure connections which contradicts with our earlier observations. I've made a quick test by setting UserName and GroupName to daemon in the plist. That did not affect the behavior. Insecure connections were still allowed. I have created a feedback about opting in ATS by launchd jobs. Sharing the number for your reference: FB9942862 I will investigate why ATS gets involved in our case. I can think of a few interesting details from the top of my head: our daemon is sandboxed. Could that change the behavior? our daemon binary has an Info.plist embedded into it. Could that make ATS look at it from bundle point of view? it performs POST requests. Could that a reason why ATS gets kicked in?

A small update: It looks better now. 1 out of 20 attempts fails with the issue above. But still not completely stable.

@eskimo, it seems notary service is back in action. Managed to notarize our packages successfully. Thanks for the assist!

@endecotp. Yes, I think you are right. There should be a warning at least. But in my observation, there is no indication at all. So to be more precise, this is what's happening. If I declare such a method in a class added to an Xcode project, - (BOOL)doTheThing { // do not return anything } then I see a warning from Xcode saying that there is no return statement. And this issue is caught by our CI system which has a very strict policy on warnings. If anyone in the team adds even a single warning, then such a change cannot be merged. But if I add the same method to a Swift package which is linked against the same Xcode project, then there is no clang warning in Xcode about it anymore. So now we have a situation that we have no idea how many other cases like that we have in our codebase because we are totally blind to it as Xcode/clang does not indicate any issue at all...

Looks like the issue background script visibility is fixed in the latest releases of Safari Technology Preview. There are other issues identified once we managed to get a proper debugging environment in Safari. Will file separately in Feedback Assistant.

An update on this: Our extension is still under review. It has been over 3 weeks now. Got an update from Developer Support stating that the submission is still under review. To be honest, hard to imagine what you can do with a Safari extension for over 3 weeks review time.. Such cases make it hard to predict when you should expect a CRITICAL update to be delivered to customers..

Thanks! We also managed to confirm that by reading libdispatch source code in apple-oss-distributons repo. My original interest in this topic was slightly different. Originally, I was investigating a bug in our product that was not triggered until very recently. We had an command-line executable running as a launch agent that was preforming some setup and then calling dispatch_main to prevent the process from terminating. The bug was caused by important bit of code that was put below dispatch_main in main.swift. This was the setup roughly. All happening in main.swift without dispatching to any other thread. // 1. setup environment // 2. call dispatch_main // 3. additional setup The problem is that the code was reaching "3. additional setup" areas before recent changes. And it was a big WTF moment of why it suddenly stopped working. Now that I am looking at this code, it makes perfect sense. It should have never reached anything after dispatch_main. Nothing in this original setup in main.swift was touched but it was clearly working for the last 2-3 years until recent changes in the additional setup that revealed the bug. I will try to reproduce it outside of our product and file a feedback. But It was just mind blowing that code that was placed below dispatch_main was getting executed and now out of the sudden stopped. And that led us to the investigation of what dispatch_main actually does underneath :)

Yep. We found the explanation for this behavior just now. This bit from my message before is incorrect. It was never reaching this area at all. [quote='823048022, ArthurValiev, /thread/773371?answerId=823048022#823048022, /profile/ArthurValiev'] The problem is that the code was reaching "3. additional setup" areas before recent changes. [/quote] The code structure was refactored a bit and the code following the intended flow by pure accident :) So this "3. additional setup" area was not necessary for the functionality of the process. But with the recent refactoring, it became a must for process to finish initializing properly. So mystery solved. No issues with dispatch_main. It's business logic of the product that relied on implicit behavior before which was now straightened out. Thanks for being the voice of reason :)

[quote='833602022, Etresoft, /thread/779910?answerId=833602022#833602022, /profile/Etresoft'] Or various command-line looks like pkgutil, codesign, or spctl? [/quote] [quote='833618022, DTS Engineer, /thread/779910?answerId=833618022#833618022'] Stick with installer packages but use pkgutil to check their signature. [/quote] Thanks for the responses! pkgutil was considered but we wanted to avoid parsing of the command line tools output. We are primarily interested in the certificate subject names present in the package signature. The intention is to make sure that we install packages that are not only validly signed or accepted by Gatekeeper, pkgutil. And it looks like one would need to parse the output of command line tools to check if a specific team ID is present. That's definitely doable but we wanted to look into options with proper API that we could call from ObjC/Swift before going to an option with running a command line from code.

[quote='833618022, DTS Engineer, /thread/779910?answerId=833618022#833618022'] [1] For new applications we recommend the Apple Archive framework, which comes with its own archive format. I talk about that more in Unpacking Apple Archives. [/quote] The Apple Archive option is curious. We haven't dealt with it much before. I will need to read about it to understand if it fits our use case. One of the reasons why Installer pkg format was selected is because it's the same payload that is downloaded when the user starts using the product for the first time as an update that we publish in our update system which gets installed in the background using installer command. Installer package contains signature information that we can validate before starting the installation. So if Apple Archive allows us to achieve similar outcome, then it's definitely something to try out.

[quote='833855022, DTS Engineer, /thread/779910?answerId=833855022#833855022'] Oh, and you should probably file an enhancement request for a non-deprecated way to verify installer signatures. If you do, please post your bug number, just for the record. [/quote] Yes. I posted a similar question in FB17148233. Added a summary of our discussion as a comment to it with an ask to provide a non-deprecated API now. Thanks!