On Tue, Apr 28, 2009 at 12:16:23PM +0200, Steven wrote:
> It has been argued that the safe disposal of confidential data is not
> the responsibility of SVN, because other programs share the same
> problem. But the uncontrolled-copying-of-data problem is worse with
> SVN than with any other program I've seen.
[citation needed]
> So it would make sense to
> me if SVN gave me the option to NOT spread all my data across the
> disk. Without me having to know about logfiles in the tempdir.
In some situations, Subversion has to use temporary files to make sure
that it does not end up with corrupted working files. Editing files in
place is not always possible without the risk of losing data.
One tool, one task.
Subversion is not a data confidentiality tool.
Subversion is a version control system.
It's primary purpose is to *not* lose any data.
> If SVN has to make copies all over the place, while handling working
> copies, then it has to; but just disposing them seems unscrupulous for
> some kinds of files.
You clearly have data confidentiality requirements that go beyond what
our average users need. If your requirements are that high, why would
you even trust us to implement the feature you proposed? What if we made
a mistake and still accidentally leaked data even if the feature was
implemented? Especially given our track record of features that don't work
quite as intended when first released (e.g. merge-tracking, file externals)?
I mean, why don't you try to find a solution yourself that you *know* will
meet your requirements, rather than believing in us to solve the problem
accurately?
Blair already suggested which locations need to be encrypted/shredded.
And it does not have to be /tmp. You could run svn with TMPDIR set to
some known location, such as an encrypted filesystem mounted at /shredme
that's being shredded from a cronjob as soon as it can be unmounted,
i.e. all files on it have been closed.
If that is not enough, let me suggest another simple solution:
You could do all your svn sessions inside a chroot jail (so no files
can leave the jail), and shred the entire jail whenever you are done
with the working copies in the jail. For convenience, you can repopulate
the jail using a script whenever you need it to use svn or any other
program that you have similar concerns about.
And if your OS does not support chroot jails, then you have much bigger
problems than Subversion potentially leaving confidential data in
a temporary file somewhere :)
And you can combine this solution with encrypting any filesystems
inside the jail, and also the entire filesystem the jail is hosted on.
Oh, and did you look at things like http://www.mcdonald.org.uk/StegFS/ ?
Unfortunately this particular implementation does not seem to be maintained
anymore, but it sounds like you'd want something like that, too.
If you're really that concerned about your data, I wonder why you didn't
look at these kinds of solutions before even thinking about how Subversion
should handle this. Because if you are just looking at Subversion, you
are probably trying to solve the problem at the wrong level.
> If switching to CVS solves any problem, than SVN has failed it's
> mission :p
I'm afraid not. If CVS works better for you, then use CVS.
Stefan
Received on 2009-04-28 15:05:58 CEST