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

Re: Bug? FSFS revision control

From: Mark Parker <mark_at_msdhub.com>
Date: 2005-01-27 00:44:45 CET

Dassi, Nasser wrote:
> **IMPORTANT**
> Instead, Subversion should create a XXX.1 file to enumerate the number
> of times a specific number was attained (if the original XXX file still
> exists). This would at the very least disallow overtly LOSING any data
> directly (because SVN overwrites the XXX file right now in an FSFS
> backend).

OK, then when the hypothetical hacker wants you to lose information,
he'll just delete the xxx.1 file or rename it to xxx.0 or whatever. No.
Protection. Whatsoever.

> At the very least the revision counter should not get so easily
> adjusted. In all honesty, data integrity should not get jeopardized by
> opening Notepad!

If not Notepad then your favorite hex editor. Binary formats are not
more secure just because you can't edit them in notepad. If someone has
OS-granted rights to the repository and wants you to lose data, then
you'll lose data. Even if the repository was totally encrypted, secure,
and unmodifiable via any known tool, that doesn't prevent someone from
doing:

svnadmin dump repo -r 0:some_old_revnum > dumped_repo
rm -rf repo
svnadmin create repo -fs-type fsfs
cat dumped_repo | svnadmin load repo --force-uuid

In which case you've lost data, and didn't involve any notepadesque
tools whatsoever. Should svnadmin do a retinal scan to verify that
you're allowed to dump/load repositories?

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 27 00:47:26 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.