Welcome to our community!

Sign macOS app

Avatar
Alex Hart
  • 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.

Replies 101
Avatar
0
Alex Hart
Quote from Howie Isaacks

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.

Brandon, can you please clarify what it is that ConnectWise is working on (referenced above in https://control.product.connectwise.com/communities/1/topics/2046-sign-macos-app#comment-7007 "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")? I really hope that the app itself is going to be signed as part of that work, which is what this ticket is for, and not something else. I would expect that the customizations are either held outside the application (in Library or something like most other apps). I could see you signing before download (after customizations are injected server-side), but it seems easier to just move those outside the .app that you sign. Ideally, you aren't signing with any client preference changes on the server side (that requires re-install of client. Bottomline, this request and the outcome of any related work should be a signed app. 

Avatar
0
Alex Hart
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.

Don't forget that the privacy permissions manually granted are reset anytime you update the client, which you guys also do very frequently, for better or worse.

Avatar
0
Howie Isaacks

If it will help, I would be happy to test the new version by distributing it using one of our Jamf Pro servers. We need to be able to deploy Screen Connect without users being nagged about approving the app. A lot of the Macs that we manage never get touched by us. Some of them are as far as 1000 miles away, and the users are not admin users. The key for us being able to whitelist the app is that it must be signed. There is no other way for us to do this.

Avatar
0
Alex Hart
Quote from Howie Isaacks

If it will help, I would be happy to test the new version by distributing it using one of our Jamf Pro servers. We need to be able to deploy Screen Connect without users being nagged about approving the app. A lot of the Macs that we manage never get touched by us. Some of them are as far as 1000 miles away, and the users are not admin users. The key for us being able to whitelist the app is that it must be signed. There is no other way for us to do this.

There really shouldn't be much to test. They just codesign the app and we put the Code Requirement string in our PPPC profiles. 

Avatar
0
Howie Isaacks
Quote from Alex Hart

There really shouldn't be much to test. They just codesign the app and we put the Code Requirement string in our PPPC profiles. 

No. I test. When I took my Jamf certification courses, I was taught to test, test, test, and do more testing before deploying something to hundreds or thousands of systems.

Avatar
0
anonymous
Quote from Alex Hart

Brandon, can you please clarify what it is that ConnectWise is working on (referenced above in https://control.product.connectwise.com/communities/1/topics/2046-sign-macos-app#comment-7007 "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")? I really hope that the app itself is going to be signed as part of that work, which is what this ticket is for, and not something else. I would expect that the customizations are either held outside the application (in Library or something like most other apps). I could see you signing before download (after customizations are injected server-side), but it seems easier to just move those outside the .app that you sign. Ideally, you aren't signing with any client preference changes on the server side (that requires re-install of client. Bottomline, this request and the outcome of any related work should be a signed app. 

The changes include signing the macos access client. Please refer to my comment above for a description of what's involved with that.

Our customization features include rebranding of the application that is a part of the app itself and cannot be extracted to an external library (e.g. bundle name, icon, etc)

Avatar
0
anonymous
Quote from Alex Hart

Don't forget that the privacy permissions manually granted are reset anytime you update the client, which you guys also do very frequently, for better or worse.

Good point, because an update to the client requires a reinstall, the clients permissions will not persist. 

Avatar
0
Headbolt
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

The next Stable release of 6.9 after you made this post came and went without any change to the situation, I suspect the code for that release was locked already.

Do you have an eta for the NEXT 6.9 stable that will have this in, or pre-release of 7 ?


This is critical for us and we are getting a lot of backlash denying upgrade to Mojave while we wait for this, i'd love to get this tested ASAP.


Thanks 

Avatar
0
Headbolt
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

Brandon

The latest stable version of 6.9 came out a few days after you made this post and the change was not there, I assume the code was already "Locked" by that time.

When will the next stable version of 6.9 with this fix in it be available ? Or a Pre-Release of 7 ?


We are getting masses of flack from our user base because we wont allow them to have Mojave until this is fixed and we can control their machines properly.

Avatar
0
anonymous

@Headbolt: There is a new version of 6.9 available in the Canary channel in Control Cloud (6.9.21870.6964). This includes several fixes for macOS Mojave (including the signing of the access client) and is currently in testing.

!!!!NOTE: Versions in the Canary channel have not completed internal testing and are not appropriate for production environments!!!!

A new version of 6.9 will be available in the Preview channel once testing is complete. I will keep this thread updated with details.



Top contributors
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar