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

Re: Shredding private/confidential information‏

From: Andy Levy <andy.levy_at_gmail.com>
Date: Mon, 27 Apr 2009 15:09:17 -0400

On Mon, Apr 27, 2009 at 14:57, Ryan Schmidt
<subversion-2009a_at_ryandesign.com> wrote:
> On Apr 27, 2009, at 11:48, eg wrote:
>
>> Steven wrote:
>>
>>> When deleting private/confidential files, I think it is a good
>>> practice
>>> to run them through a shredder, even when a limited number of
>>> people has
>>> access to the disk they are on.
>>>
>>> However, when managing private data in an SVN repository, this
>>> becomes
>>> problematic, because SVN copies and disposes files all over the
>>> place.
>>> The problem is particularly grievous with working copies. For
>>> example,
>>> when ordering a delete, SVN just disposes the file. When
>>> committing, it
>>> also disposes the copy in .svn/text-base. The same is done when
>>> updating
>>> any working copies containing this file. All this is done without any
>>> oppurtunity to shred the files in question.
>>>
>>> Has anyone thought about this before? Suggestions? Maybe a
>>> candidate for
>>> a feature request?
>>
>> http://subversion.tigris.org/issues/show_bug.cgi?id=516
>
> Not quite the same thing. That is the feature request for
> obliteration of an item in the repository. However Steven wants to
> securely erase a file in a working copy, whenever Subversion would
> delete such a file.

IMHO, that would be better done via the host OS's APIs, not Subversion
itself. And the host API would probably be called by APR, not SVN
directly (I'm guessing, I don't really know how APR is used by SVN).

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1950461

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-27 21:10:13 CEST

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.