> From: John P N Pybus <john.pybus@zoology.oxford.ac.uk>
>> I'm not sure how you can get a sufficiently secure and sufficiently
>> quickly verifiable signature system into svn without a lot of
>> hacking. The DB mechanism kind of fights against it. It's going to
>> be a hard problem.
> I can think of approaches. The project host is probably creating dump
> files for backup. These can have the hashes checked at writeout
> time.
Yup. At least then you're just streaming these dump files through a
verifier and that should be pretty quick. I'm not familiar with the
dump format or the costs of creating it, though. It seemed to me
that either the dump format doesn't contain contiguous whole-texts of
files (in which case you won't be just streaming through the verifier)
or else they do contain whole-texts (in which case my question is how
expensive it is to make these files).
Anyway, I thought that one of the ways to do backups, especially
incrementally, was via the logs. And at the same time there's this
issue of the logs growing in proportion to whole-text sizes of
modified files. So another approach I considered but didn't mention
is that maybe you can kill two birds with one stone: have a smarter
logging mechanism and "somehow" tie what-gets-signed to
what-gets-logged.
> At disaster time a dump up to revX is created, checksummed, and compared
> with the signed hash. Only revisions newer than X now need verifying at
> the individual file level. By allowing some of the verification work to
> scheduled for checking up front that required to validate at any one
> time can be kept feasible without major alterations to subversion.
Sounds interesting. I should probably go back into lurk mode and let
the experts take it from there..... :-)
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 11 21:00:46 2003