Make some mergeinfo tests pass against old servers.
[svn.git] / notes / changeset-signing.txt
blob81170d877c570ffc1f6a36a0eb99d0f3f7616500
1 Changeset Signing
2 =================
4 1. Goals
6 Allow repository users to digitally sign committed changes, so that:
8   - Others can verify the authenticity of a commit;
10   - Hacked modification and (optionally) deletions of historical
11     revisions can be detected.
14 2. Features
16 2.1 Client-side signing of committed changesets
18 If changeset signing is enabled, the client sends a signed hash of the
19 changes to the server as part of the commit. This signature is stored
20 in a new revprop, svn:signature.
22 Implementation:
24 Modify the commit editor to calculate a hash of the committables
25 during generation of the commit report. The input data for the hash
26 could be an incremental dump of the pending commit (without revision
27 and date info), generated on the fly.
29 As the last act of the commit, the client would add a digital
30 signature of this hash as the svn:signature revprop.
32 [Optional]
34 The client could add the value of current HEAD's svn:signature to the
35 signed data stream. This would let us verify that the sequence of
36 revisions in the repository hasn't changed, giving an extra layer of
37 anti-hack protection. The problem is that commits would have to be
38 serialized, but the client could silently retry the txn-commit if HEAD
39 changed from the time when the commit txn was created. This has
40 interesting effects on the RA protocol, especially the stateless DAV;
41 it implies complete control over txn props on uncommitted
42 transactions.
44 Issues:
46   - The RA API must be revved to allow setting the svn:signature
47     revprop during commit. This would be a natural spin-off of issue
48     #1976.
50   - The client needs a library that can handle digital certificates
51     and create signatures. OpenSSL can do that, and SVN already
52     depends on it via Neon, but not directly. The svnadmin-ssl project
53     will change that.
55   - Changeset signing should be a repository requirement, so we'd
56     really need server-side configuration to control it. As a
57     workaround, a post-commit hook could reject the commit if a
58     svn:signature property wasn't present.
61 2.2 Server-side changeset signature verification
63 The server can verify the signature of a changeset:
65   - Online check during post-commit, an invalid signature causes the
66     commit to be rejected.
68   - Offline check for database consistency, perhaps in "svnadmin
69     verify".
71 Implementation: TODO
73 Issues:
75   - The server needs a list of commit author certificates. Ideally
76     this list would be the same as the one used for client
77     authentication, although cert-based authentication shouldn't be
78     required for changeset signing to work.
80   - The server must maintain a list of expired and revoked client
81     certificates. While these are no longer valid for new commits,
82     they may be needed for verifying signatures on historical
83     revisions.
87 2.3 Client-side verification of changeset signatures
89 The client verifies the changeset signature during update.
91 Implementation:
93 ??? How on earth do you do that? What the server sends during "svn
94 update" is not necessarily the same as one changeset...
96 Perhaps some variant of "svn info URL" or "svn st -u" could do the
97 right thing.