On Mon, Mar 21, 2011 at 1:07 PM, Cecil Westerhof <Cecil_at_decebal.nl> wrote:
> Op maandag 21 mrt 2011 17:57 CET schreef Nico Kadel-Garcia:
>
>>> As I understood it, the best way to setup subversion is just with
>>> svnserve. Because it is accessed through the Internet, we should also
>>> SASL.
>>>
>>> It looks like the passwords are then stored in a text-file. Which
>>> means that when an user want to change his password, the maintainer of
>>> the svnserver has to change the password and mail it to the user. Is
>>> this correct, or am I overlooking something?
>>
>> Cecil, there are trade-offs. Do go to the redbook at
>> http://svnbook.red-bean.com/. svnserve works, but is not automatically
>> encrypted, and has poor logging. HTTP/HTTPS access can be set to
>> encryption, but the UNIX/Linux clients store passwords in cleartext
>> locally, which I personally consider absolute anathema. svn+ssh works,
>> but handling the SSH public keys is awkward and has no tool for easy
>> management of access.
>>
>> They've all got trade-offs: different ports need to be acessible for
>> clients, for example. SASL, in particular, *CAN* be managed by
>> authorized users from offsite, but it requires more infrastructure.
>
> I already was reading the redbook. I think I first just implement SASL
> to get things on the road. When that works, I'll look at the offsite
> management. Is that in the redbook? I can not remember seeing it. But
> maybe I overlooked something.
Cool. Check out
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.netmodel.html#svn.serverconfig.netmodel.credcache
to learn more about the credential caching. Unfortunately, while that
page mentions support for Gnome and KDE wallets, it fails to mention
the dependencies on active X sessions for those to work well, and the
difficulties of using them in a plain text environment, nor does it
properly address the ongoing practices of storing passwords in clear
text, by default. Enabling Gnome or KDE wallets requires additional,
client managed steps that are therefore difficult to enforce sitewide.
Received on 2011-03-21 18:37:44 CET