Am 27.12.2004 um 23:29 schrieb Tobias Ringström:
>> I have a DMZ with Web Server on which I work with svn for the web
>> pages and today decided to enforce digest auth in apache.conf. But
>> for other users (the clients) in a corporate network it is very
>> confusing. Since those people normally are no admins it doesn't make
>> sense.
>>
>> And it took me hours to change every working copy and the config on
>> all my accounts. On the other side enabling caching would be much
>> faster.
>
> I don't understand what you are saying here. Why did you have to
> change the working copies?
Hello.
I enabled apache's digest auth and worked with some wc's on three
machines until sudden where I realized that svn didn't ask me twice for
a password. Then I searched around and find ~/subversion/config where
the hint was given to change store-auth-creds and to remove already
stored credentials inside each .svn directory. I didn't work that out
so I finally committed outstanding changes of the wc's and deleted them
to check them out again (with store-auth-creds=no).
Setting store-auth-creds (or store-passwords which looks better) to no
by default would give more security by enforcing some sec policy where
user who really want can change that later although they shouldn't.
Remember my example some developer's account gets hacked and the
intruder commits lots of rubbish into the repository. Poor admin and
poor filesystem since the database could grow until the partition is
full.
I would suggest creating /etc/subversion/config and no
~/subversion/config with store-passwords=no as default becourse a rigid
security policy is best. Users are usually no experienced admins but
the should ask their admin if the environment is not comfortable
enough. On the other hand, if everything is comfortable no one will ask
leaving a big security hole to the subversion database.
Just my 3 ct's,
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 28 18:42:30 2004