[MIR] snapd in trusty

[Michael Vogt]

I'm not familar with the MIR process if a package is already in main in other releases. I will just do it as a regular MIR bug.

[Availability]
- available in Ubuntu 16.04,16.10,17.04 in main
- available in Ubuntu 14.04 in the trusty-updates pocket in universe

[Rationale]
- the package is important for our users to get the latest snaps from upstreams and other vendors (e.g. mysql)

[Security]
- we have an active team of maintainers around the snapd codebase
- the Ubuntu security team is very involved with snapd and provides review and guidance and code

[Quality assurance]
- runs the unit tests during build
- uses autopkgtests with an extensive test suite
- active bug triage community

[Dependencies]
- dependencies are bundled via the go-vendor system because it would require too many backports to trusty

[Standards compliance]
- standard compliant expect for the use of the non-standard /snap directory

[Maintenance]
- actively maintained by a team inside Canonical

[Background information]
- snapcraft.io :)

[Michael Terry (mterry)]

Oh yeah this is a weird situation. :) I guess it would normally make sense to re-review if the potentially older code was different than what was previously approved.

In this case, the code is the same as the newer releases? So I normally would expect a MIR rubber stamp.

BUT... the MIR team is not happy with snapd these days. See bug 1658181, which is a big security and MIR policy violation, implemented just a few months after getting MIR approval last time around. (Presumably done specifically to support trusty? I don't know, because no one that knows why it was done has commented.)

So bug 1658181 is a blocker. Though oddly, for trusty specifically an exception might be able to be made because the golang packages you need may not be in the archive. But for all *other* releases, it's definitely a blocker, after the fact. But that's not what this bug is about... I'll assign to security team to see what they want to do about supporting this.

[Seth Arnold (seth-arnold)]

How are we going to handle snapd's use of systemd on trusty?

Are we teaching snapd how to drive upstart? What portions of snap's security story are provided by systemd? How much work has been done to teach upstart suitable replacements?

Are we backporting systemd to trusty and untangling upstart from all services? All services in main only? Or some co-mingled systemd+upstart shared responsibility for system services?

It feels to me like there's a great many open questions about snapd on trusty still.

Thanks

[Thomas Voß (thomas-voss)]

@Seth: We are deploying a deputy or subordinate systemd not running as PID 1 on trusty to support snapd. We isolated systemd on trusty away and minimized its interaction with the system, except for the functionality required by snapd. That is, upstart is still PID 1 and responsible for all system services but snapd.

All adjustments to systemd have been properly SRUd and reviewed.

[Tyler Hicks (tyhicks)]

In general, the Ubuntu Security team is ok with snapd going into main in 14.04.

We trust that the snapd upstream developers will be responsive in fixing security issues and there's a documented history of them performing SRUs to stable Ubuntu releases. We can depend on them to prepare any necessary security updates and perform QA prior to the updates being published.

@mvo please confirm that what I said above is true.

As for the question of bundling, as long as the upstream project has a close relationship with the Ubuntu Security team, there's a demonstrable history of regular SRUs, and the dependency does not exist in the stable Ubuntu release, I'm reluctant but ok with bundling of new dependencies in stable Ubuntu releases.

There are some open questions about how much help the Ubuntu Security team can actually provide in tracking security issues in snapd's bundled dependencies. We currently have no convenient way of determining existing bundled dependencies in snapd and have no notification mechanism when upstream adds a new bundled dependency. I'll discuss this more in bug 1658181.

[Michael Vogt (mvo)]

Yes, I can confirm that the snapd upstream developer will be responsive in fixing security issues and we have experience in preparing SRUs for trusty (and the other releases of Ubuntu).

[Tyler Hicks (tyhicks)]

Moving this back to New since mvo has addressed all feedback.

[Zygmunt Krynicki (zyga)]

Is there more action needed on this bug or can it be closed now?

[Mathieu Trudel-Lapierre (cyphermox)]

Setting this to Fix Committed.

There has been feedback from the Security team, feedback was addressed, and it seems that in any case bundling of Go dependencies in trusty is more or less "unavoidable".

MIR team ACK on promoting snapd to main in trusty.