Hi!
Suppose someone becomes very paranoid that someone will surreptitiously
tamper with a subversion repository while off-duty (no commits without
this person review and authorization). Taking a backup when leaving the
office and making a diff when coming back is considered impractical.
Moreover the paranoid relatives might tamper with the backup media.
Digital signatures require public/private key protections, just shifting
the problem to yet another security challenge.
So one solution is to hash (SHA-256) the range of revisions committed
during the on-duty period, printing the hash value in two copies, saving
one in a vault for long-term integrity checking, and keeping the other
one as a personal precious item. As a practical consideration, a single
hash for a revision range limits the page count.
At the end of the next on-duty period, the previous day hash value is
verified (prior to the hash computation for the new revisions). To make
the verification convenient, I use bar codes for this paper media
strategy (one-dimensional bar code readers may be cheap). Finally, the
hash value computation may be made incremental such that the latest
revision range hash value can verify the integrity of every revision
ranges. (This scheme has uses other than this exact application, not all
triggered by the Snowden revelations.)
My questions are:
Do I need to hash more than the files db/revs/<n>/<nnn> and
db/revprops/<n>/<nnn> to protect the contents integrity of a revision?
(I guess no)
Are these files end-of-line convention dependent? (I guess yes)
Any other reason why the db/revprops/<n>/<nnn> contents would
legitimately change through a svnadmin dump/load cycle with neither
dumpfilter nor repository version upgrade? (I guess no)
I am using version 1.7.
If any interest in this concept, let me know.
Thanks in advance,
--
- Thierry Moreau
