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

[timsutton]

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:

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

[erikng]

Why can't you just post the key online?

Do I really need to put a support ticket in and then blog about it to help others?

[kevinmcox]

It would be great if we could control this behavior for Slack through a configuration profile.

[RobertHammen]

It’s already been blogged:

https://rickheil.com/disabling-auto-updates-on-slack-for-mac/

[erikng]

What on earth is this? Who in their right mind let this make it out into production?

[neilmartin83]

Just chiming in a bit late on this but since Microsoft are now using Squirrel for Skype 8.x and Teams, this is now an issue with those apps too.

Right now you can run /bin/launchctl setenv DISABLE_UPDATE_CHECK 1 in the user context at each login to knock it out globally (have tested/verified against Skype 8.x but not Teams, however assume it works for that too) but I fully support the request to have it manageable on a per-app preference domain basis, rather than use the "sledgehammer to crack a walnut" approach.

Prompting non-admin users (e.g. students during a lesson) for admin authentication in lab environments is not great.

[nilsbyte]

/bin/launchctl setenv DISABLE_UPDATE_CHECK 1 does not work. The variable is not set when checking it with env. macOS 10.11.6 over Remote Desktop.

[apizz]

School with 300+ Macs. We need to be able to control what updates are pushed out when. Sad to see that this has been a request for almost 2 years ... where is this admin preference??

[apizz]

I feel like I'm having Dejá vu ...

[grahampugh]

Does this mean that /bin/launchctl setenv SLACK_NO_AUTO_UPDATES 1 will work here if run for every user?

[tbridge]

Bumping this again, since it appears to do this on install of Slack 3.4.0. Annoying as hell.

[lashomb]

I have brought this up to Slack, asking them to contribute to this framework as they use it and enterprises would welcome control over their updates. They said they wouldn’t be doing that.

[ygini]

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]

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]

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]

@rickheil ! At least some bit of good news after ⏲ ⏲ ⏲

[MarshallOfSound]

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

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

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

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

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

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

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]

The point you seems to miss is: this feature does not have to be linked to any software editor choice.

Look at this insane thread, do you want us to have the same waste of time with all developers relying on your framework?

Should I remind you that your product exist for one exact reason: developer that don’t want to bother with native code at all.

So think a minute about what you said and consider how badly advised it is.

And no, adding what way too many people already asked you to do is the only solution (and for god sake, take a look at where those people are working, they are way more knowledgeable on this topic that your company!)

And no, it won’t impact thousand of software using your system since it’s an opt out feature. So no one will notice it at all.

And for one reasons:

• people with unmanaged apps will not use it so app will stay up to date via built in system
• people with managed app will use it and app will stay up to date with a way more performant solution that yours

So in the end, since it’s an opt out, made for sysadmin more knowledgeable than you, you can be sure that your customers won’t notice it.

Le 16 juil. 2019 à 22:47, Anaïs Betts notifications@github.com a écrit :

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.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[bp88]

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

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

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]

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

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

[MarshallOfSound]

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

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

[bp88]

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

[bp88]

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

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]

[bp88]

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

[bp88]

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

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

[bp88]

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

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]

I just wanted to mention @shiftkey is "fighting for the users" over in threads like https://github.com/desktop/desktop/issues/3410#issuecomment-472162125, 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]

I'm adding my +1 to this issue.

[apizz]

It's like at this point >> https://github.com/Squirrel/Squirrel.Mac/issues/192#issuecomment-512027702 << we finally got someone to understand that this isn't that hard and then crickets

[fmamberti]

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

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]

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]

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]

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]

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]

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