Cannot register Tart VMs as developer device to provisioning profile

[s6eskand]

Hello,

I am trying to build a macos app from src on a tart VM running macOS sequoia, and in order to be able to, the provisioning profile needs to have the device (tart VM) included. The device ID here is the mac UDID except I am getting the following error when attempting the register the device

{
  "errors" : [ {
    "id" : "<id>",
    "status" : "409",
    "code" : "ENTITY_ERROR.ATTRIBUTE.INVALID",
    "title" : "An attribute in the provided entity has invalid value",
    "detail" : "An invalid value '<tart_vm_udid>' was provided for the parameter 'udid'."
  } ]
}

The request was made via the fastlane register_devices lane.

I'm trying to understand if this is a limitation by Apple, or if there is any known workaround.

[fkorotkov]

409 status indicates there is some kind of conflict. Can you try to tart set --random-serial <tart_vm_name> before running you VM to make sure UDID is unique.

[s6eskand]

The issue persists even with a random serial set

[fkorotkov]

Then the other option might be that in order to use Apple ID on Sequoia devices VMs must be built from *.ipsw on a Sequoia device. Right now our images are still built on a Sonoma host due to some networking issues happening in Sequoia which blocks us from upgrading our infrastructure.

Which images are you using?

[s6eskand]

I was using the tart sequoia 15.1 images. I have a suspicion this is because Apple does not recognize the random UDID that tart provides in the VM, whereas the UDID of an actual mac would be verifiable, especially since you can change the UDID of the vm using tart set <vm_name> --random-serial so it's possible this isn't possible at the moment.

My workaround for right now has been to build apps with the developer_id profile since that doesn't require a registered device. More info on that here if you're curious

[CodeStage]

For signing macOS apps this is really annoying, because we have to register a new device ID for every new VM image we create. And there is a limit of 100.

I want to make a suggestion. I saw this MR which added the --random-serial set command.

Why not allow advanced users to pass the device ID they want to use? The VZMacMachineIdentifier type has an initializer with Data so it should be possible in exactly the same way as with the random identifier.

Has this been discussed before? I don't want to maintain a Tart fork, but I would be willing to create a MR for it if there is a chance for it to get accepted.

[fkorotkov]

#59 is not possible at the moment. You want to create VMs from an *.ipsw with a predictable device ID, right?

[CodeStage]

No actually it's more about the device ID not changing when deploying new versions of a image. As far as I understand you can't just chose arbitrary device IDs because we don't know how VZMacMachineIdentifier works exactly.

The documentation says "When serializing the VM to disk, you can preserve the identifier in a binary representation by serializing the data in the VZMacMachineIdentifier.dataRepresentation property. Conversely, you can recreate the identifier with init(dataRepresentation:) from the binary representation."

And I thought if we can just take a valid binary representation, for example when the image is first created, persist it, use it the next time we generate a new version of the image. That would ensure the device ID never changes.

[edigaryev]

No actually it's more about the device ID not changing when deploying new versions of a image

1. Does it change when you run tart set --random-serial?

2. Where do you observe the device ID?

[CodeStage]

Yes it changes, which confirms assumption about how code signing works. I don't know what exactly is going on, but after running tart set --random-serial xcodebuild will fail with the error message that the provisioning profile does not include the device and it shows the new machine identifier. Adding this new machine identifier to the developer portal fixes the issue for this image.

From playing around I can tell that you are already persisting this serial / machine identifier in some way, because merely creating a new image on the same machine will not create a new serial. In other words, every image created on the same machine always has the same serial, unless tart set --random-serial is run.

Therefore my conclusion is that our issue stems from the fact that we are using a pool of several machines to create these images, and if a new machine is added to this pool, the images created on it will have a new serial.

Which is not as bad as I thought initially, where I said the serial changes for every new image. This is not true, the serial only changes if the new image is build on a new machine.

[CodeStage]

To the original poster: I was not using fastlane to add the machine identifiers, but I am using match to generate provisioning profiles. So generally speaking there is no issue with Tart VMs and code signing. Maybe you just sent the wrong machine identifier? Where did you get your argument tart_vm_udid from? I'm taking it from the xcodebuild output...

[s6eskand]

To the original poster: I was not using fastlane to add the machine identifiers, but I am using match to generate provisioning profiles. So generally speaking there is no issue with Tart VMs and code signing. Maybe you just sent the wrong machine identifier? Where did you get your argument tart_vm_udid from? I'm taking it from the xcodebuild output...

The issue here isn't code signing itself but code signing an app using a specific provisioning profile. The app I'm trying to build uses an iOS App Development profile, in order to build on any device using a Development profile you must register the device to the profile which returns the error I originally sent.

The tart_vm_udid is just the mac UDID (from the VM), grabbed by running:

system_profiler SPHardwareDataType | awk '/Provisioning UDID/ { print $3 }'

or by just checking System Information

[edigaryev]

I am trying to build a macos app from src on a tart VM running macOS sequoia

1. Are you using a macOS Sequoia VM that was built on your machine, or somewhere else?

   This could be related to No able to sign in with Apple ID #722 and Error with new sequoia image #883 (comment).

2. Have you tried using the latest IPSW? For example, Sequoia 15.2 beta 3 or newer.

[s6eskand]

Are you using a macOS Sequoia VM that was built on your machine, or somewhere else?

I'm using a VM, not built on my machine, from the latest IPSW at the time (15.1). How would I build on my machine? Just found the cirruslabs packer templates. I can try that out and see if it fixes the error

Have you tried using the latest IPSW? For example, Sequoia 15.2 beta 3 or newer.

I haven't tried anything newer than 15.1

[s6eskand]

tried building locally and it did not resolve the issue, I believe because the hardware identifier is originally set from the restore generated and distributed by apple. If there is a way to generate the ipsw from my own mac then I think the issue may be resolved, but I can't find any information about this online.

Looking through the virtualization docs also confirms this as the hardware model settings come from the restore itself.