docker in 14.04

[Martin Pitt]

Hello James,

sorry for the very late answer!

James Page [2014-12-18 17:32 +0000]:
> but once stable switches to a new
> release, they currently no longer backport security fixes to the old
> stable release.
> 
> So the current recommendation to fix security issues to to upgrade to
> the latest stable, which will have the required fixes.

That's in fact the position of the majority of upstreams out there,
and why we have to backport individual security patches to our
released versions. So this is nothing special really, we've done that
for ten years. ;-)

> We (as in the Canonical Server team) considered whether we would be
> able to backport security fixes to the version we released with in
> 14.04 (1.0.1)

OK, that's good to know. Hopefully there won't be too many? E. g.
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=docker shows 6 vulns
for 2014, but not all of them apply to 1.0.x.

docker is in universe, so we aren't obliged to maintain this for the
full duration of the LTS. So once we stop being able to backport
security fixes, or that version becomes totally useless for some
(good) reason, a last-resort "exit path" is to replace it with an empty
package in -updates:

  https://wiki.ubuntu.com/StableReleaseUpdates#Package_Removals

This of course will hit deployments pretty badly, but might still be
better than leaving gaping security holes forever.

> I'm also keen that we keep deployment repeatable, meaning that an end
> user of the Ubuntu docker packages can deploy and expand capacity
> without worrying (within reason) that they are suddenly going to have
> a version mismatch on the new servers they just added.

For those cases it seems prudent to always keep "docker" as the
version that we released with? And only introduce new package names
for newer versions, if we want to do that at all.

> For these reasons, I'm proposing the approach of maintaining three
> docker versions at any given point in time.
> [...]
> with separate meta packages to support:
> 
> 	- docker.io-unstable -> docker.io-1.4
> 	- docker.io-stable -> docker.io-1.3
> 	- docker.io-oldstable -> docker.io-1.2

That seems rather complicated, very maintenance intense, and rather
aggravating the problem? Instead of one version which we can't/don't
want to support for long we'd now have an ever-growing number of them.

> Once a docker-io-X.Y package is no longer referred to by a meta
> package, it gets removed from the archive and is no longer installable.
> 
> So this allows end-users to manage their migration between versions,
> by directly using the docker.io-X.Y packages, OR track what we
> consider to be 'stable' or 'unstable' (if people really want to bleed).

This is a contradiction though. If we allow people to install
docker.io-X.Y directly, there is again no upgrade path when you remove
them, and they'd be left with an insecure version forever. But if we
replace them with an empty package, you again break people's
deployments.

I would feel better about this if we'd use -backports for this and
always just keep the latest version in trusty-backports for the users
who explicitly opt-in; of course this also isn't ideal, but no
solution that tries to accomodate stability with fast-moving and
compatibility-breaking upstream releases will be. Users who don't opt
into backports would just keep using the stable one we released with,
for reproducability/reliability.

Another option: if docker really wants to be the fast-moving project
without maintaining stable releases for a nontrivial time, then we
should accept that and not try and keep packaging it into an LTS where
we keep the illusion of stability, if we can't or don't want to live
up to that promise and actually maintain all these versions. In that
case it seems better to directly get docker.io from upstream at your
own pace IMHO. There's times when the traditional distro model and the
fast-moving upstream model collide :-)

So in summary, I'm not sure how this "package N versions in parallel"
is going to help with maintenance effort OR reliability in any way?

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20150121/60e2ef13/attachment.pgp>