Squirrel.Mac
Squirrel.Mac copied to clipboard
Squirrel
System or bundle-specific default for disabling updates and helper tool installation
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).
+1, especially confusing when the prompts are like every few hours, and there doesn't seem to actually be any updates available?
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.
+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
fwiw, Slack will be fixing this via chown'ing itself in the next version
On Wed, Jan 18, 2017, 18:44 innermotion [email protected] wrote:
+1 , it's certainly odd and annoying.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Squirrel/Squirrel.Mac/issues/192#issuecomment-273667030, or mute the thread https://github.com/notifications/unsubscribe-auth/ABiD8SEDSayOHKR5XCDIuEXQUhj3K8NPks5rTs34gaJpZM4LCvT2 .
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.
I would be extremely :-1: on that change, this is up to individual app developers, not as a systemwide "please disable this library" setting
On Wed, Jan 18, 2017, 19:10 Greg Neagle [email protected] wrote:
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.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/Squirrel/Squirrel.Mac/issues/192#issuecomment-273670483, or mute the thread https://github.com/notifications/unsubscribe-auth/ABiD8Rx1eobdo0wuAgE-abas2b6wi1Y-ks5rTtQhgaJpZM4LCvT2 .
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.
Lol also /cc @paulcbetts, this is what I get for replying to GH issues via mail
On Wed, Jan 18, 2017, 19:14 Paul Betts [email protected] wrote:
I would be extremely :-1: on that change, this is up to individual app developers, not as a systemwide "please disable this library" setting
On Wed, Jan 18, 2017, 19:10 Greg Neagle [email protected] wrote:
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.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/Squirrel/Squirrel.Mac/issues/192#issuecomment-273670483, or mute the thread https://github.com/notifications/unsubscribe-auth/ABiD8Rx1eobdo0wuAgE-abas2b6wi1Y-ks5rTtQhgaJpZM4LCvT2 .
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.
+1 The update prompt is confusing and, worse, looks like broken software (~3600 Macs). Please look into Greg and Tim's suggestions above.
Thanks! What approach would make sense to you for the Mac? For example, supporting a preference like SQRLEnableAutomaticChecks which could be set to false?
For example, supporting a preference like SQRLEnableAutomaticChecks which could be set to false?
Yup, I think mirroring Sparkle would make sense.
@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
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.
+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.
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.
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.
+1 here. I'm in agreement with most of the sentiments expressed above. A SQRLEnableAutomaticChecks preference would be ideal.
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.
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.
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.
Sounds like we need to start engaging Slack as paying customers instead of trying to influence the development of this project
@gregneagle Just opening a support ticket right now, since my employer IS a paying customer.
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.
