Sign macOS app

Avatar
  • updated
  • Completed

In order to deploy macOS privacy preferences policy via MDM/DEP, the macOS app in Mojave that needs exceptions must be signed. Otherwise, a user has to create exceptions to allow remote control via ConnectWise Control, which isn't ideal. I don't want to have to sign your app to get the payload pushed out to create the exceptions from our management software. If you signed your apps like other developers, this would be much easier for all users, like those of the Addigy and JAMF communities. 

Duplicates 1
Please Implement code signing for MAC OS PKG installers.

This has been an issue for some time and it is getting worse with the latest release of MACOS Mojave. https://control.product.connectwise.com/communities/6/topics/1974-complicated-process-required-to-control-macos-1014-mojave-clients


Security requirements are increasing and there may come a point where we cannot use ScreenConnect to manage/support Macs. If that happens, it will force us to abandon Screenconnect for managing Macs which means less revenue for you.  Since you have a cert in use for the windows EXE, why not sign the PKG files for Macs with the same cert?  Can someone in business development review this and get an internal count of how many hundreds or thousands or tens of thousands of machines are currently under Control?  It's likely a big impact.

Thanks for your time and consideration.

Avatar
0
ASimm
Quote from anonymous

I enjoy all the feedback we have gotten on this issue. As we continue development on this issue, I wanted to provide some clarification.

We have started development on signing the macOS installer bundle. When the macOS installer bundle is downloaded, it undergoes dynamic changes related to our customization features. The same is true for all of the installers. However, only for macOS do these changes break the signature of the bundle. Therefore, not signing the application was a tradeoff to allow for the .pkg to have customized branding, naming, etc. However, the release of Mojave changes that calculation for the following reason: permissions granted to unsigned applications to not persist upon reinstall.This is the main reason why we have decided to investigate signing the installer. Doing so requires some significant changes to what/how we customize our application, but we are working hard to maintain all functionality at this point. This is the main sticking point with signing the application.

As Caitlin said, this does not solve this issue because end users will still be required to be admin users and supply permissions to our application. Although signing the application allows it to be distributed with an MDM product, we do not consider that a solution because we can't require our partners to purchase a 3rd-party tool to support ours. Currently, there is no way to get around these permission challenges for any software vendor. That said, we are glad that signing our application has the ancillary benefit of making it compatible with 3rd-party tools in use by our partners.

Hope that helps. We will keep this thread updated as work progresses.

Is there an ETA of when this will be working for macOS 10.14? Currently unable to push it out to labs until I can give accessibility access using an MDM.

Avatar
1
anonymous
Quote from ASimm

Is there an ETA of when this will be working for macOS 10.14? Currently unable to push it out to labs until I can give accessibility access using an MDM.

You can expect this change to be available in the next stable version of 6.9, or the pre-release of 7.0, before the end of January

Avatar
0
DFree
Quote from anonymous

You can expect this change to be available in the next stable version of 6.9, or the pre-release of 7.0, before the end of January

Please post here when that version is available.  While I can also dig up the Team ID after it is installed, can you also provide us the Team ID of your signed installer when the new version is available?  This will make it possible to whitelist in Jamf/PPPC before I test the new version.

Thanks!

Avatar
0
Howie Isaacks

I would love to know exactly why ConnectWise was not signing the app in the first place. I have WASTED hours of precious time working on a profile that would allow Screen Connect to run, and then I find out that because it's not signed, this is not possible. Application signing became a requirement on the Mac with the release of OS X Lion nearly 8 years ago. Why did ConnectWise wait so long? When I have a choice, I won't work with developers who don't sign their work.

Avatar
0
anonymous
Quote from Howie Isaacks

I would love to know exactly why ConnectWise was not signing the app in the first place. I have WASTED hours of precious time working on a profile that would allow Screen Connect to run, and then I find out that because it's not signed, this is not possible. Application signing became a requirement on the Mac with the release of OS X Lion nearly 8 years ago. Why did ConnectWise wait so long? When I have a choice, I won't work with developers who don't sign their work.

Only the macOS access client is not signed. This is due to incompatibilities with Apple's signatures and Control's customization features. The unsigned access client has not caused any problems on macOS until Mojave. 

Avatar
0
anonymous
Quote from DFree

Please post here when that version is available.  While I can also dig up the Team ID after it is installed, can you also provide us the Team ID of your signed installer when the new version is available?  This will make it possible to whitelist in Jamf/PPPC before I test the new version.

Thanks!

You should whitelist these Team IDs:

X5ZCVVHK4S

K8M3XDZV9Y

Avatar
0
Howie Isaacks
Quote from anonymous

Only the macOS access client is not signed. This is due to incompatibilities with Apple's signatures and Control's customization features. The unsigned access client has not caused any problems on macOS until Mojave. 

OK. So it's Apple's fault for improving the security of their operating system. Let me go on record as saying that I do not blame Apple for this. I am 100% in support of their security and privacy measures on macOS even though they are sometimes a pain to have to deal with. As I stated before in this thread, macOS Mojave was released to developers in June of last year. The full release of the OS was released in late September. 

Avatar
2
Howie Isaacks
Quote from anonymous

You should whitelist these Team IDs:

X5ZCVVHK4S

K8M3XDZV9Y

We need more than just team IDs. Here's a sample of code requirement needed to create a configuration profile to whitelist an app. Note that the team ID is at the end, and there is information related to the certificate that is attached to the Jamf agent. Since Screen Connect has no certificate there's not enough information to put into the code requirement field.

identifier "com.jamfsoftware.jamfAgent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "483DWKW443"

Avatar
0
anonymous
Quote from Howie Isaacks

OK. So it's Apple's fault for improving the security of their operating system. Let me go on record as saying that I do not blame Apple for this. I am 100% in support of their security and privacy measures on macOS even though they are sometimes a pain to have to deal with. As I stated before in this thread, macOS Mojave was released to developers in June of last year. The full release of the OS was released in late September. 

The macOS access client currently works as expected when permissions are granted. The main issue is that the applications permissions are not persisted upon reinstall, and must be re-granted. We are working to remedy this and are testing OS releases more thoroughly in the future to find issues like this sooner.

Avatar
0
Howie Isaacks
Quote from anonymous

The macOS access client currently works as expected when permissions are granted. The main issue is that the applications permissions are not persisted upon reinstall, and must be re-granted. We are working to remedy this and are testing OS releases more thoroughly in the future to find issues like this sooner.

Right. It will work once permissions are granted, but that requires admin access. If a user is not an admin, they can't grant permission. Also, a lot of the affected systems are out of my reach. I cannot grant access. The only solution to this is that we need the app to be signed. Period. I don't care about the installer. When Jamf Pro runs the installer for Screen Connect, it does so with root privileges, so there is no Gatekeeper warning. The app itself needs a developer certificate. I'm not going to debate this. We know what the solution needs to be, so it needs to be implemented.



Top contributors

Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar