Changeset Signing ================= 1. Goals 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. Features 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. Implementation: 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. [Optional] 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 transactions. Issues: - The RA API must be revved to allow setting the svn:signature revprop during commit. This would be a natural spin-off of issue #1976. - 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 verify". Implementation: TODO Issues: - 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 revisions. 2.3 Client-side verification of changeset signatures The client verifies the changeset signature during update. Implementation: ??? 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 right thing.