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 · 91 comments

Comments

@timsutton
Copy link

@timsutton timsutton commented Dec 2, 2016

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 bochoven commented Dec 3, 2016

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

@smashism
Copy link

@smashism smashism commented Dec 13, 2016

+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

@timsutton timsutton commented Dec 14, 2016

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

@YNedderhoff YNedderhoff commented Jan 10, 2017

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

@arubdesu
Copy link

@arubdesu arubdesu commented Jan 19, 2017

+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

@innermotion innermotion commented Jan 19, 2017

+1 , it's certainly odd and annoying.

@fakepaulbetts
Copy link

@fakepaulbetts fakepaulbetts commented Jan 19, 2017

@gregneagle
Copy link

@gregneagle gregneagle commented Jan 19, 2017

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 fakepaulbetts commented Jan 19, 2017

@gregneagle
Copy link

@gregneagle gregneagle commented Jan 19, 2017

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 fakepaulbetts commented Jan 19, 2017

@timsutton
Copy link
Author

@timsutton timsutton commented Jan 19, 2017

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 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

@joshaber joshaber commented Jan 26, 2017

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

@timsutton
Copy link
Author

@timsutton timsutton commented Jan 27, 2017

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

@joshaber joshaber commented Jan 27, 2017

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 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 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

@nmcspadden nmcspadden commented Jan 28, 2017

+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 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

@timsutton timsutton commented Jan 28, 2017

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

@andrewvalentine andrewvalentine commented Feb 16, 2017

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

@timsutton
Copy link
Author

@timsutton 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

@RobertHammen RobertHammen commented Mar 15, 2017

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 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

@gregneagle gregneagle commented Mar 15, 2017

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

@RobertHammen
Copy link

@RobertHammen RobertHammen commented Mar 15, 2017

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

@foigus
Copy link

@foigus foigus commented Mar 15, 2017

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

@nealdav
Copy link

@nealdav 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 erikng commented Mar 15, 2017

Company with about 2,000 macs as well.

@ygini
Copy link

@ygini ygini commented Apr 24, 2019

And more over, Slack just told me they don't support mass scale deployment…

https://twitter.com/SlackHQ/status/1120976379795914753

Squirrel is really the root issue here, that's really bad.

@MichalMMac
Copy link

@MichalMMac MichalMMac commented May 15, 2019

Today I wanted to turn off auto update for Skype. Turns out it's also using Squirrel. Would love to have manageable preferences key for Skype. Only found LaunchAgent workaround. Deploy weird workaround or let standard users suffer through auto update prompts requiring admin account.

@rickheil
Copy link

@rickheil rickheil commented Jul 15, 2019

While it does not solve for any OTHER apps, Slack v4.0 introduces a preference to disable auto-updating if desired. https://rickheil.com/disabling-slack-updates-in-v4-0/

Other apps are still affected by this bug.

@apizz
Copy link

@apizz apizz commented Jul 15, 2019

@rickheil ! At least some bit of good news after

@MarshallOfSound
Copy link
Collaborator

@MarshallOfSound MarshallOfSound commented Jul 16, 2019

@rickheil I still don't believe something like this belongs at the framework level, as apps should be making these decisions themselves.

The code to make this kind of feature in your own app is tiny, e.g. the code that slack / electron apps can use to do it.

if (systemPreferences.getUserDefault('MyRandomKeyThatMeansNoUpdates', 'boolean')) return;
@nmcspadden
Copy link

@nmcspadden nmcspadden commented Jul 16, 2019

@MarshallOfSound that line of thinking causes an almost incalculable amount of work at the enterprise level. If we deploy a dozen apps that each use Squirrel as their update framework, you're suggesting that we must individually enforce update settings on each of those apps individually. That generally means the creation of a dozen nearly identical configuration profile payloads, all of which may be randomly named or barely enforced.

It also means existing apps would require the developers who use the framework to make active changes to accommodate this, which puts more onus on them. I'd imagine updating the version of the embedded Squirrel framework without having to make major behavioral/code changes is a far simpler prospect for most developers.

From an enterprise perspective, our remit is to manage things across the board at a system level. Many of us in this issue have been asking, for months, for a simple global killswitch for Squirrel updates. There are a variety of reasons why various organizations would need or want to do this, but this is, at its heart, an enterprise-level request. I highly doubt end-users will notice or even ever care. But it matters quite a bit to the engineers responsible fleets of machines that number in the hundreds, thousands, and tens of thousands, because a global config setting that solves a dozen problems at once is immensely, vastly preferable to a dozen config settings that each only solve one problem and require individual testing, verification, validation, and documentation.

Otherwise enterprise administrators will have to continue to find other, harsher means of enforcing this - such as blocking it at the network level, sinkholing DNS, or clever permissions hacks to prevent the apps from asking users to do things they can't succeed at. All of those contribute to a really poor user experience across the board, because users will likely not understand why the app doesn't behave the way they expect. A global option to disable update checking would generally prevent this from ever coming up, because enterprises can rely on their own internal tooling to update software more effectively than end users can.

@MarshallOfSound
Copy link
Collaborator

@MarshallOfSound MarshallOfSound commented Jul 16, 2019

@nmcspadden Sorry if I wasn't clear, I 100% get your perspective that from a sys-admin side of things you want a simple killswitch so that you can manage updates yourself using your existing infrastructure.

My point was more around I don't think I or this project have the right to make that decision on behalf of apps. If apps come along and ask for this option then that's a different question.

I would also caution against a kill-all switch in case you accidentally prevent updates on a component and you are unaware that it will no longer update.

TLDR: I'm for a solution that would work for sysadmins (hence the recent change in Slack) but in a way that apps are on board with and is predictable / safe for sysadmins, users and app developers. Finding that balance is the thing that thus-far no one has found / proposed 👍

EDIT:
Note I may be missing a thing here (I'm by no means a sysadmin, I just write code). So if there's some perspective I'm missing it'd great to gain that.

@anaisbetts
Copy link

@anaisbetts 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 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

@anaisbetts anaisbetts commented Jul 16, 2019

@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

@anaisbetts anaisbetts commented Jul 16, 2019

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 ygini commented Jul 16, 2019

@bp88
Copy link

@bp88 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

@MarshallOfSound MarshallOfSound commented Jul 16, 2019

@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 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 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

@MarshallOfSound MarshallOfSound commented Jul 16, 2019

@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 bp88 commented Aug 8, 2019

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

@bp88
Copy link

@bp88 bp88 commented Mar 29, 2020

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

@bp88
Copy link

@bp88 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 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 apizz commented Jul 23, 2020

external-content duckduckgo

@bp88
Copy link

@bp88 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 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 bp88 commented Dec 9, 2020

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

@bp88
Copy link

@bp88 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 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

@arubdesu arubdesu commented Jan 26, 2021

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

@wegotoeleven wegotoeleven commented Feb 9, 2021

I'm adding my +1 to this issue.

@apizz
Copy link

@apizz 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

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

Successfully merging a pull request may close this issue.

None yet