[snap] migration from strict to classic enclosure

There’s some outstanding problems with our use of the strict enclosure for the Snap installer:

• #95
• #98
• #59

Essentially, a Snap in a strict enclosure is not able to launch any processes outside it sandbox. This affects some of the important integration for Desktop, such as being able to launch your configured editor or shell.

After talking it over with various Snap team members there appears to be no easy solution for this, other than switching enclosures. But that in itself is a really hard problem, because there’s no way to upgrade a package which changes it’s enclosure setting from strict to classic (which is basically unrestricted). This is why we’ve temporarily disabled the listing on the Snap store to prevent more people installing this app and then facing this problem: #108

The solution we have figured out is a bit rough, but looks like this (paraphrasing an earlier discussion with @flexiondotorg about this):

Preparations

• ✅Make a request for GitHub Desktop to be approved to use classic confinement
• ✅Create a branch named snap-strict-enclosure. This will contain the old version with the strict confinement that we need to use later.
• ✅ Create a pull request to restore the classic confinement: #117
• ✅ Create a pull request to add a prompt for users running edge with the strict enclosure to manually migrate to the beta channel with the classic enclosure: #118

This Week

• ✅ Friday 29th March
  • Merge #117 into linux
  • bump the version to release-1.6.5-linux6
  • tag and publish from linux to the beta channel
  • confirm the version in the beta channel is working as expected with the classic enclosure

Next Week

• ✅ Monday 1st April -> Sunday 7th April
  • add documentation to README about Snap migration - #135
  • Merge #118 into snap-strict-enclosure
  • bump the version to release-1.6.5-linux7 so it is ahead of beta
  • tag and publish the snap from snap-strict-enclosure to the edge channel
  • as strict enclosure is unable to invoke spawnSync we need a more robust way to detect the versions installed on edge
  • confirm the version in the edge channel is working as expected
  • make the snap public again so new users can install (either from edge or beta) - closes #108 #95 #98 #59

At this point existing users of the edge channel will receive the update and see the notification to transition manually to the beta channel.

Post-Migration

• allow time for edge installs to migrate themselves over to beta
• at some point, publish a version on edge that uses the classic enclosure
• cleanup the Snap migration warning once a sufficient % of users have migrated

[shiftkey]

It’s been almost 2 months since I did the cutover to beta and published the dialog about getting people to migrate from edge to beta. We had almost 400 installs at the time:

Fast-forward to today and we still have 300+ active installs of edge:

I was really hoping that this number would be much lower, as I’d love to start exploring using edge as a preview channel for things like Electron upgrades and experimentation. But I can’t do that if users are ignoring the warning and still running the wrong enclosure.

A few ideas to make this more aggressive and see if it helps move people off edge:

• make the wording more explicit about what the user needs to do
• show the dialog every 30mins (or hour) while the app is running, rather than just on launch
• show the dialog but then close the app when it’s dismissed to essentially bomb the app

[zypA13510]

You need to remove (or make optional) the requirement to run this with classic confinement.

I can think of one way to make this optional - build another snap that’s under strict confinement and publish it via a different name, e.g. github-desktop-confined. However, I’m not sure this is worth the effort, see my points below.

As far as I’m concerned, this defeats the whole point of using Snap. If I didn’t want confinement, I would just install the .deb package.

Yes, I agree that using snap without confinement is somewhat pointless, save for the auto-update. But, if you didn’t want a GitHub Desktop with shell, editor and file explorer integration, what are you using GitHub Desktop for? View git tree? gitk --all can do just that (and more, like cherry-picking or tagging). Stage files for commit? Atom or whatever IDE you use will probably have that built-in or provided via a plugin. As far as I’m concerned, GitHub Desktop is more about integrating the workflow, and if those integration features are all missing, this defeats the whole point of using GitHub Desktop.

I am not installing some random code from Microsoft of all people with unconfined access to my system! I understand that this currently brings with it several limitations, but that’s better than opening up my entire system to random code from the internet.

It’s not some random code, it’s code in this repository that you can review or even build yourself. This is open-source, if you so desire, you can fork it and switch it back to strict confinement, build, install, and use it. No-one will keep you from doing that. The question is, should we build broken snap by default, what do most users expect?

And it’s not just GitHub Desktop, vscode, atom, webstorm, sublime, android-studio they all do this, all of them requires classic confinement to function properly.

And if you don’t trust the source, the best and only solution is to not run it. Would you run an email attachment from an unknown sender, even if in strict snap confinement? Would you run malware in a VM? Who knows it won’t utilize some privilege-escalation vulnerability and break out of jail? At some point, you have to trust something.

Eventually I’m sure snapd will have a proper interface for running external editors or whatever the issue is that motivated this change

That would be great and eventually we can switch back to strict confinement without this discussion.