On Thu, 09 Dec 2004 17:20:00 -0600, Ron Johnson <[EMAIL PROTECTED]> wrote:
> libfoo 1.7 fixes a non-security bug in v1.6. "bar" segfaults when > running libfoo 1.6. But libfoo 1.6 is in Sarge, and the bug won't > be fixed because it's not a security bug. Having a formal GNU/Linux Distro Test Kit would help organize this process. Suppose that sarge validates against DTK 1.0, the vendor of "bar" contributes a new test case which is accepted into DTK 1.0.1, and DTK 1.0.1 runs against sarge + libfoo 1.7. Then we'd be in no worse a position than Other-Distro 14.7 which also included libfoo 1.6 and validated against DTK 1.0 -- except insofar as commercial distros are more likely to silently roll DTK 1.0.1 and libfoo 1.7 into 14.7-updates, which isn't the way Debian handles stable. This could be handled with "overlay" repositories that handle bug fixes within a DTK minor version. In the case described, "bar" depends on validated-with-dtk (>= 1.0.1, < 1.1), validated-with-dtk 1.0.1-1 depends on libfoo (=1.7-1), and you need to have packages from the validated-with-dtk 1.0.1 repository in order to install "bar". A security fix to libfoo 1.6 (in stable) would need re-validating against DTK 1.0, and might also need to be done on libfoo 1.7, resulting in validated-with-dtk 1.0.1-2 (built to depend on libfoo 1.7-2). I actually think trying to handle this with a validated-with-dtk package is a kludge, but it doesn't require any new development (except, of course, the DTK, and perhaps automation of propagation into the overlay repositories). One of these days I will get around to doing a more competent job of proposing "Signed Package Integrity Tokens" (my last effort wasn't worth SPIT :-) as a way for ISVs to self-service (or delegate self-servicing) at the level of functional test and validation. Either approach partitions the problem of security/bug-fix management so that ISVs and their customers can contribute to things that matter to them. The DTK needs to be re-run, and the validated-with-dtk dependencies updated or the PITs re-signed, any time there is a security update to the relevant packages. Security updates themselves multiply because they may hit the versions in the overlay repositories as well. But at least it's possible to estimate the resource cost of maintaining the various overlays, and it's clear what the criterion for adding an overlay package is -- a DTK update that fails without the overlay. Note that many of the core packages we are talking about already have extensive test suites, so the DTK could get off the ground by adapting them into tests of the package in its installed state instead of build-time tests. This would make it pretty easy for an ISV to prototype a test within the DTK, send it to upstream (the same test runs in the build-time test framework), and get the bug fixed (or feature added). Obviously there aren't any new ideas in this (DejaGNU, anyone?) and it's not a panacea. The LCC's proposal is just a special case of this -- a DTK that verifies the checksums of the common binaries :-). But I prefer an approach in which I can verify when and why the contract between distro and ISV changed, so that I can make reasonable decisions about whether and how to replace distro binaries with builds that meet my own needs better. Cheers, - Michael
