notes/changeset-signing.txt

   1 Changeset Signing
   2 =================
   3
   4 1. Goals
   5
   6 Allow repository users to digitally sign committed changes, so that:
   7
   8   - Others can verify the authenticity of a commit;
   9
  10   - Hacked modification and (optionally) deletions of historical
  11     revisions can be detected.
  12
  13
  14 2. Features
  15
  16 2.1 Client-side signing of committed changesets
  17
  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.
  21
  22 Implementation:
  23
  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.
  28
  29 As the last act of the commit, the client would add a digital
  30 signature of this hash as the svn:signature revprop.
  31
  32 [Optional]
  33
  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.
  43
  44 Issues:
  45
  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.
  49
  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.
  54
  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.
  59
  60
  61 2.2 Server-side changeset signature verification
  62
  63 The server can verify the signature of a changeset:
  64
  65   - Online check during post-commit, an invalid signature causes the
  66     commit to be rejected.
  67
  68   - Offline check for database consistency, perhaps in "svnadmin
  69     verify".
  70
  71 Implementation: TODO
  72
  73 Issues:
  74
  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.
  79
  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.
  84
  85
  86
  87 2.3 Client-side verification of changeset signatures
  88
  89 The client verifies the changeset signature during update.
  90
  91 Implementation:
  92
  93 ??? How on earth do you do that? What the server sends during "svn
  94 update" is not necessarily the same as one changeset...
  95
  96 Perhaps some variant of "svn info URL" or "svn st -u" could do the
  97 right thing.