Hi Quinn,
Thank you for your reply!
After your advice I checked the code signing, and here’s what I found:
With every release of our software, we sign all binaries using the codesign utility, and each binary has static Designated Requirements that don’t change from release to release. Overall, our signing process is the same as everyone else’s, and as far as I know, the original Chromium faces the same update issues https://issues.chromium.org/issues/346505950.
Moreover, Chromium developers made opinion in (https://issues.chromium.org/issues/346505950#comment31) that
this local network permission is associated with the specific Mach-O UUIDs of an application rather than being tied to a code signing identity like most other TCC permissions are on macOS. The network extension subsystem listens for LaunchServices notifications about an application being installed and updates the Mach-O UUIDs it associates with an application's bundle identifier. This means that when LaunchService sees a new version of an application, the local network permission is lost for prior versions of that application, even if they're still running.
In our case, with every Rsync update, a new Contents/Frameworks/Comet Framework.framework/Versions/A.B.C.D folder with the updated version is added, and the main binary changes.
However, the Designated Requirements remain the same.
Here’s an example of how I checked (note the version numbers: 140.0.7339.20465 and 139.0.7258.18212)
find "/Applications/Comet.app" -type f -print0 | xargs -0 file | grep -E 'Mach-O' | awk -F: '!/\(for architecture/ {print $1}' | sort -u | xargs -I {} codesign --display -r - "{}"
https://gist.github.com/poluyanov/78893d8d574694164d7c5d310a1dcafa
It seems that the problem might lie elsewhere, and I may be missing something.
I really appreciate your help with this, Quinn.
Best. IP
