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