Lasse Kliemann wrote:
> * Message by -David Weintraub- from Sat 2008-09-27:
>> So, you want to prevent someone, on a system they control, not to be
>> able to modify files?
> 
> No. I want to give users the _option_ of marking certain files in 
> their working copy as immutable to 'svn up' operations.
> 
> 
>> By the way, how do you mean that the repository was compromised?
> 
> Someone breaks into the server, by whatever means. Then the 
> attacker replaces the repository by a specially crafted one. This 
> new repository looks like the old one to the 'svn' client, so the 
> 'svn up' operations run smoothly. However, the new repository 
> does not contain certain important files - in no revision. So, 
> users do 'svn up', and the important files get deleted in their 
> working copies. Any attempts to get these files from previous 
> revision fail, since also the previous revisions (if any at all; 
> that depends on how the new repository was crafted in detail) do 
> not contain these files.
That seems like a very unlikely scenario and one you should protect 
against by other means if you expect it to be possible.  Normally you 
would expect the repository copy to be authoritative and the working 
copies more or less disposable and you'd focus your security and backup 
efforts on the repository server.  I'd think through the full plan for 
recovery before deciding if a partial step like this is needed or 
worthwhile.
I'm somewhat curious about this scenario anyway.  Would the client 
actually delete an existing file that a repository with a matching id 
suddenly didn't have?
-- 
   Les Mikesell
    lesmikesell_at_gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-28 19:30:28 CEST