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

[bochoven]

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

[smashism]

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

[timsutton]

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]

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

[arubdesu]

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

+1 , it's certainly odd and annoying.

[fakepaulbetts]

fwiw, Slack will be fixing this via chown'ing itself in the next version

On Wed, Jan 18, 2017, 18:44 innermotion notifications@github.com 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 .

[gregneagle]

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]

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 notifications@github.com 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 .

[gregneagle]

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]

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 paul@paulbetts.org 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 notifications@github.com 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 .

[timsutton]

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]

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

[joshaber]

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

[timsutton]

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]

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

Yup, I think mirroring Sparkle would make sense.

[anaisbetts]

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

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]

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

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]

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

[timsutton]

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]

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]

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]

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

[RobertHammen]

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

[foigus]

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

[nealdav]

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]

Company with about 2,000 macs as well.

[anaisbetts]

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]

What are the expected permissions?

---

From: Paul Betts notifications@github.com Sent: Wednesday, March 15, 2017 5:30:19 PM To: Squirrel/Squirrel.Mac Cc: Erik Gomez; Comment Subject: Re: [Squirrel/Squirrel.Mac] System or bundle-specific default for disabling updates and helper tool installation (#192)

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

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/Squirrel/Squirrel.Mac/issues/192#issuecomment-286922131, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFa_GL7m4fVvynhYW-5GoBwjwO0rENQDks5rmIKbgaJpZM4LCvT2.

[anaisbetts]

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

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

[anaisbetts]

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]

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]

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

They can't force the user to update and they can't silently update the user either.

---

From: Timothy Sutton notifications@github.com Sent: Wednesday, March 15, 2017 6:12:34 PM To: Squirrel/Squirrel.Mac Cc: Erik Gomez; Mention Subject: Re: [Squirrel/Squirrel.Mac] System or bundle-specific default for disabling updates and helper tool installation (#192)

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?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Squirrel/Squirrel.Mac/issues/192#issuecomment-286928322, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFa_GFFRwZfrhMmt6j21eV9fDyWKW2lFks5rmIyCgaJpZM4LCvT2.

[anaisbetts]

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]

People who intentionally block/disable updates or simply choose to not install them.

I could strip the MASReceipt on Slack.app and Slack would never be able to update again as it no longer contains the purchase information and associated AppleID.

---

From: Paul Betts notifications@github.com Sent: Wednesday, March 15, 2017 7:26:25 PM To: Squirrel/Squirrel.Mac Cc: Erik Gomez; Mention Subject: Re: [Squirrel/Squirrel.Mac] System or bundle-specific default for disabling updates and helper tool installation (#192)

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?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Squirrel/Squirrel.Mac/issues/192#issuecomment-286939472, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFa_GDws1b9mLm07SgZyiJnAqYxbTQYJks5rmJ3RgaJpZM4LCvT2.

[anaisbetts]

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

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

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

[anaisbetts]

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

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

[anaisbetts]

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

[nmcspadden]

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

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

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

Any updates to this?

[CharlieHess]

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