changeset-signing.txt [plain text]
Allow repository users to digitally sign committed changes, so that:
- Others can verify the authenticity of a commit;
- Hacked modification and (optionally) deletions of historical
revisions can be detected.
2.1 Client-side signing of committed changesets
If changeset signing is enabled, the client sends a signed hash of the
changes to the server as part of the commit. This signature is stored
in a new revprop, svn:signature.
Modify the commit editor to calculate a hash of the committables
during generation of the commit report. The input data for the hash
could be an incremental dump of the pending commit (without revision
and date info), generated on the fly.
As the last act of the commit, the client would add a digital
signature of this hash as the svn:signature revprop.
The client could add the value of current HEAD's svn:signature to the
signed data stream. This would let us verify that the sequence of
revisions in the repository hasn't changed, giving an extra layer of
anti-hack protection. The problem is that commits would have to be
serialized, but the client could silently retry the txn-commit if HEAD
changed from the time when the commit txn was created. This has
interesting effects on the RA protocol, especially the stateless DAV;
it implies complete control over txn props on uncommitted
- The RA API must be revved to allow setting the svn:signature
revprop during commit. This would be a natural spin-off of issue
- The client needs a library that can handle digital certificates
and create signatures. OpenSSL can do that, and SVN already
depends on it via Neon, but not directly. The svnadmin-ssl project
will change that.
- Changeset signing should be a repository requirement, so we'd
really need server-side configuration to control it. As a
workaround, a post-commit hook could reject the commit if a
svn:signature property wasn't present.
2.2 Server-side changeset signature verification
The server can verify the signature of a changeset:
- Online check during post-commit, an invalid signature causes the
commit to be rejected.
- Offline check for database consistency, perhaps in "svnadmin
- The server needs a list of commit author certificates. Ideally
this list would be the same as the one used for client
authentication, although cert-based authentication shouldn't be
required for changeset signing to work.
- The server must maintain a list of expired and revoked client
certificates. While these are no longer valid for new commits,
they may be needed for verifying signatures on historical
2.3 Client-side verification of changeset signatures
The client verifies the changeset signature during update.
??? How on earth do you do that? What the server sends during "svn
update" is not necessarily the same as one changeset...
Perhaps some variant of "svn info URL" or "svn st -u" could do the