[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: Todd C. Gleason <tgleason_at_impac.com>
Date: Mon, 27 Apr 2009 15:19:21 -0700

> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell_at_gmail.com]
> Sent: Monday, April 27, 2009 4:04 PM
> To: Gleason, Todd
> Cc: eg; Ryan Schmidt; Steven; users_at_subversion.tigris.org
> Subject: Re: Shredding private/confidential information‏
>
> 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.

I'm not arguing against a universal OS solution, but I wouldn't hold my breath for one either. I was merely pointing out that Subversion could choose to offer security enhancements in this area. If you did put shredding in, you might want an svn subcommand to shred an entire WC as well.

Note that I'm also not debating the priority of such a feature (because I don't personally need it).

However, arguing that some things are out of your control seems to me like saying that it's not worthwhile to do X unless everybody else is doing it. (Pick your favorite altruistic cause here.) Besides, for those non-svn areas the user may already have shredding utilities, and simply want something to cover the svn portion.

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

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-28 00:21:43 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.