Todd C. Gleason wrote:
> ------------------------------------------------------------------------
>
> *From:* eg [mailto:egoots_at_gmail.com]
> *Sent:* Monday, April 27, 2009 3:33 PM
> *To:* Ryan Schmidt
> *Cc:* Steven; users_at_subversion.tigris.org
> *Subject:* Re: Shredding private/confidential information
>
>
>
>
>
> On Mon, Apr 27, 2009 at 11:57 AM, Ryan Schmidt
> <subversion-2009a_at_ryandesign.com
> <mailto:subversion-2009a_at_ryandesign.com>> wrote:
>
> On Apr 27, 2009, at 11:48, eg wrote:
>
>
>
>
> 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.
>
>
> True ... but does having one without the other make sense? A simple
> update to a revision before the "svn delete" would bring the sensitive
> files back.
>
>
>
> Say your computer is stolen at that point and the thief gains full
> access to it. If you change your svn password before said update, the
> thief’s update will fail, and so those sensitive files remain
> inaccessible. I think that’s why the proposed feature is a useful
> security mechanism. Of course, an encrypted file system would go a long
> way as well.
But the client side operation wouldn't be unique to svn except for the
fact that a workspace happens to hold another hidden copy. The user may
have copied files out of the workspace to other areas or have equally
sensitive material not under svn control.
--
Les Mikesell
lesmikesell_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1952780
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-28 00:05:51 CEST