[mosh-devel] snap package for mosh

[Keith Winstein]

Thanks, Leo. Do you already have snaps for similar programs (e.g. screen,
tmux, ssh)? Mosh is probably going to have similar needs to those re: the
isolation or "plugs".

Generally we add new platforms/distros when somebody submits a PR or
volunteers to be a maintainer; my suggestion is for you to just submit a PR
with a proposed snapcraft.yaml (and changes to .travis.yml if appropriate)
and we can all try it out.

Cheers,
Keith

On Fri, Jan 13, 2017 at 7:56 AM, Leo Arias <yo at elopio.net> wrote:

> On Thu, Jan 12, 2017 at 11:59:53PM -0800, Keith Winstein wrote:
> > Right now we have a Debian package, which we maintain in our own source
> > tree, and which we upload to Debian every time there's a new release.
> That
> > flows into Ubuntu as part of the normal release schedule. For users who
> > want something more immediate, we also have the mosh-dev PPA that pulls
> > from our GitHub repository once a day and auto-builds the Ubuntu source
> and
> > binary packages, and then we have a "stable" mosh PPA as well, which only
> > gets updated on new releases.
>
> That is great because we would love to hear your impressions, taking into
> account your experience with debs and PPAs.
>
> In classic Ubuntu you have to follow our 2 years/6 months release cycle,
> or use
> a PPA. When you release a deb to an LTS, you will quickly get many users
> in an
> outdated version for many years, you need maintainers to review your
> package to
> make sure it's compatible with the archive, and you need to follow a
> heavy-weight format full of conventions and rules to make the archive
> consistent. debs are great for some projects and some users, and we are
> using
> them as a base for our new Ubuntu Core distro; but something like getting
> the
> mosh 1.3.0 to xenial, or even to trusty, it's a huge pain.
>
> That's what we are trying to improve with this new dev experience. Snaps
> are
> mounted read-only directly from the uncompressed package and they bundle
> all
> their dependencies. So there is no conflict between snaps, nor with the
> base
> system, and then we can get out of your way, you don't need the distro as a
> middle man and you can just push to the store any version you want, any
> time
> you want.
>
> Snaps are also isolated to their sandbox for security reasons. But there's
> where things get interesting with mosh...
>
> > Is it possible to teach Launchpad to also auto-build a snap once a day
> (if
> > our Git repo has changed), alongside the PPA .debs? Can we script
> Travis-CI
> > to automatically build and push a snap each time it runs a successful CI
> > test on the master branch? Or how would you recommend we do this?
>
> Yes, we want the snapcraft.yaml metadata to be as simple as possible, and
> to
> use continuous deployment, so you will just have to spend a little time
> packaging one time, and then everything is automatic. You can take a look
> here:
> http://snapcraft.io/docs/build-snaps/ci-integration
>
> > Mosh is pretty simple so I doubt we're going to be pushing the boundaries
> > of the snap format -- it's basically two unprivileged binaries and some
> man
> > pages. And a bash-completion script that gets put
> > in /usr/share/bash-completion/completions/mosh. I guess that might be a
> > little more interesting, depending on whether snap can handle that.
>
> If I understand correctly, the mosh server is a terminal emulator. (I'm not
> sure about mosh internals, so I'm eager to understand more about that too
> :)
> By default, snaps can't do anything outside of their confinement, so things
> like calling binaries they don't provide or accessing devices will be
> blocked.
> And that's good enough for the vast majority of applications out there,
> they
> just declare a few "plugs", like listening to the network, and they can
> fully
> function. But now we are turning our eyes to also support developer tools,
> like
> emacs which needs to be able to read and write to /etc, or a shell like
> zsh, or
> mosh.
> They pose a bigger security risk than normal apps, but still we think it
> should
> be a direct agreement between the user and the developers distributing that
> package. So you would declare on your snap the kind of things that your
> application will do out of its confinement, and the user decides to grant
> that
> permission or not.
>
> > Happy to work with you on this if you think there is user demand for it.
>
> Well, I'm sure it will make it easier for you to do early testing of the
> new
> release, and once you are ready to release to the stable channel, many of
> your
> users on current Ubuntu versions will find the update in the store and
> make the
> jump.
>
> But as I said above, we are trying to make it extremely lightweight, so it
> shouldn't take a lot of your time. Developers usually just start by
> dumping an
> existing binary into the snap, and use the devmode confinement to get a
> list of
> the security exceptions that they need. Then if you like, you can build the
> binary during the snapcraft packaging, which will make it easier to
> provide the
> snap for other architectures.
>
> I'm about to leave for vacations, so I encourage you to take a look at
> http://snapcraft.io/create/ and give it a quick try. Then when I return
> the
> following week I would be happy to answer any of your questions, and give
> you a
> hand with the packaging if you need it.
>
> I'm sorry for the long email, but I'm excited about snaps and mosh, and
> really
> eager to hear your comments :)
>
> pura vida
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20170113/6343f9a3/attachment.html