[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: AW: AW: AW: How to check integrity of database?

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2005-10-06 16:57:20 CEST

On Oct 6, 2005, at 10:47 AM, Leon Zandman wrote:

>> We don't bother to checksum them, because they are
>> unversioned, and you shouldn't be storing anything critical
>> in there anyway.
> I don't understand why you don't checksum the properties. I do
> understand why the properties/log messages aren't versioned, but I'd
> still like to know when my repository has been corrupted somehow.

Okay, well, i've copied greg, who made this design decision, AFAIK.

I imagine it was done because it would have complicated the file format.

> I used to trust my nightly batch run of "svnadmin verify"'s to
> inform me
> when something has gone wrong. But as I understand now some external
> event (virus, disk damage) might alter the property part of the
> repository database and "svnadmin verify" might never notice this. I'm
> not really happy about this...

You should never rely on a single thing to tell you whether you have
valid data integrity or not.
There are always cases svnadmin verify couldn't ever notice, even if
you checksummed everything, because a smart virus could simply update
the checksums!

I don't see why the line you've drawn is any better or worse than the
line we've drawn.

I'm involved in quite a few information security committees, etc, and
i can tell you with absolute certainty that when it really comes down
to it, you need a lot more than subversion could ever give you to be
able to say that the data you have is the data you originally had.

(one company that specializes in this is http://www.proofspace.com/)


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 6 17:00:57 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.