| 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. |