Squirrel.windows: Thoughts on an alternative machine-wide install

[Andrew-Hanlon]

After recently working with the machine-wide install options in Squirrel, I spent some time reviewing how the google update (omaha) mechanism works:

• Chrome, for example, asks for UAC on install, but falls back to a per-user install if it is not granted.
• With privilege, the application is installed to '%program files%' and the updater is registered as a local DCOM[1] service that runs under the local system account.
• Since DCOM services start on demand when their exposed COM class is requested/instantiated, this service only runs while chrome is being updated (i.e. it's not just constantly running like other annoying 'update services') - in fact it stops immediately if simply run.
• Much like Squirrel today, most of the actual updater work can be handled without privilege, with the service stepping in when required.

It would be amazing if Squirrel implemented a similar approach, possibly with the caveat that per-user is the default install type.

I actually believe that very little would have to change overall for this to be implemented. Most of the same separation of concerns is already implemented in Squirrel. In fact this change would unify machine-wide and per-user installations such that the overall install, uninstall, and update mechanisms work effectively the same way.

The major change would be that rather than simply launching Update.exe as a process, when running from %program files%, Squirrel would first attempt to instantiate the DCOM class, and if successful the arguments passed to a function instead. Otherwise it would require changes like ensuring any hard-coded %localappdata% references use the 'entry exe's parent directory' method that is already available in the code.

Obviously this is a fairly significant change, but if I implemented a pull-request, would this be an idea that could be entertained? I believe it would go a long way to making Squirrel a more enterprise friendly installer.

[stefanolson]

My customers would really like this change. We have a number of issues because customers are trying to use the software with terminal services but it has to be re-downloaded completely every time the user logs in because they don't cache the user folder.

[anaisbetts]

How about this:

1. Per-user install stays exactly how it is, no UAC required
2. Per-machine install via the MSI file registers Update.exe as the DCOM object

I'd be into this proposal, if we can get around the technical problems with it.

Much like Squirrel today, most of the actual updater work can be handled without privilege, with the service stepping in when required.

This is the hard part, because unless you are very very careful, this is a local EoP waiting to happen. Some questions:

• What happens if you install >1 MSI on your machine and they both try to register the DCOM object? What happens when one of them gets uninstalled and takes the registered DCOM with it?
• Local Service doesn't have network access. Does Update.exe running as that user get to do the download? How does Update.exe DCOM verify that this download hasn't been tampered with? (i.e. evil process creates a fake update, then calls DCOM "Hey Install this!", now local users w/o privs can write to Program Files)
• How does DCOM service know what it's allowed to write to and what it's not? Just its own folder? Goes back to the first bulletpoint

If we can answer these questions in a non-crazy way, it'll probably make Slack customers very happy /cc @alirayl, but the reason I've shied away from the service approach is because it really is very easy to write an update service that compromises security, even if you're careful

[Andrew-Hanlon]

That was my exact thought regarding making Update.exe itself also act as the service, and it is fairly easy to implement following the first link in the OP.

Your points:

• There would need to be a way of configuring the service and COM Type parameters like name/description/guids such that each service is unique.
• Originally I thought 'local service' but actually Omaha runs as 'local system' and does the downloading itself. This might need to be the way forward since applying arbitrary updates from outside of the services' boundaries would be dangerous. This would certainly require more surface area for the service than a simple 'hey apply this release' method.
  
  
  
  • The other option is to use some form of SSL type signature such that the service can verify that a nupkg is legit. The hash could be generated during releasify and included in the RELEASES file.
  
  
• As long as the installer and updates can be verified to be who they say they are, then I don't think it is Squirrel's concern what the installer and updates do (outside of correctly following the programmatic intent).

[StefanKoell]

I just want to chime in here as this thread is quite old and still open. I'm looking into Squirrel for my apps (.NET WinForms and WPF) and I really like the general idea, especially with the delta updates.

However, my app is also heavily used in enterprises and if I switch from traditional MSI to user based installations using Squirrel, I already know the outcry I get from all those who wants/needs to deploy the app on their own terms using some sort of MSI/SCCM/whatever. Also all those companies with terminal servers will not be very happy.

My question, I guess, is: is the above in the works or is there some sort of workaround to please both camps (the ones who prefer user based installes and the ones in enterprise environments)?

[anaisbetts]

My question, I guess, is: is the above in the works or is there some sort of workaround to please both camps (the ones who prefer user based installes and the ones in enterprise environments)?

In general, the advice I give for Enterprisey People, is to use Squirrel's MSI deployment but create a separate update channel, the "LTS Update" channel. It still updates automatically, but less often than your standard version, and the timing of those updates is scheduled beforehand (i.e. IT Admins will know months in advance, "This app will be updated on day X"), and give them a link to the new version early so they can run it in a test env.

This gives IT Folx the predictability and safety they're looking for, but doesn't sacrifice automatic updates.

[StefanKoell]

That is great advise! Thanks, Paul! I'm still a bloody newbie with Squirrel and will work my way through the docs once I have to deal with the CI/CD pipeline. I may come back with some questions but so far this looks really promising...