docker in 14.04

[James Page]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Martin

On 21/01/15 15:25, Martin Pitt wrote:
>> 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. ;-)

Yup.

>> 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.

I think you missed my point about regression risk for security
backports being very high; as the docker codebase is evolving so
quickly, straight low risk cherry picks are not possible; this makes
back-porting of any security fixes time intensive requires expert
knowledge of the code for re-factoring fixes for older code-bases.

> 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.

Agreed.

>> 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.

We would have a maximum of three, for which the majority of effect can
be automated.  These would be managed on a published cadence so its
clear to everyone how long they can expect to get version x.y from the
Ubuntu archive.

>> 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.

The upgrade path is for those users to switch to the new version which
they can do inline with their test process/cadence cycle; albeit they
do need to-do that migration within the published cadence for
'oldstable' removal.

> 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.

We could do that; but the effort to maintain any level of security
support around the release version will be large.

> 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 :-)

I'm proposing that we don't maintain any illusion of stability for
docker, but we have a way to help users manage the risks of upgrading
between versions and maintaining some level of security.

Cheers

James
- -- 
James Page
Ubuntu and Debian Developer
james.page at ubuntu.com
jamespage at debian.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJUxrAGAAoJEL/srsug59jDH7sQAJh0V7V+0sRAss3TdxgFE1EE
rKua2biHef42ODqiVDQKToFZ9Wj3XW+UGJ77N9YNT0YFsj3tH1ad4oVCtn++BBNt
uy/Y2hioCX49A8arcRq6p4xXo6wYottj0A6B/0/GI/IQNNZQo8+dGprO7FgxnLZ/
uFkNJf9A/pXIMZ/eo8n70KT7q1hA6YGg5dooZEqjcGd5uS61RnOrxx6+1JBbiey2
He8z/GUrl+zrzgAY7DQgz/4KwpQPIskI9hoY2F6rcBHDBpdaJQJoUANTjRZaQXBC
EdEhqIWn0/LOnWzogA3ovGCvu6hjhmhMdHMbuPnrpNobA2OMB9x2ZYxL9RGWVC39
KWJw1BQo0Rzbkm+/FYIA0gYv9m9BPxwIV3+7J00vs6+pjVTtMPFow8By4MRYsb9K
6CqlK4tTbM9tQn2/KRs11lHFEx+7wHe4hZB4Iulx6RsRxmCn9bRe0wiuGrM6MjPb
XH5IrM0sx0BuoER1MJZYiTG4F+CBW+SC6J+v8GsvlvnrlnkSQP+UTeBf0MemaJ8r
sbHPgdnCZhEfemEjPwK3gK38qd4Piq3AqoTwAd7q6qt4nXXVl0EXc5VaAyKiNMRe
oHyRKiKmUN5GiNPWYACFF7VtaLFMBJyYz671JbP33pMD9KOoo/UtYhvoME+f6zwI
/mbmVGcbwwbgzODz3Q7F
=iZcU
-----END PGP SIGNATURE-----