[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: Paul Koning <pkoning_at_equallogic.com>
Date: 2005-10-07 19:35:51 CEST

>>>>> "kfogel" == kfogel <kfogel@collab.net> writes:

 kfogel> Fabian Cenedese <Cenedese@indel.ch> writes:
>> These information can be set any time and countless times to new
>> values with svn admin, be it a user or a virus. As they are
>> unversioned you won't ever find a trace that they changed. Anyone
>> can store any data if he has access to the machine. As the
>> checksum would need to get updated on every change you will never
>> find an error. The only thing you could detect with that checksum
>> is a hardware error. And if there's something wrong with the disc
>> it would surely also affect the real data files.

 kfogel> No, you could also detect a software error -- for example, if
 kfogel> Subversion were writing out revprop values *or their
 kfogel> checksums* improperly. Or it might be trying to write
 kfogel> something else, but due to boundary bug accidentally smash
 kfogel> part of a revprop value or a revprop value's checksum. So
 kfogel> it's technically possible for a Subversion problem to be
 kfogel> detected by this means.


The one thing you don't get with checksums is protection against
malicious corruptors. For that, you need cryptographic integrity
machinery (in other words, digital signatures or equivalent).

 kfogel> It's not only hardware that makes mistakes :-).

True. And I agree with the earlier comment that not all hardware
errors are going to mess up enough bits that data checksum alone is
guaranteed to sound the alarm. Especially when the "hardware" is
actually a combination of hardware and software -- as in the case of
any storage device more complex than a simple disk drive.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 7 19:39:00 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.