[ On Tuesday, November 11, 2003 at 13:08:57 (-0500), Thor Lancelot Simon wrote: ]
> Subject: Re: attempt to plant a back door in the Linux kernel
>
> On Tue, Nov 11, 2003 at 01:25:31AM -0600, Andy Isaacson wrote:
> > 
> > Furthermore:  when a clone is made of a BitKeeper repository, the
> > resulting repository is a fully functional duplicate of its parent.
> > Every peer who has downloaded a copy of the Linux BK tree has a complete
> > revision history, so there's no master copy to compromise -- if Linus'
> > tree were modified by an intruder, he would be able to compare it
> > against any other copy of the tree to find the changes.  (And in fact,
> > Linus has several trees; the ones on his main work machine and the ones
> > on kernel.bkbits.net, to start.)   It's not completely secure, but BK
> > does make the attacker's job enormously more difficult than a
> > centralized, there-is-one-repository CVS system.
> 
> The above paragraph is almost completely specious; all of the assertions
> made about copies of BitKeeper repositories are equally true of copies of
> CVS repositories, and the implicaiton that, for example, our CVS repository
> is "centralized, there-is-one-repository" and thus somehow more vulnerable
> than the Linux BitKeeper repository is quite simply and entirely false.

True enough to some extent, though there are important differences
between the way CVS is used in projects like NetBSD and the way BK is
used for the Linux kernel.

On first light the risks of an unauthorised change to a copy of a
repository migrating back to any "official" repository seem quite
similar for both BK and CVS.

However with BitKeeper commits can be, and often are, made to any copy
of the BK tree and change sets can be moved between copies of the trees
without loss of any metadata.  There really and truly is no one master
BK tree to compromise and there are a multitude more ways and means to
compare whole BK trees and individual change-sets, and IIUC Linux kernel
developers do regularly compare change-sets and read change-sets.  I
suspect Linus himself compares his own change sets as he moves them from
one of his BK trees to another, and what Andy writes above seems to
confirm that.

With CVS there really is only one centralized master CVS repository for
any and every project using only CVS in the "normal" way, even though
many read-only copies and mirrors of that repository may exist.  Commits
are only made to that one master repository and changes are distributed
to other "slave" repositories by copying or opaquely updating the
internal repository file structure, not by moving change sets (except
maybe in the case of the FreeBSD CTM diffs-by-email service).

As a result, if I understand correctly, it is more likely that every
change will receive more careful scrutiny by more eyes and by more
commonly used tools with BK than with any centralized repository system
like CVS.  For example even though I have a copy of the NetBSD CVS tree
on my local development server I have no easy/direct way to compare
changes in my repository with what should be the same changes in some
other copy of the repository, and indeed with the centralized CVS
approach I have no expectation that I would ever need to do that (unless
maybe I was worrying about corruption occuring somewhere along the wire
during file transfers).  My only options at the moment are either to try
to obtain another copy of the repository by some other channel and then
to compare the internal repository files in each copy, or to ask someone
to send me diffs from their copy of the repository so that I could
compare them with the same diffs from my copy of the repository.  Either
way I'd have to be suspicious of something before attempting such
comparisons.

It may not be fair though to compare this particular event with any of
the similar risks in a CVS-only project.  The purpetrator of this
incident may not have intended to get the change into any "official"
copy of the BK trees used by Linus et al, but rather only to have the
change stay in the public CVS mirror such that it would only affect
those solely using the CVS mirror.  While such an exploit would have a
narrower audience, that may also have made it more difficult to detect
had automated tools not caught it at its origin.  Perhaps the intent was
only to raise fears about Linux and/or open source security rather than
to introduce a flaw in every copy of the Linux kernel.

The risk of a similar exploit against NetBSD (e.g. an unauthorised
change being introduced into a copy of the repository that's used by
many people) might actually be much greater not because of the use of
CVS but rather because far more NetBSD users might build their own
kernels from source obtained from such a copy of the repository instead
of just downloading "official" kernel binaries that would likely have
been built from sources checked out from a pristine copy of the
repository.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>