Re: Linux Core Consortium
On Thu, 09 Dec 2004 17:20:00 -0600, Ron Johnson <ron.l.johnson@cox.net> 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
Reply to: