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)
signature.asc
Description: Digital signature
-- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
