Add the packaging metadata to build the mosh snap

[come-maiz]

This is a package for the installation of apps that works in most Linux distributions.
Landing it upstream will enable frequent builds that then can be distributed to many users through the Ubuntu store.

[come-maiz]

You can find more information about snapcraft here: http://snapcraft.io/

To test it in an Ubuntu 16.04 machine:

$ sudo apt install git snapcraft
$ sudo snap install core  # required to build the snap in classic confinement
$ git clone https://github.com/elopio/mosh
$ cd mosh
$ snapcraft
$ sudo snap install *.snap --dangerous --classic

dangerous because the snap you build yourself doesn't come signed from the trusted store. classic because mosh can't use strict confinement as it requires to launch other binaries, and those will need to touch even system files
https://insights.ubuntu.com/2017/01/09/how-to-snap-introducing-classic-confinement/

Once you push it to the store, your users will just have to do $ sudo snap install mosh --classic

Now, in order to achieve independence, every snap can have only one top level command. So with this you would have to call mosh.mosh-server and mosh.mosh-client.
To solve that, we are introducing alias: https://insights.ubuntu.com/2017/01/28/ubuntu-core-how-to-enable-aliases-for-your-snaps-commands/

$ sudo snap alias mosh mosh-server
$ sudo snap alias mosh mosh-client

Final caveat is that in order to connect to a machine with mosh installed from a snap, for now you would have to calal it like this:

$ mosh 192.168.122.74 --server=/snap/bin/mosh.mosh-server

This is a bug already fixed, soon to be released: https://bugs.launchpad.net/snappy/+bug/1659719

If you have any questions or doubts, please let me know.

[cgull]

Thanks, @ElOpio! This build configuration looks about as complex as I expected it to be from reading the Snapcraft documentation (which is to say, not very complex at all).

This looks like a plausible add to mosh, but I do notice a few things in trying this:

• For some reason the snapcraft build removes snapcraft.yaml, so mosh --version reports -dirty in the version number. It would be nice to avoid that and have the version number be accurate.
• I am a bit worried about confusion between /usr/bin/mosh-client and /snap/bin/mosh.mosh-client, at least for a Snappy mosh. There is obviously some magic happening with the aliasing which I haven't bothered to figure out yet. Will this protect Snappy mosh from seeing /usr/bin/mosh-client? If not, then maybe we need to add some smarts to mosh.pl about applying its dirname to the mosh-client command.
• I am also a bit concerned about users having to know that a Snappy mosh-server must be called mosh.mosh-server; that will be extra confusing to users. One way around this might be to actually distribute mosh as two snaps, so that mosh-server can retain its usual name. A mosh-server snap would also avoid the Perl dependency.
• I saw this once after running mosh:
  runtime/cgo: pthread_create failed: Resource temporarily unavailable
  Probably an issue with the Snappy infrastructure rather than Mosh itself.
• Would you have any objection to moving snapcraft.yaml to snap/snapcraft.yaml?
• I assume confinement: classic essentially disables sandbox functionality. It would be very nice to sandbox mosh-client and mosh-server, if we can figure out how to let mosh-server's children escape the sandbox. mosh and mosh-client should be very easy to sandbox. Hmm, this might be another reason to distribute Mosh as multiple snaps.

I'm not sure we'll get this in for 1.3.0, and if we do it'll be labeled highly experimental-- but it should be easy to resolve issues quickly thereafter.

[come-maiz]

Hello @cgull! Thanks for the review :)

I don't see any harm on keeping the yaml during the build. In fact, we are discussing about keeping the yaml inside of the snap, a step closer to reproducible builds. Can you please report a bug? https://bugs.launchpad.net/snapcraft/+filebug

The alias puts the command in /snap/bin, and then it wins the one that it's first in $PATH. By default, /snap/bin comes last in the path, but any user can change that of course.

With the alias, users will not have to know about mosh.mosh-server vrs mosh-server. However, currently they will have to manually enable the alias. It's work in progress to have alias auto-assigned during installation. That has required some discussion on our side because there will be more name disputes with aliases than with package names, so as I said before, all your opinions about this are very useful.

I reported this bug about pthread_create failed: https://bugs.launchpad.net/snapd/+bug/1661863
Thanks for mentioning it!

snap/snapcraft.yaml is acutally the new default location as of last week ^_^ I've pushed another commit.

And I find your last point really interesting. If we split it in two, the client can be fully confined and the server is the only one that needs to be classic and risky. I don't think it's possible to keep sandboxing on the server though, but I'm not an expert on that. If you have any ideas, please share.

I'm +1 on the highly experimental tag. That's what the edge channel in the store is for. If you push it we can get more feedback and maybe more hands to help polishing the snap. And it won't be visible on the store, only the users who know about it will install it.

I've shared all your comments with my teammates.

pura vida.

[cgull]

I've spent a little more time on this.

• I reported the snapcraft.yaml removal issue.
• Right, I was being mixed up about aliases. They do what we need, at least once auto-assignment is in place.
• As for the path confusion issue, I coded a potential solution, it's on https://github.com/cgull/mosh/tree/snapcraft. I think it's OK, but I'm not going to pull that into 1.3.0.
• As for sandboxing and security: I'm not so sure Snappy is a good solution for Mosh, which is very much a systems app. I realized that only mosh-client can be effectively sandboxed by Snappy; both mosh and mosh-server do need wider access to the host system. Additionally as a Perl script, mosh seemed particularly unhappy under Snappy-- it wasn't able to find a standard module when I ran it in devmode, is the Perl story really fully in place yet? I also noticed that snapcraft stripped the setgid bit off /usr/lib/x86_64-linux-gnu/utempter/utempter (but it still seems to work, I don't know how). I think some finer grained sandboxing with AppArmor and/or seccomp may be a better solution for Mosh.

[jdstrand]

Hi! I was asked to comment on the last bullet point:

"As for sandboxing and security: I'm not so sure Snappy is a good solution for Mosh, which is very much a systems app. I realized that only mosh-client can be effectively sandboxed by Snappy; both mosh and mosh-server do need wider access to the host system. Additionally as a Perl script, mosh seemed particularly unhappy under Snappy-- it wasn't able to find a standard module when I ran it in devmode, is the Perl story really fully in place yet? I also noticed that snapcraft stripped the setgid bit off /usr/lib/x86_64-linux-gnu/utempter/utempter (but it still seems to work, I don't know how). I think some finer grained sandboxing with AppArmor and/or seccomp may be a better solution for Mosh."

I'll respond to the individual points raised in this bullet:

• I tend to agree that mosh is not well-suited for strict confinement. It is like byobu or alternate shells in that manner. Based on what was described, it sounds like mosh and mosh-server could be in a classic confinement snap with mosh-client possibly in a strict confinement snap.
• perl not working is perhaps a bug in snapd security policy or perhaps a bug in the snapcraft wrappers for perl. Please file bugs
• snapcraft does strip setuid/setgid off of executables, yes. Without knowing the snap's internals, I suspect that mosh-server was running as a root daemon or mosh/mosh-client was run under sudo and therefore didn't require the setgid bit set and that's why 'it' worked
• as for something specific for mosh, it is always possible to create mosh interfaces that give the accesses mosh needs, however because it is advertised as 'a replacement for SSH' it seems highly likely that any restrictions in the security policy would cause usability issues, just like with other shells. Eg, when running a shell you may legitimately want to load kernel modules, install snaps or other software, etc, etc and anything that gets in the way from a full shell experience would be deemed a bug. 'classic' confinement seems to be the answer for now.

Snappy can be a nice solution for mosh even when using classic confinement IMHO in that it can provide a nice delivery mechanism that you control and this can be tied to things such as travis or Launchpad builds, etc. While the security stance is no different than a deb or rpm in this case, you are able to deliver your software on your terms to multiple distributions with one snap.