Re: RFC: Central version control for Debian
On Thu, Feb 01, 2001 at 10:22:56AM +0100, Bart Schuller wrote:
> On Wed, Jan 31, 2001 at 11:40:03PM -0500, Matt Zimmerman wrote:
> > - Repackaged upstream source (DBS and similar). Unfortunately, this includes
> > several important packages, especially in the context of a security audit:
> >
> > gcc-2.95 libnss-db pam silo
> > glibc openldap2 ppp yaboot
> > gpm openldap shadow zlib
> >
> > I don't know what to do about this last set of packages. Perhaps
> > maintainers of these and similar packages would like to speak up about what
> > they gain from using such a format, and how we can come up with a solution
> > that meets their goals without compromising a CVS effort. As far as I
> > know, these benefits
>
> Tell us again why you are basically taking over these packages from their
> maintainers.
Pardon? I'm not taking anything away from anyone. I'm performing an
experiment, seeing whether it is feasible and useful to check a subset of
Debian sources into a CVS repository. This thread shows that several
developers have an interest in the idea, and I'm trying to find out how it
works in the real world.
> What is it that makes it easier to audit gcc-2.95 and silo by having them in
> the same CVS repository?
Well, the advantages of having them in CVS should be obvious. As for having
them in the same repository, I don't suppose it makes much of a difference for
two packages, but having 142 packages coming from 100 repositories is not a
very maintainable architecture. The best way to ensure that everything is
accomodated with enough disk, bandwidth, uptime, maintenance, etc. is to
centralize it.
> I just don't get it. If a piece of software could use a security audit, who
> is the first person to talk to?
>
> The upstream maintainer
>
> And the second person?
>
> The Debian maintainer
>
> What is it that made you jump these two steps? We've seen that the OpenBSD
> approach amounts to a fork, and you are trying to do the exact same thing.
Asking maintainers to do audits doesn't work. Having everyone audit their own
work defeats the purpose somewhat. The more eyes, the better. Are you
suggesting that I file a bug against every package I'm working with asking the
maintainer (and/or the upstream author) to please audit every line of code and
then close the bug? I'd spend a lot of time nagging them and tracking down who
has done what, and that's time better spent reading code. Most of them would
never get around to it, and it would end up being done by somebody else anyway.
As for the ones that did, what about quality control? What can we really say
about 142 software packages audited by 100 different people? Can we have any
assurances about the result?
Auditing is not a procedural effort. One can't follow a set of steps and say
at the end that the program has been "audited" and is now safe. It is a fuzzy,
qualitative process, and can't be automated in any meaningful sense.
A better strategy is to have a small group of volunteers go through the whole
batch of source code at once, and submit the fixes to the appropriate
maintainers.
> Yet I have a huge filesystem with CVS checkouts from all kinds of different
> projects, all living nicely together. I'd have to look into the CVS/Root
> files to find out whether they belong to the same repository. What makes this
> setup so different from what you're proposing?
Not all Debian maintainers use CVS, and of those that do, even fewer have a
system on which to host a CVS repository full-time.
Rather than storing all of the Debian archive on centralized servers, why not
have the server NFS mount filesystems from developer's machines? It doesn't
scale.
> Instead, what would be useful is a database with a subjective evaluation of
> every package with regards to security. Anyone so inclined could then pick a
> package and start contributing *to the upstream source*. Because that needs
> to happen sooner or later anyway.
And it will, through the normal channels. This is not OpenBSD. Any bugs that
are found will be fixed forever (upstream and sidestream, to other
distributions) whenever possible. OpenBSD learned the hard way that a lot of
important software is not always responsive to these kinds of improvements. We
will be relying on Debian maintainers' individual relationships to upstream
maintainers to give us better communication with upstream.
--
- mdz
Reply to: