Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

System or bundle-specific default for disabling updates and helper tool installation #192

Open
timsutton opened this issue Dec 2, 2016 · 98 comments

Comments

@timsutton
Copy link

Is there a way besides an environment variable to altogether disable Squirrel's attempt to install the ShipIt helper, for environments where applications get deployed to systems from a central management tool, and where regular users aren't admins or otherwise don't own the application app bundle?

For example, on macOS, I install Slack 2.3.2 (now out of date) to /Applications owned by root:wheel. When I run it as a non-admin user, I get this prompt:

screen shot 2016-12-02 at 11 05 50 am

In environments where there's a large install base of an app using Squirrel (for example, a University classroom lab teaching code using Atom), it's confusing for users to get a prompt asking them to install a helper tool that they'll never be able to install without being administrators.

I've worked around this prompt by setting DISABLE_SYSTEM_UPDATES (found in use here) in my user environment, but that's less obvious and looks like an undocumented debugging solution. Might be it possible for there to be a supported system-wide configuration file path to disable this?

For example, Atom supports a config setting in its config.cson to disable updates. The non-Mac-App-Store Slack doesn't seem to support any such setting. Sparkle never supported a system-wide setting either, but at least supported it as a preference that could be set system-wide (or per-user) for a Mac app bundle.

(As a side note, if I enter an admin's credentials, it doesn't complain but I get the same prompt next time I launch the app, and it never seemed to attempt an update).

@bochoven
Copy link

bochoven commented Dec 3, 2016

+1 The update prompt is a confusing UX in our environment (2000+ Macs)

@smashism
Copy link

+1, especially confusing when the prompts are like every few hours, and there doesn't seem to actually be any updates available?

@timsutton
Copy link
Author

In my experience with Atom and Slack, it's always been that there is a newer version available, but that even if I do authenticate to install the helper tool, somehow it still does not seem always to properly install the update. Haven't tested this systematically enough to know if it's related to the ownerships being something like root:wheel or some other user which is not the user being prompted to install the helper tool.

But here, I really just want an officially-supported way to disable the Squirrel update check besides using an undocumented debug flag. If Squirrel already had infrastructure for some kind of system-wide config file it would be trivial to add, but I'm not sure that such a thing exists or is planned.

@YNedderhoff
Copy link

+1 Experiencing the same, also with Atom and Slack.

@arubdesu
Copy link

+1, I have over 4 thousand machines, this is undesirable behavior. I could understand if it was due to someone adding themselves to a beta track while I'm trying to maintain the stable versions, but that's not what is being experienced. Please consider working with Slack to have them respect this configuration option

@innermotion
Copy link

+1 , it's certainly odd and annoying.

@fakepaulbetts
Copy link

fakepaulbetts commented Jan 19, 2017 via email

@gregneagle
Copy link

The fix that is being asked for is a way to disable the Squirrel updater without relying on environment variables. An on-disk preference would be ideal.

@fakepaulbetts
Copy link

fakepaulbetts commented Jan 19, 2017 via email

@gregneagle
Copy link

A per-app control would be fine, too. Right now you can disable the library for all apps using environment variables, so it's not really something being taken away from app developers.

@fakepaulbetts
Copy link

fakepaulbetts commented Jan 19, 2017 via email

@timsutton
Copy link
Author

Consider the situation with Mac apps that use Sparkle, where there's a consistently-available method for disabling the update-checking mechanism (setting SUEnableAutomaticChecks and friends using either defaults, a configuration profile, or some other method to set a standard Mac preference).

If it were built into the framework, then something similar would be possible, no application maintainers would need to spend time considering working on such a feature, implementing it differently, etc.

On Windows I would imagine something similar working via a registry key.

@nealdav
Copy link

nealdav commented Jan 24, 2017

+1 The update prompt is confusing and, worse, looks like broken software (~3600 Macs). Please look into Greg and Tim's suggestions above.

@joshaber
Copy link
Contributor

I'm happy to review any pull requests to this effect 😄

@timsutton
Copy link
Author

Thanks! What approach would make sense to you for the Mac? For example, supporting a preference like SQRLEnableAutomaticChecks which could be set to false?

@joshaber
Copy link
Contributor

For example, supporting a preference like SQRLEnableAutomaticChecks which could be set to false?

Yup, I think mirroring Sparkle would make sense.

@anaisbetts
Copy link

anaisbetts commented Jan 28, 2017

@joshaber Please don't add this feature, I've already had to nerf that environment variable in the Slack app. This is a nightmare for any customer support staff for any app that uses Squirrel

@gregneagle
Copy link

gregneagle commented Jan 28, 2017

And the lack of the feature is a nightmare for internal support staff for any app that uses Squirrel. Our users often do not have admin rights and this dialog -- which they can do nothing about themselves -- leads to help desk calls. We have ways of updating the software we manage for our users -- we don't need the app's own auto-updater. We'd like a supported way to disable it.

@nmcspadden
Copy link

+1 here as well. Enterprise organizations generally have their own mechanisms for deploying software updates. Updating our software on our own schedule tends to be of critical importance during high stakes projects, and having a user experience like this is a major downer.

As others pointed out, not being able to suppress updates from an enterprise perspective leads to significant extra churn for support personnel, and unnecessary hassle for IT departments.

Please trust enterprise orgs to manage things on their own, and provide us the simple tools (a simple preference key is all we ask for, really) to do this.

@foigus
Copy link

foigus commented Jan 28, 2017

This is a nightmare for any customer support staff for any app that uses Squirrel

The goal isn't to disable every Squirrel updater with a single setting. The goal is a common, supported change to disable Squirrel updates per-application.

The closest analog I can think of is Sparkle's SUEnableAutomaticChecks, which is a consistent setting across many applications that allows per-application disabling of updaters in environments where updates are already managed.

@timsutton
Copy link
Author

To address @paulcbetts's concern about it causing support burden, I think that the only environments where people would intentionally set such a "disable update checks" preference would be the environments where the Squirrel updates wouldn't work anyway, like where 1) users aren't admins anyway, and this can do nothing about repeated prompts to install a helper tool, or 2) management tools are already installing app bundles to /Applications owned by root, which could conflict with what Squirrel would be doing when it installs updates.

In other words, cases where Squirrel is "competing" with existing infrastructure that manages most of users' app installs or system configuration. I don't know if this is stretching your argument but I don't think any admins are intentionally holding back updates to collaboration apps like Slack, they just would like users to not be confused or annoyed by authorization prompts if that can be avoided.

@andrewvalentine
Copy link

+1 here. I'm in agreement with most of the sentiments expressed above. A SQRLEnableAutomaticChecks preference would be ideal.

@timsutton
Copy link
Author

timsutton commented Mar 10, 2017

I see now that in Slack 2.5.1 (and 2.5.2) this disable env var has, as @paulcbetts alluded, been squelched by the app:

➜ ~ cat /Applications/Slack.app/Contents/Resources/app.asar | grep --text -C 6 DISABLE_UPDATE_CHECK

  constructor(options: MacSquirrelUpdaterOpts) {
    super();
    if (isAppStore) return;

    // NB: Squirrel.Mac has a brain-dead way to disable itself system-wide
    // for any app using Squirrel. Nerf that shit so hard
    if (process.env.DISABLE_UPDATE_CHECK) {
      delete process.env.DISABLE_UPDATE_CHECK;
    }

    const updateUrl = options.useBetaChannel ?
      `${UPDATE_URL_PREFIX}_beta` :
      UPDATE_URL_PREFIX;

Within 30 minutes of 2.5.1's release generally, two Mac sysadmins in the Macadmins Slack team each reported help desk tickets about Slack prompting them for admin rights. One supports Mac machines numbering in the hundreds, the other in the thousands.

This is why I think supporting an admin-configurable disable flag for Squirrel is still of value to organizations. However, with Slack being one of the most popular (IMO) apps using Squirrel, if the app will continue being hostile to any such setting, I can only assume that if we were to add a system-wide preference to Squirrel that Slack would do everything possible to flip it.

Apple also supports the notion of preferences via management tools like Configuration Profiles and CFPreferencesAppValueIsForced, which could potentially ignore any user preferences if so desired. This starts to feel very heavy-handed, though.

I'll get off the soapbox after this (and for lack of a better venue more specific to Slack), but I manage and configure well over a hundred Mac apps for use in creative environments in an aim to avoid application-level dialogs which are not actionable in any way by the user, and I've never before seen in a scenario in which the application actively unsets any user preferences that control behaviour of its included frameworks.

The only thing holding me back on testing a (admittedly very simple) PR for this is my lack of familiarity with all the build tooling around Squirrel and a test implementation, which I've looked at but has taken me some time to wrap my head around.

@RobertHammen
Copy link

Just chiming in here, had 6 tickets in an hour this morning once Slack 2.5.2 was released, because the app prompts for admin credentials and our users are not admins.

IT admins really need a method to disable the automatic update. This doesn't mean that we won't update the apps - far from it - but we want to update them seamlessly and on our terms, not Slack's.

@macmule
Copy link

macmule commented Mar 15, 2017

Just chiming in that we've had our customers (whom are paying for Slack too).. complaining about the admin prompts.

We had to respond immediately to update a few hundred Macs across a few companies, not good.

@gregneagle
Copy link

Sounds like we need to start engaging Slack as paying customers instead of trying to influence the development of this project

@RobertHammen
Copy link

@gregneagle Just opening a support ticket right now, since my employer IS a paying customer.

@foigus
Copy link

foigus commented Mar 15, 2017

I also just submitted a support ticket for our paid Slack instance.

@nealdav
Copy link

nealdav commented Mar 15, 2017

We've had a ticket open for a few weeks now. It was suggested that 2.5.2 was going to address this issue but that was obviously not the case.

@erikng
Copy link

erikng commented Mar 15, 2017

Company with about 2,000 macs as well.

@anaisbetts
Copy link

anaisbetts commented Jul 16, 2019

@nmcspadden it is not appropriate or reasonable to patch Squirrel and change policy for thousands of applications, in a backhanded attempt to change some vendor's app for them. Please talk to your application vendor, this is not a user support forum.

@apizz
Copy link

apizz commented Jul 16, 2019

@anaisbetts Given the number of people on this thread and length of time that this issue has been in place here, your comment comes across to me as incredibly dismissive and ignores the legitimate issue & concern that we as administrators in the enterprise have when we can't manage the rollout of software updates across our fleet.

I honestly don't understand why it is so hard to understand this need and why after 3 years we're still arguing about why this functionality needs to be added.

@anaisbetts
Copy link

@apizz while I agree that this is absolutely a problem for IT admins, everything that I said still continues to be true. This is not the Way to fix it.

@anaisbetts
Copy link

I think that a great compromise here would be to add a new -isEnterpriseDeployed public API that app developers can query, that polls a well-documented, public plist key.

That way, developers can change their policy (maybe by ignoring updates altogether, maybe by doing something else), and IT admins still can use one single key.

@ygini
Copy link

ygini commented Jul 16, 2019 via email

@bp88
Copy link

bp88 commented Jul 16, 2019

@MarshallOfSound You mentioned that this was a simple one line of code that developers could introduce in their apps, but it's clear that if it were that easy all apps would be adding this option. The problem is that in many cases IT administrators are a complete after thought for many developers. The reason is that those developers are trying to just get the app out there and focus on their main target audience. It's only when they get popular enough that the apps start to get use in enterprise environments and then it becomes a problem for IT administrators to manage.

May I suggest an alternative? Before Squirrel became popular, Sparkle was quite (and still is) a popular update framework for macOS apps. One neat effect of using this framework is that one could look at the preference keys in the application and automatically control SUEnableAutomaticChecks, SUFeedURL and other related preferences. What this meant is that all apps that used the framework implemented the preference keys which meant that IT admins could control the update mechanism for the specific app in question so that end users did not get prompted for updates.

The compromise here would be that the Squirrel framework would write out and read preferences from using native APIs on macOS for the specific application's domain similar to how Sparkle does it. This would have the effect of allow admins to manage updates for individual apps rather than ALL apps that use Squirrel. This would mean that all apps using the Squirrel Framework would predictable have preference keys such as SQEnableAutomaticChecks, SQFeedURL, SQFrequencyCheck, etc.

Some benefits include:

  1. developers wouldn't have to write specific code for their apps which IT admins would need to figure out,
  2. it would create consistency with the preference keys IT admins could look out for,
  3. it would avoid updates being disabled for ALL apps that use Squirrel, and
  4. keep the update default state to enabled but allow IT admins to opt out on managed computers.

Right now, because of the lack of update control, I'm positive there are Squirrel-based apps out there that are currently being blocked from updating because there's not a specific mechanism to manage the preference for specific apps. Or in some cases, the apps may not be allowed at all because they are not ones that can be managed.

What we're asking for is the same kind of management capability we have with Sparkle: https://github.com/sparkle-project/Sparkle
Here are some such keys used in that project: https://github.com/sparkle-project/Sparkle/blob/fb18c1e542c034e01b8c45a3977ca7e1ace6cfa7/Sparkle/SUConstants.m#L40-L43

@MarshallOfSound
Copy link
Collaborator

@bp88 In a hypthetical world where this environment variable was extended with a NSUserDefaults key lookup for SQDisableUpdates or something how do you propose that that is surfaced to developers.

While I agree with all of the above that this would be perfect / amazing for sysadmins. The case that's missing here is what about the devs, do we throw an error, do we tell them it succeeded, do we just never complete the signal and hope the app can handle that.

This would be an entirely new end case that no developer-code would be ready to handle. Which makes this:

developers wouldn't have to write specific code for their apps

Slightly wrong, all devs would need to handle this case, in pseudocode.

// Before
tryUpdate();
if (success) restartAndUpdate();
else logError();

// After
tryUpdate()
if (success) restartAndApplyUpdate()
else if (updatesDisabledBySystem) ignore()
else logError()

Your proposed change would introduce a third case that needs to be handled by developer code due to the current API of Squirrel.Mac and electron.

If we can come up with a way of doing this that doesn't introduce a third case then that's where things start looking brighter, but for now from my perspective it's either

  • Introduce a subtle breaking change for all applications that depend on Squirrel.Mac / Electron
  • Ask each developer individually to support a preference key

Neither of which is all that great, the first one sucks for devs and the second one sucks for sysadmins because the keys won't be consistent, documented or might not exist at all.

As @anaisbetts said above

it is not appropriate or reasonable to patch Squirrel and change policy for thousands of applications

I'm here to try find a middle ground that won't break existing logic but will grant you the ability to manage your devices like you want 😄

@gregneagle
Copy link

gregneagle commented Jul 16, 2019

One assumes there is a case where no update is available.

When this proposed global preference is set, the code could just always act as if no updates were available. No developer code changes needed.

@gregneagle
Copy link

gregneagle commented Jul 16, 2019

// Before
if (updateAvailable()) {
    tryUpdate();
    if (success) restartAndUpdate();
    else logError();
}

// After
if (updateAvailable()) {
    tryUpdate();
    if (success) restartAndUpdate();
    else logError();
}

@MarshallOfSound
Copy link
Collaborator

@gregneagle That actually seems somewhat reasonable and would slide into expected behavior territory which is good. Let me do some offline chatting with some folks and get a feel for how this would go down

@bp88
Copy link

bp88 commented Aug 8, 2019

@MarshallOfSound Just curious how offline discussions are going concern this topic.

@bp88
Copy link

bp88 commented Mar 29, 2020

@MarshallOfSound Just following up on how offline discussions are going concern this topic.

@bp88
Copy link

bp88 commented May 19, 2020

@MarshallOfSound Hope you and your family are safe during these pandemic times. Just wanted to check in to see if you ever got a chance to have any offline discussions on this particular issue?

@simX
Copy link

simX commented Jun 26, 2020

Lol at this thread, and how admins continue to be an afterthought. @MarshallOfSound, has anything been done on this? This has been 3.5 years in "discussion" now, maybe it's actually time to make admin's lives easier?

@apizz
Copy link

apizz commented Jul 23, 2020

external-content duckduckgo

@bp88
Copy link

bp88 commented Nov 19, 2020

@MarshallOfSound Would you be able to give us an update on how discussions on this issue and the proposed changes went?

@bp88
Copy link

bp88 commented Dec 3, 2020

@MarshallOfSound I get this strange feeling that you might be ignoring us. Why? We're just trying to have a discussion and you had mentioned that you would discuss this with other devs. Where did that conversation land?

@bp88
Copy link

bp88 commented Dec 9, 2020

@MarshallOfSound Just checking in again. Any update is appreciated.

@bp88
Copy link

bp88 commented Dec 10, 2020

@MarshallOfSound Just checking in again. Myself and others are only looking an update on the discussion you mentioned you'd have regarding this request.

@joshua-d-miller
Copy link

joshua-d-miller commented Dec 22, 2020

I used to disable the Squirrel Helper so that it wouldn't bug our nonadministrative users. Now that we deploy Discord that is no longer possible because Discord relies on the Squirrel updater. It would be really nice if the devs who have obviously ignored our request for four years now would actually respond instead of just letting us screaming into the ether. Unfortunately, we see this often where administrators are seen as an afterthought. Hey @MarshallOfSound, it's incredibly disappointing that your last response to this discussion was over a year ago and you have provided no update on whether you plan on working with us or not. I think we deserve at least some kind of response even if it's something you don't plan on implementing.

@arubdesu
Copy link

I just wanted to mention @shiftkey is "fighting for the users" over in threads like desktop/desktop#3410 (comment), this issue mentioning both updates and helper tool may dilute some of its effectiveness, but for reference the lack of delta patching is more fuel for this fire.... issue #5! Single digits! 😅

@wegotoeleven
Copy link

I'm adding my +1 to this issue.

@apizz
Copy link

apizz commented Feb 9, 2021

It's like at this point >> #192 (comment) << we finally got someone to understand that this isn't that hard and then crickets

@fmamberti
Copy link

+1 on this. We are now in the position of having thousands of Macs with non-admin users which can either have to deal with a few admin prompts for updating a few apps, or not being able to launch Discord...

@MrCoBalt
Copy link

MrCoBalt commented Feb 14, 2022

So almost 6 years on… I still have to deploy /bin/launchctl setenv DISABLE_UPDATE_CHECK 1 globally just so that my users don't get useless "admin helper" prompts they can't do anything about… Not a great look here on the complete lack of followup @MarshallOfSound 😢 (thankfully not using Discord internally…)

@abulgatz
Copy link

As a sysadmin managing Macs with an MDM and pushing apps and updates (users don't have admin rights), it would be really nice if Squirrel could take after Sparkle and allow us to set per-app PLIST settings to disable auto-update. Discord and Spotify would benefit from this.

@paul-cossey
Copy link

paul-cossey commented Feb 23, 2023

I guess we're all just whistling in the wind at this point, but I may as well add myself to the list of folks that would very much like the ability to switch off in-app updates. It causes no end of head aches for our customers that don't have admin rights.

@marc-guenther
Copy link

This horribly annoying issue (on a daily basis!) has been open for more than 6 years. There has been a very simply solution (#192) proposed three years ago, which was followed by complete silence. What is going on here?

@wegotoeleven
Copy link

I love how people are still piling on this request! @MarshallOfSound have you had a chance to take a look at gregneagle's suggestion here?

@paul-cossey
Copy link

Doesn't look like any work has happened since June 2021. Is Squirrel.mac to be considered abandonware?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests