-----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.p...@ubuntu.com jamesp...@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----- -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
