[quote='872674022, ArthurValiev, /thread/810932?answerId=872674022#872674022, /profile/ArthurValiev'] My thinking now is what if there is a specific action that I do on the original VM that makes it behave as expected? Like opening Sytem Profiler to read that UDID. Does provisioning UDID get generated when the system boots or at the first time it's needed or requested? That might explain the weirdness in the behavior that we stumbled upon by accident. [/quote] Veeery curious. I see confirmation to my claim above. So, I have two use cases. 1st works as expected, 2nd one generates a new UDID one each clone. 1st use case: Create "VM 1" from an IPSW file. Create a macOS user account. Click Apple logo. Select "About my Mac". Click "More Info...". Scroll down in the newly opened window and click "System Report..." Shut down the machine. Make a new clone by copying all files from "VM 1" and create "VM 2". Boot "VM 2". Compare UDID from "VM 1" and "VM 2". They match. 2nd use case is the same as 1st use case but skipping steps 2-6: Create "VM 1" from an IPSW file. Create a macOS user account. Click Apple logo. Select "About my Mac". Click "More Info...". Scroll down in the newly opened window and click "System Report..." Shut down the machine. Make a new clone by copying all files from "VM 1" and create "VM 2". Boot "VM 2". Compare UDID from "VM 1" and "VM 2". They DO NOT match. That makes me think that UDID is generated in a lazy way meaning it's generated the first time it's needed. So one workaround to the issue would be to open "System Information" once in the template VM. But it doesn't sound to me like a future proof approach. This implicitly relies on the system to behave in a specific fashion here. So then the question would be what the preferred way is to make sure macOS generates the provisioning UDID when needed?

[quote='871885022, DTS Engineer, /thread/810932?answerId=871885022#871885022'] Shut it down cleanly. [/quote] That's a curious detail. I've just been experimenting with that now to see if that was the missing step from the time when I could see an issue with UDID not getting preserved. But even if I skip it now, it works as expected. This is what I tried just now in hope to clarify my understanding of the situation. Create a new VM in UTM app from a freshly downloaded IPSW file. Set it up and create a new macOS account in the VM. Write down the UDID. Shut it down by force from UTM user interface. Create a new clone. Boot it up. Compare the UDID. UDIDs from original VM and clone ones are the same as well. One thought that crossed my mind just now. Do you happen to know or rather could you share at which point the provisioning UDID gets generated? My thinking now is what if there is a specific action that I do on the original VM that makes it behave as expected? Like opening Sytem Profiler to read that UDID. Does provisioning UDID get generated when the system boots or at the first time it's needed or requested? That might explain the weirdness in the behavior that we stumbled upon by accident.

We are using an open-source project called UTM (https://github.com/utmapp/UTM) for managing our virtual machine infra. The way how cloning works in our current workflow is by taking an existing visual machine (a UTM bundle file) and copying it with cp command and updating the metadata to avoid clashes with existing virtual machines like so cp -cR "$template_file" "$clone_file" xmlstarlet ed --inplace -u '//key[.="Name"]/following-sibling::string[1]' -v "$clone_name" "${clone_file}/config.plist" xmlstarlet ed --inplace -u '//key[.="MacAddress"]/following-sibling::string[1]' -v "$new_mac_address" "${clone_file}/config.plist" After that, the newly copied virtual machine file is opened with UTM app with open command open -a "UTM" "$clone_file" It appears in the list of registered virtual machines and it's booted up. So I suspect that the UTM app is just opening the virtual machine and treating it as a separate entity. However, this approach allowed us to preserve provisioning UDID so far. There is one curious detail that we noticed a few days ago. We tried to reproduce the behavior where provisioning UDID was not getting preserved when following the steps above. However, it now behaves as expected and preserves the provisioning UDID with the same steps as before. We did not manage to pinpoint what exactly causes the difference in behavior now. Previously, we were able to observe the unexpected behavior on 3 different hosts. We'll keep monitoring and will see if we manage to stumble upon the issue again. So probably at the moment the main question would be about the recommended way to clone a virtual machine and preserve provisioning UDID? What to look out for and make sure we use appropriate approach to be aligned with the expectations of the Virtualization framework? I hope the expectation of preserving of the provisioning UDID when cloning a virtual machine is valid on our side.

[quote='834103022, DTS Engineer, /thread/779910?answerId=834103022#834103022'] file an enhancement request for an API that directly supports what you need [/quote] Filed FB17188856 specifically for providing an API to validate Installer package (.pkg) signature. Linked the original one FB17148233 with a question about xar APIs for reference.

[quote='834103022, DTS Engineer, /thread/779910?answerId=834103022#834103022'] Honestly though, this starting to get really ugly. [/quote] Yeah. I agree. I definitely wouldn't want to complicate the approach even further. We have already managed to shoot ourselves in the foot with requiring trust for each certificate in the chain. So right now we have a situation where Gatekeeper successfully evaluates a package signature validity but our code treats it as invalid. That's why I was considering to delegate the trust verdict decision to Gatekeeper and get team ID from xar APIs to use as an extra requirement without manual evaluation of trust on our side. So with that in mind, using spctl for checking signature validity and extracting specific fields from the certificate chain seems a more proper solution. I'll look into xar options. But definitely won't continue with that if it turns out needing a private API. I would want to decrease the number of cases where we have that and not increase :) Thanks!

[quote='833855022, DTS Engineer, /thread/779910?answerId=833855022#833855022'] Note that the --raw option gives you machine readable output, which is a step up from pkgutil. [/quote] The raw output in spctl sounds interesting. Thanks for pointing it out. We will look into it. Our current dilemma why we also considered relying on spctl is because xar API returns us subject names as strings. I haven't seen yet a way to distinguish between subjects specific to Apple vs. company specific certificates. So when we extract information from a Developer ID Installer certificate, it gives an array like this ["", "G2", "Apple Certification Authority"] This is the result of using xar_signature_get_x509certificate_data API and then passing the data to SecCertificateCopyValues API to extract kSecOIDX509V1SubjectName field We would like to make sure that the signature contains only authorized team IDs to prevent cases where unexpected team IDs are present in addition to the expected one. The problem that sparked this discussion was the fact that the certificate that corresponds to "", the actual Developer ID Installer certificate, is not trusted by a clean system. The certificates higher in the chain are trusted. Those with subject names "G2" and "Apple Certification Authority". So we cannot put a requirement for Developer ID Installer to be passing SecTrustEvaluateWithError check. That is why spctl command was considered as a replacement to xar. In a way, spctl covers both bits on the validation that we are interested in. It can check that Gatekeeper accepts the package and it provides the teamID information.

[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!

[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='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.

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 :)

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 :)

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

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.

@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...

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