Notes from the version control BOF at the summit

[Tom Lord]

    > From: Paul Koning <pkoning@equallogic.com>

    >  Tom> A fine point:

    >  Tom> Signatures in a revision control system (as in arch) can
    >  Tom> aid in _discovery_ of a break-in.  [....] Signature
    >  Tom> checking built-in to the revision control system
    >  Tom> guarantees (or should, anyway) that bogosified data is
    >  Tom> never used -- it's detected as being bogosified as soon as
    >  Tom> it matters. [....]

    > I must be missing something here.

    > SSH (as currently deployed in the GCC project) uses digital signatures
    > for authentication.

    > So right now we have digital signature protection.  

    > If the repository servers are otherwise secure, you'd need to
    > break SSH to compromise CVS.

That's correct.  Monotone and Arch provide an additional level of
security.  If a repository server _is_ cracked, but is not the home of
any private keys used to create trusted revisions, clients still can
not be harmed.  Someone may try to inject malicious code in the
archive but this attempt will fail because any client reading the bad
data from the server will immediately recognize it as such because of
the missing or incorrect signature.


    > Or did you mean cryptographic checksums (e.g., md5sum) computed and
    > recorded at the repository server?  [....]

What Monotone and Arch have in common is that when a client commits,
the packet it transmits can be cryptographically signed and,
critically, when a client reads the data associated with that commit,
_it_gets_back_exactly_that_same_packet_.  

So, authentication is between a committing client and all future
readers of that commit, no authentication with (or trust of) the
server is necessary.

You can understand Arch and Monotone pretty well by imagining doing
more or less what they do, but by hand.  People did, in fact, used to
work this way commonly (before CVS gained client/server support):

I can record the history of a software project by

  1. Storing a src.tar.gz, a complete copy of the project
     on day 0.

  2. For each interesting change made to the project, store
     a src.patch.gz, a patch file, essentially, describing
     the change.

I could sign all of those.  They could be trivially mirrored.  They
could easily be incrementally mirrored.  We could broadcast
incremental updates on FTP sites or in usenet messages -- many
different ways.  The transport for moving this data around can be
almost anything.  The signatures are what secure the communication
freeing us to use untrusted channels to broadcast incremental updates.

You, reading these updates, would get a complete history of my branch.
You might want to put it in a more convenient form, of course, but you
can do that locally where it will do you more good anyway.   

Add in some tools to look at a database of these packets (or an
optimized database built from them) and

	extract historic revisions
        merge things in various ways
        describe the history of a revision
        form related branches of development
        etc.

and, voila, you've got Arch or Monotone.

Also notice this: the little packets in my hypothetical project, the
.diff.gz and .tar.gz files, are all independent of one another.  There
is no reason they all have to live in the same archive.  So long as we
have some naming scheme to keep track of which .diff.gz goes where, we
could let _anyone_ publish new .diff.gz and .tar.gz files, from
anywhere, and that would be a form of distributed branching.   For you
example, you might create a directory related to my project and put a
rev23.diff.gz there, with the understanding between us that that is a
patch designed to be applied to my revision 23.   We have distributed
revision control!

That's really "all" these systems are, at core.

If you want to understand the differences between Arch and Monotone
you have to look into the details of those common elements.  They
store patches differently, for example.  They handle renames
differently.  They differ in the selection of merge tools offered.
They differ in their approach to naming revisions.  They differ in
their approach to client-side optimizations.  And on an on...lots of
details some of which are quite important, I think, and subtle.

-t