On Wed, 26 Jan 2005, Dassi, Nasser wrote:
> If you would, please allow me to revisit the point from another angle.
>
> 1. Do you care about the accuracy of a revision history?
>
Yes.
> If yes, please read on; if no, then maybe you should read on anyways.
>
> 2. Do you feel bothered that modifying a single number value from a
>text-based file can and would result in the rewriting of the repository's
> very own revision history?
No.
> Not even a bit?
No.
> After all, it greatly diminishes the accuracy of said revision history which you probably care about.
By definition, introducing any error removes accuracy, since
accuracy is defined as "freedom from error".
> And, alas, that is my point. Although I have never been as personally
> offended (racially or otherwise) by email, I beg everybody to take a
> quick breath and ask yourself if changing that single number of that
> single file
> should result into a worthless version control solution (more easier to
> a attain in FSFS than BDB, especially without actually hampering the
> operations of SVN).
Changing a single file or string in almost any application, can almost
always cause the application's data to be worthless, whether you can
detect it or not.
I let you get away with claiming that security through obscurity is more
legally defensible than security through negligence, even though every
information security lawyer i know would disagree with you (including
me. I've got a JD, and I'm a member of the ABA's Information Security
Committee, which is part of the Science and Technology law section).
In the very few states where you could make out legal liability for
security breach due to negligence, relying on security by obscurity would meet the
definition of negligence.
In terms of risk assurance, i don't see how locking these files (or
whatever else you wanted to do) while the process is operating will give
you any higher level of assurance as to the data they contain, for a
whole host of reasons that have been explained to
you (that you probably have the permission to kill the
process, etc). I'd rate it marginally beneficial at best.
Thus, if i was a security professional attempting to ensure my version
control solution was secure and accurate, i would spend all of my time on
higher level security measures that would also prevent this particular
attack vector, while at the same time providing a much higher level of
assurance of security of my VCS.
HTH,
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 27 06:03:45 2005