1. A non-hacker can edit the number, and boom... Revisions gone. The
non-hacker is not determined to overwrite revisions... But hey, sh*t
2. SVN-accessed modifications (including dumping) is beyond the scope of
this concern. In fact, SVN-accessed actions are all by-design or at
3. My other post (same thread, minutes ago) examplifies how file locking
is possible without blaming the OS or sysadmin for stuff.
Sr. Technical Programmer
From: Mark Parker [mailto:email@example.com]
Sent: Wednesday, January 26, 2005 6:45 PM
To: Dassi, Nasser
Subject: Re: Bug? FSFS revision control
Dassi, Nasser wrote:
> 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.
> 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
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
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?
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jan 27 01:07:32 2005