Per-app VPN issues with apps update

There is a mechanism which updates SomeOtherBundle.app with ServiceApplication.app periodically. After some research, I found, that the reason for this is the system is not aware of the new version of ServiceApplication.app binary

What is the mechanism that updates SomeOtherBundle.app periodically? After update, if you cycle your per-App VPN does this help the situation any? If not, are there any logs that can point some more light on this situation?

The mechanism is just a background daemon that checks if there is any update present on some server, and if it is, installs it from the .pkg in silent mode. The pkg places the new SomeOtherBundle.app in the temporary folder first, like "update" subfolder on the same level with an old SomeOtherBundle.app, then in the post-install script it calls rm on old SomeOtherBundle.app and perform a mv of a new SomeOtherBundle.app to the target location from "update" subfolder.

What is the cycling of per-App VPN?

If it means to turn off and on, then I would say it does not help: the update happens only while per-app vpn is in deactivated state, and after the update completed I turn it on (activate).

The possibly important notice on how I turn it on and off: I'm adding the rule for ServiceApplication.app on a first start of my per-app VPN, then activating the tunnel; when it comes to turning the tunnel off, I just deactivating it, without removing the apprule for ServiceApplication.app - so when I activate it again later, the rule for ServiceApplication.app will be already there. This seems to be ok for me, because the API for Apprule uses only stable parameters: bundle id and designated requirement, however I could be wrong here.

If the cycling means the removing of an Apprule for ServiceApplication.app and adding it again, or the removing and readding the whole tunnel configuration - I have not tried this yet. Generally, it will require my per-app VPN app to monitor the state of some other bundles on the filesystem, which is possible to implement, however I hoped that system will do it for me, as I have an API interface with just a bundle id and signature parameter.

What is the cycling of per-App VPN?

I did mean to deactivate the tunnel, reconfigure it, and then activate it again with the newly installed app.

Regarding:

I'm adding the rule for ServiceApplication.app on a first start of my per-app VPN, then activating the tunnel; when it comes to turning the tunnel off, I just deactivating it, without removing the apprule for ServiceApplication.app - so when I activate it again later, the rule for ServiceApplication.app will be already there. This seems to be ok for me, because the API for Apprule uses only stable parameters: bundle id and designated requirement

I'm assuming you mean an NEAppRule here with the designated requirement? If I understand you statement above correctly, do you still contain the signature information for the old app that was removed?

Well, I do deactivate it and activate it again, however I don't get what I should reconfigure.

The NEAppRule, which I indeed referenced, contains two fields: signingIdentifier (which is bundle id) and designated requirement. You are saying, I'm still have the "signature information" for the old app that was removed, but neither the bundle id nor the designated requirement has been changed, as this is the same bundle, with the same bundle id, the same certificate used to sign it, just the new version.

Maybe I got something wrong about it: I'm checking the designated requirement of the bundle using the

codesign -d -r- <code-path>

command.

The output for every single version of ServiceApplication.app is always the same, it looks like this:

identifier "com.bundle.id" and anchor apple generic and certificate number[some.numbers] /* exists */ and certificate leaf[numbers.more.numbers] /* exists */ and certificate leaf[subject.OU] = teamId

This stays the same for all versions, just as bundle id, and I don't see how any part of this could or should change with the update to new app version.

Am I using the wrong designated requirement? Why is this even work, if it is not the correct DR to use?

Am I using the wrong designated requirement?

No, it looks like you are using the correct version of the Designated Requirement.

Going back to:

The mechanism is just a background daemon that checks if there is any update present on some server, and if it is, installs it from the .pkg in silent mode.

I am trying to narrow down which part of the update and registration process might be causing you problems here. Based on your description above this sounds like a custom update process and not something that is done with MDM. Either way it would be good to open a bug report at this point so this can evaluated further. Please make sure to include a sysdiagnose with the exact time and date the issue took place.