Fwd: version control features

Just forwarding this mail (with the author's permission, of course) to
the dev-list for discussion and/or archival purposes.

--
From: "Joel N. Weber II" <nemo@red-bean.com>
To: "C. Michael Pilato" <cmpilato@red-bean.com>
Subject: Re: version control features
Date: Sat, 21 Sep 2002 13:03:10 -0400
Lines: 59
I'm not an expert at subversion at all (my level of clue is ``I've
read 10% of the documentation''), but one guess about how to do what I
want:
As part of the checkin process, take the binary diff that subversion
uses, feed it to gpg, make a gpg detached signature, and add the
detached signature as a metadata attribute.  It is probably also be
worth making a detached signature on the resulting complete file, and
making that another metadata attribute.
Then from there, you can write a verification tool which makes sure
that all of these signatures are consistent on all these diffs and
versions of the file, and that all the signatures are good signatures
made using valid keys of people who are supposed to be able to
contribute code; if they are, you can know that even if the repository
machine was cracked, the data wasn't corrupted.
As a later step, you could also add code so that before the server
allows the transaction to complete, it verifies the signatures are
good if it's configured to do so.
And you might not actually need both sets of signatures, but I think
they're both useful.  Consider:
Alice, who's both a key contributor and the person who runs the
repository machine, checks in a thousand lines of code changes, some
of which are very obviously malicious.
Bob, who is an occasional contributor, checks in a ten line change to
that same file a few hours later.  It's in a part that wasn't affected
by the previous change, and he doesn't have the time or knowlege to
evaluate Alice's checkin.
Alice then deletes her version from the repository, so when you check
the signatures on Bob's new version, and the version before Alice's
version, it will look like Bob inserted the malicious code.  (Unless
the version numbers are such that it will be obvious that a version in
between is missing.)
You want the per-entire-file signatures because they make it easy for
someone with a casual paranoia level doing an anonymous checkout to
efficiently verify things.  When a developer who's going to commit
code does an update, he or she probably ideally should be using a mode
where each intermediate version is checked, and the client makes sure
that both the diff signature and entire file signature are correct,
and refuses to actually do the update if not.
The signatures probably should be made against a header of a line or a
few lines of text which contain information about the version numbers
involved, and filename involved, etc, followed by the actual file or
actual diff.  If you're feeding data to gpg across a pipe, it's easy
to write a few lines of text and then feed the file to the pipe.
If you're really paranoid, you may want the signature to eventually
include an externally cryptographically signed timestamp, but the
tools to do that aren't really quite there yet as far as I know.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org