Code Signing change to the macOS Application.

[paul-cossey]

Before you start Please open an issue only if you suspect there is a bug or any problem with GNS3. Go to https://gns3.com/community for any other questions or for requesting help with GNS3.

You may also post this issue directly on the GNS3 server repository if you know the bug comes from the server: https://github.com/GNS3/gns3-server/issues/new

Describe the bug The identifier in the code signing on the macOS App has changed on the latest release.

Old: identifier "net.gns3" New: identifier "gns3-55554944975e7584157e3e77a8ed78863ff9f8c5"

Is this expected? Or a mistake?

If this is expected, the new identifier looks like a UUID, will this change with subsiquent releases?

GNS3 version and operating system (please complete the following information):

• OS: macOS
• GNS3 version 2.2.48

To Reproduce Steps to reproduce the behavior: /usr/bin/codesign -d --deep --verbose=2 -r- /Path/To/GNS3.app and compare the certificates

Screenshots or videos N/A

Additional context As part of our security checks we automatically check the code certificate on download for any changes before we can install on client computers.

[grossmj]

Is this expected? Or a mistake?

No, this is not intentional. In version 2.2.48, we have switched to building the GNS3 app on Apple Silicon with xcode 14.2.0.

This may also be because we use notarytool instead of altool to sign the app. notarytool doesn't take an identifier anymore however it looks like this value wasn't used anyway:

https://developer.apple.com/documentation/technotes/tn3147-migrating-to-the-latest-notarization-tool#Submit-a-file

There’s no replacement for the --primary-bundle-id option. The notary service never interpreted that value; it was effectively a comment.

I am going to check if the identifier can be provided to codesign or why the default behavior has changed.

[grossmj]

Providing the identifier as a parameter to codesign worked. Would you like us to release new binary with the net.gns3 identifier?

[paul-cossey]

Holy smokes that was quick!

Yes please, @grossmj that would be amazing

[grossmj]

I am considering changing our identifier to "com.gns3.appname", would this cause any issue on your end?

[paul-cossey]

No issues for me.

com.gns3.appname would actually be perefered and more in line with current standards than the old net.gns3

[grossmj]

I have uploaded a new app with the updated identifier: https://github.com/GNS3/gns3-gui/releases/download/v2.2.48/GNS3-2.2.48.dmg

[admdly]

Is this expected? Or a mistake?

No, this is not intentional. In version 2.2.48, we have switched to building the GNS3 app on Apple Silicon with xcode 14.2.0.

Somewhat related - are Intel builds no longer provided? The latest version appears to be Apple Silicon only (not Universal), and there is no link to an Intel build anywhere.

[grossmj]

Somewhat related - are Intel builds no longer provided? The latest version appears to be Apple Silicon only (not Universal), and there is no link to an Intel build anywhere.

We have built for Apple Silicon only (because the platform we use to make the builds, CircleCI, has deprecated macOS Intel instances).

We can try to create a Universal build if we have enough requests, however this is quite challenging to do...

[admdly]

Somewhat related - are Intel builds no longer provided? The latest version appears to be Apple Silicon only (not Universal), and there is no link to an Intel build anywhere.

We have built for Apple Silicon only (because the platform we use to make the builds, CircleCI, has deprecated macOS Intel instances).

We can try to create a Universal build if we have enough requests, however this is quite challenging to do...

Thanks for the quick response. I understand the difficulty in creating a Universal build and I wouldn't expect you to do so without appropriate demand.

However, I would highlight that Intel builds are no longer provided as it's not clear beyond the app being unable to be executed after downloading the disk image, particularly when upgrading.

[core-code]

i wanted to open a bug report about the fact that the new binary won't run on most Macs and that this isn't even mentioned in the release notes but i see this is discussed here already.

[paul-cossey]

Thanks again for the quick turn around, @grossmj much appreciated! I'm happy for this to be closed as resolved.

And thanks for the additional info around CircleCI deprecating Intel builds. That's very helpful to know. I guess more vendors will follow suite and start to only release arm64 versions.

@core-code The release notes do mention arm64 builds only: https://gns3.com/community/blog/gns3-2-2-48-released

Please note that since v2.2.42, only macOS 12 and above is supported and since v2.2.48 only Apple Silicon based machine are supported. Building a universal macOS app is a possibility if enough requests are made.

FWIW we'd prefer a universal build, as we still have to support x86_64 computers, but appreciate the additional effort on your part may not be worth it.

[core-code]

The release notes do mention arm64 builds only

thats good, also adding the note to the release notes on GitHub would be great

[grossmj]

thats good, also adding the note to the release notes on GitHub would be great

I have added a note, thanks 👍

[grossmj]

@core-code @admdly

I have released an Intel version that needs to be tested: https://github.com/GNS3/gns3-gui/releases/download/v2.2.48/GNS3-2.2.48-intel.dmg

Please let me know if it works on your side. Thanks 👍

[admdly]

@core-code @admdly

I have released an Intel version that needs to be tested: https://github.com/GNS3/gns3-gui/releases/download/v2.2.48/GNS3-2.2.48-intel.dmg

Please let me know if it works on your side. Thanks 👍

Thanks for this - from brief testing it looks to be working as expected for me (iMac, 2019).

[core-code]

same here