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

Comments

Projects
None yet
@timsutton
Copy link

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

This comment has been minimized.

Copy link

bochoven commented Dec 3, 2016

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

@smashism

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

YNedderhoff commented Jan 10, 2017

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

@arubdesu

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

innermotion commented Jan 19, 2017

+1 , it's certainly odd and annoying.

@fakepaulbetts

This comment has been minimized.

Copy link

fakepaulbetts commented Jan 19, 2017

@gregneagle

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

fakepaulbetts commented Jan 19, 2017

@gregneagle

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

fakepaulbetts commented Jan 19, 2017

@timsutton

This comment has been minimized.

Copy link

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

This comment has been minimized.

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

This comment has been minimized.

Copy link
Contributor

joshaber commented Jan 26, 2017

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

@timsutton

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

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.

@paulcbetts

This comment has been minimized.

Copy link
Member

paulcbetts 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

This comment has been minimized.

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

RobertHammen commented Mar 15, 2017

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

@foigus

This comment has been minimized.

Copy link

foigus commented Mar 15, 2017

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

@nealdav

This comment has been minimized.

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

This comment has been minimized.

Copy link

erikng commented Mar 15, 2017

Company with about 2,000 macs as well.

@paulcbetts

This comment has been minimized.

Copy link
Member

paulcbetts commented Mar 16, 2017

So, for the folx on this thread who are IT admins specifically wondering about Slack, here's the information on how this works now:

  1. If Slack.app is able to be updated directly (i.e. the permissions allow us to write to the app), we just do the update, no dialog shown. This can be done even when the user is not an Admin user - Slack.app just needs to have the correct permissions
  2. If Slack can't update, it will attempt to show a sudo dialog so that it can correct its permissions to be writable by the current user. If this succeeds, the user should never see this again (i.e. if you used something like JAMF to install as root, but your users have admin rights, they'll only be annoyed once). This is in contrast with previous versions of Slack, which would just be stuck forever and annoy users every update, because of this bug
  3. If users aren't admin and they have incorrect permissions, they will see this dialog on every startup. The solution for IT folx is to fix the permissions via a script, or switch to the Mac App Store version.

For Slack in particular, the ability to disable automatic updates is particularly problematic. Slack is a hybrid application - while part of it is delivered with the Desktop app, a large part of it is a webapp that is hosted remotely. The webapp will update, no matter what, just like GMail and other web applications that you use every day. So, for Slack, giving users the ability to postpone updates is effectively saying, "I would like to have an app where part of it is updated and part of it isn't, and I want a combination that has undergone possibly little to no testing".

@erikng

This comment has been minimized.

Copy link

erikng commented Mar 16, 2017

@paulcbetts

This comment has been minimized.

Copy link
Member

paulcbetts commented Mar 16, 2017

@erikng When we repair the app, we use the same user/group as the current user - here's the code that does that, from the same file:

  private async repairFilesystemPermissionsIfNecessary(): Promise<void> {
    const { uid, gid } = await getCurrentUser();
    const appUid = fs.lstatSync(process.execPath).uid;

    // NB: This path may or may not exist
    let shipItIsBorked;
    try {
      shipItIsBorked = fs.lstatSync(shipItPath).uid !== uid;
    } catch (e) {
      shipItIsBorked = false;
    }

    if (!shipItIsBorked && uid === appUid) {
      return;
    }

    const ourAppDir = path.resolve(path.dirname(process.resourcesPath), '..', '..');
    const args = ['-R', `${uid}:${gid}`, ourAppDir];
    if (shipItIsBorked) args.push(shipItPath);

    const { exitCode, stdout } = runas('/usr/sbin/chown', args, { admin: true, catchOutput: true });
    if (exitCode !== 0) throw new Error(stdout);
  }

Basically any user / group will work, as long as the result is that the current user can write to Slack.app

@timsutton

This comment has been minimized.

Copy link

timsutton commented Mar 16, 2017

"Correct" permissions as you describe here still seem to always imply a single user on the system.

While it's commonplace for IT to run a script as part of an app installation, what should the ownership be if there are multiple users on the system, or the "primary user" has recently changed to a different login with a new UID?

Making the app world-writable isn't a solution either as that adds a vector for malware.

@paulcbetts

This comment has been minimized.

Copy link
Member

paulcbetts commented Mar 16, 2017

While it's commonplace for IT to run a script as part of an app installation, what should the ownership be if there are multiple users on the system, or the "primary user" has recently changed to a different login with a new UID?

Create a new group (or use the staff group)

@timsutton

This comment has been minimized.

Copy link

timsutton commented Mar 16, 2017

Yes, one can manage groups, and make it so any user (like a member of staff) can write to the bundle - which is effectively the same as making it mode 777 and subject to the same security concerns - since typically any other user on a Mac would also be a member of the same group. For example, Active Directory logins or different local users.

But I think the functional disconnect here is still that there's an expectation that a user-level operation can update code installed to a system location (/Applications).

Spotify does this too, and their latest update this past week has executables set as +x only for owner, because they didn't test it being able to run for any user other than the one who copied it to /Applications. There's a demand for applications like these in large organizations where software installation still remains the responsibility of a system-level daemon, and it immediately shows when the application's updated or installation doesn't take a system-level install into account.

Are you saying that the portion of the app which is rendering web code is also actually expecting to frequently write updated code to disk in /Applications instead of, for example, in the username Caches folder, or wherever else Electron apps would typically store such live data? Out of band from the updates to the "full" app bundle?

@erikng

This comment has been minimized.

Copy link

erikng commented Mar 16, 2017

@paulcbetts

This comment has been minimized.

Copy link
Member

paulcbetts commented Mar 16, 2017

To go back to the "problem" Slack faces about users not updating - how do they deal with this on the Mac App Store?

The Mac App Store can cheat and run code as local system, so they can update apps while still setting their permissions as root. Or do you mean, users who intentionally nerf App Store updates?

@erikng

This comment has been minimized.

Copy link

erikng commented Mar 16, 2017

@paulcbetts

This comment has been minimized.

Copy link
Member

paulcbetts commented Mar 16, 2017

@erikng That's definitely still a problem we're dealing with on all platforms (as well as the far more common case of, "Update just Didn't Work for one reason or another, user is stuck"), we've got some ideas on what to do in these cases that we'll be rolling out soon

@bochoven

This comment has been minimized.

Copy link

bochoven commented Mar 16, 2017

@paulcbetts Please consider the remarks of @timsutton: we consider it a severe security issue to open the permissions for apps on multi user systems. User A can modify the app so that when user B opens it, it will do Bad Things® to his account/files.

Please supply system administrators with a supported way to manage the updates in a controlled way.

@timsutton

This comment has been minimized.

Copy link

timsutton commented Mar 16, 2017

@paulcbetts To your point about ongoing issues getting your updates out to users, I think you'd find that everyone participating in this (now completely hijacked) thread would be very proactive about deploying updates to the app quite promptly, and using tools that are already very capable of automatically installing the updates when the app is detected as not-currently-in-use.

Most people in this thread probably found out about the Slack 2.5.2 using automated means provided by AutoPkg (or similar tools) and may well have already had it running on test systems within hours of the non-MAS version being released.

I completely understand that there's a major incentive for developers to make sure that for the average user or computer, that the app gets itself up to date. However, I'm pretty sure that if Squirrel can have its update check disabled, per app bundle, using a Configuration Profile, it's not going to result in a new problem category of "regular" users who implement a managed preference on their own machines and are forever trapped running outdated versions of the app.

@paulcbetts

This comment has been minimized.

Copy link
Member

paulcbetts commented Mar 16, 2017

@paulcbetts Please consider the remarks of @timsutton: we consider it a severe security issue to open the permissions for apps on multi user systems. User A can modify the app so that when user B opens it, it will do Bad Things® to his account/files.

I think the best solution in this scenario is to install Slack to ~/Applications for every user, and to set the permissions to 700 - this makes sure that users can't mess with each other, and it also ensures updates work, without having admin access.

@ygini

This comment has been minimized.

Copy link

ygini commented Mar 28, 2017

+1 with all other Mac admins of course. For all the best reasons in the world (Security, UX, Manageability) we need to disable at scale the auto update feature. Especially regarding how broken is it.

Also, @paulcbetts, excuse what I will say in since I'm french and some nuance might be lost in translation, but you should run background check on all people who just contributed to this thread. Those people are among the most recognized and capable Mac Admins. Before, giving really bad advises like installing Slack to ~/Applications you should really consider the amount of skills and devices you're facing in this thread…

@paulcbetts

This comment has been minimized.

Copy link
Member

paulcbetts commented Mar 29, 2017

@ygini You know, everyone says that's a bad idea, but nobody can say why 🤔

@nmcspadden

This comment has been minimized.

Copy link

nmcspadden commented Mar 29, 2017

@paulcbetts Let's look at this proposal logically. You are saying that the best way to manage Slack in every environment is to put into the user's Applications folder, owned by the user, purely in user space.

Let's look at all the scenarios we might have to install software.

1. A user is logged in, and intentionally chooses to install Slack
This is an easy one. A user chooses to install Slack from their management tool of choice, or from the web, and it gets placed in ~/Applications. Note that no software from the Mac App Store does this. Note that by default, ~/Applications doesn't exist. So for a brand new user, this would cause potential friction and confusion, because users aren't used to looking here for software.

2. A user is logged in, and Slack is installed by management automatically
A management tool installs Slack while a user is logged in. That means the management tool has to figure out who is logged in (which isn't that hard), and then place Slack in the appropriate folder in that user's home directory.

Of course, this is problematic if the user's home directory isn't local on the hard drive. Anyone using network homes, or NFS shares, or something to that semblance is going to have a harder time with this. Those are not common scenarios, but they certainly do exist.

3. The machine is logged out, and Slack is installed by mgmt automatically
So now we have a conundrum. We now have a scenario where no user is installed. Where does Slack go at this point? Do we iterate through all the user accounts > 500 and look for home directories that exist? Do we then create ~/Applications folders for them?

Do we just choose not to install Slack at this point?

We can't look in /Users/, because that's just not representative of actual home directories. Home directories can be anywhere (mobile accounts, etc.), and even on separate volumes. Also, user accounts that are newly created but haven't been logged into for the first time may not have home directories exist yet.

So where are we supposed to put Slack now?

4. Multiple users are on a system, all of whom want to use Slack at different times. One user is logged in
So let's say we have a multi-user system, which is especially common in educational institutions or lab scenarios. If one user is logged in right now, so we have the easy choice of putting Slack into that user's home directory (which has all the usual issues described in number 1).

What happens when the user logs out, and a second user logs in and wants to use Slack? Do they now have to install their own copy of Slack into their own home directory?

What happens if we add a third user? A fourth? A classroom of 23 kids? Are we supposed to have 23 copies of Slack, one for each home?

5. Multiple users are on a system, all of whom want to use Slack at different times. NO user is logged in

Then we run into the same problems described in number 3 - where do we put them when the users are logged out? We can't preload them because we don't necessarily know where all the homes are, or will be.

I mean, sure, here's a fun idea: we put a LaunchAgent in place that copies Slack from a central location into each user as they log in. So now we at least guarantee they get Slack, one time. 24 copies of Slack, if we have 23 users (plus the central one).

And of course, with Slack entirely in user space, users are free to delete, modify, or otherwise affect the files of Slack.app. Including choosing not to update it or replacing it with old versions, which you seem desperate to avoid at all costs.

Why are we doing all this work?
Instead, we could put Slack into the one place every other Application typically goes, and where software from the Mac App Store goes - into /Applications. And we could make sure it's owned by the system instead of the user, so that users can't modify it or damage it or delete it.

But as soon as an update comes out, a non-admin user has a bad experience because they're presented with a dialog asking them to update that they can do nothing about, which leads to wasting several people's time to address.

So we're going a crazy amount of work to handle situations 1-5 described above, all because you think the risk of letting people not update software is too high.

Why can't we just turn off auto-update in environments like this?

But you don't want to do that, because then we have the possibility it doesn't get updated. Even though the App Store version goes into /Applications, owned by root, and users can turn App Store updates off and therefore never get updates.

Why are users punished for being non-admins and using the non-App Store version?

That's so un-neighborly for a software vendor, it's almost astounding.

@ygini

This comment has been minimized.

Copy link

ygini commented Mar 29, 2017

@paulcbetts the fact you dont accept others arguments as valid doesn't mean no one has been able to tell why.

Here is a simple summary of what has already been said.

System compliance

/Applications is made by Apple to be managed only by admins. Tricking the system to change the owner of your app make you a bad citizen who break Apple Guidelines.

User experience

/Applications is made by Apple to be managed only by admins. Trying to enforce the software update even if the current user isn't able to do the update without asking for an admin account create a large amount of frustration in your customer base and get you flagged as "not ready for enterprise".

Security

/Applications is made by Apple to be managed only by admins. This isn't for nothing, end user are so easy to trick. If you trust them to do an update or deploy an app, you will endup with all kind of bad things on your network. Do you really want to be in the top 3 of most vulnerable app on Mac after Java and Flash?

This is also the reason why ~/Applications can't be taken seriously. In most network when people has to handle security, applications can't be run from user writable space. Configuration profiles are set to deny every apps located under /Users.

Scalability

Let's consider an app of 100 MB on a network with 100 devices.

If we follow your bad advise, that mean 100 devices reaching Internet over an HTTPS connection to download 100 times uncacheable 100 MB. That's the worst idea ever and will slow the update propagation.

If we follow the pattern adopted by the whole community accros the world, a single server check every X hours all update feed for managed apps and download all updates as soon as possible to publish them on a central repo. Then, this app is automatically installed on endpoints according to the enterprise setup, without any human interaction at all.

This allow us to:

  • enforce scalability with update cache everywhere it's necessary
  • improve user experience by not having to enter admin password on thousand of devices
  • enforce global security by removing the need of human interaction to spread an update without any security issue

And give us in the same time the ability to manage at scale developers errors. We can easily remove a broken update on a infinite number of computer without doing anything except blacklisting a version. And we can adopt preprod scenario where updates are automatically pushed to few users before being pushed few days after to the whole network.

@devtobo

This comment has been minimized.

Copy link

devtobo commented May 10, 2017

@paulcbetts Hi,

When we repair the app, we use the same user/group as the current user - here's the code that does that, from the same file: ...

Is this code fixing the following scenario: A non-admin user installed my electron application in /Applications, when trying to update it:

  1. no admin credentials is prompted
  2. the squirrel.mac download the update
  3. quit and relaunch the application
  4. looping this process forever
@lashomb

This comment has been minimized.

Copy link

lashomb commented Nov 7, 2017

Any updates to this?

@CharlieHess

This comment has been minimized.

Copy link

CharlieHess commented Feb 5, 2018

Paul's update from last year is still current:

  • If Slack.app is able to be updated directly (i.e. the permissions allow us to write to the app), we just do the update, no dialog shown.
  • If Slack can't update, it will attempt to show a sudo dialog so that it can correct its permissions to be writable by the current user. If this succeeds, the user should never see this dialog again.
  • If users aren't admin and they have incorrect permissions, they will see this dialog on every startup. The solution for IT is to fix the permissions via a script, or switch to the Mac App Store version.

With respect to Slack, there is a key that disables just Slack's auto-updates (rather than all Squirrel apps). IT admins can open a support ticket to get that key. Future versions of Slack will begin bannering folks on stale versions though, so if you're not updating it you're signing up for a different kind of annoyance.

If Squirrel.Mac is unable to update, and you're stuck on a stale version like @devtobo, this is also indicative of a permissions issue. Check ~/Library/Caches/com.tinyspeck.slackmacgap.ShipIt/ShipIt_stderr.log and nuke the ShipIt cache with

rm -rf ~/Library/Caches/com.tinyspeck.slackmacgap.ShipIt
@erikng

This comment has been minimized.

Copy link

erikng commented Feb 5, 2018

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

This comment has been minimized.

Copy link

kevinmcox commented Feb 5, 2018

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

@RobertHammen

This comment has been minimized.

Copy link

RobertHammen commented Feb 5, 2018

@erikng

This comment has been minimized.

Copy link

erikng commented Feb 5, 2018

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

@neilmartin83

This comment has been minimized.

Copy link

neilmartin83 commented Feb 25, 2018

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

This comment has been minimized.

Copy link

nilsbyte commented Apr 5, 2018

/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

This comment has been minimized.

Copy link

apizz commented Oct 12, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment