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

Re: Bug? FSFS revision control

From: Sean Laurent <sean_at_neuronfarm.com>
Date: 2005-01-26 23:34:30 CET

Hash: SHA1

On Wednesday 26 January 2005 04:10 pm, Dassi, Nasser wrote:
> > > There are several ways; and giving up so easily is extremely *bad*
> > > practice. Making a hacker think a few minutes is better than just
> > > giving them the answer without a blink.
> >
> > 1) The best way to do that is to secure the server itself.
> >
> > 2) Security through obfuscation does not work.
> Security through negligence works less than through obfuscation.
> Ironically, negligence carries a greater legal penalty than
> obfuscation!!!

I guess I'm just not seeing how modifying the FSFS backend would actually

Let's assume an malicious user gains unauthorized access to a server. Perhaps
the exploited a security hole that allowed them to run a script as an
arbitrary user. Perhaps they cracked a user's password or worse yet, the
root password. It doesn't really matter.

If the hacker has write access to the Subversion repository and they want to
cause harm, why would they bother to edit the revision history? As Toby
Johnson already pointed out, if a user has write access to the repository,
they could destroy the entire repository!

The best way to prevent this is to use the existing OS access controls, secure
the repository directories and restrict access to them. Why add a level of
complexity to Subversion that won't help solve the problem?

- -Sean
Version: GnuPG v1.2.4 (GNU/Linux)


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 26 23:37:11 2005

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.