I may have found something risky security and integrity-wise.
The revision number with file-type FSFS is manually modifyable in any
ol' text editor. The value (in a file within the repository's file
structure) is stored in plain-text and can be edited with extreme ease.
Whomever has access to the repository's directory (not via interfaces,
but directly at file-system level) can easily modify and alter and
possibly wipe clean the actual revision history.
How to reproduce:
1. Open notepad, and open the file "path-to-repo/db/current"
2a. Edit first number set (this is the revision number) to any desired
2b. Once you save the file, the HEAD revision is whatever value you
3. Update your working copy; expect "conflicts" to exist everywhere
based on whatever differences exist between the "current revision"
(manually input) and "youngest revision" (before modifying the version
4. Mark any/all conflicts as resolved.
5. Commit. Your revision number is now your manually-input revision +
Windows XP SP2 Professional
Subversion 1.1.1 (r11581) Server
Subversion 1.1.3 Client
TortoiseSVN 1.1.3 Client
Keep in mind:
The steps taken to reproduce are easily attainable in a command-line
approach with not GUI client.
Possible/suggested bug fix/workaround solutions:
1. Implement integrity checking to cause future modified-repository
commits to fail; or
2. Implement revision-locking at the filesystem level so existing
revprops + revs files are not *overwritten*; or
3. Revert to latest revision based on FSFS-stored revprops and revs file
4. Implement encoding/encryption to reduce likelihood of tampering (as
Berkeley DB does)
Sr. Technical Programmer
Received on Wed Jan 26 22:08:07 2005