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

Re: [PATCH] Change default "store-passwords" policy to "no"

From: Ph. Marek <philipp.marek_at_bmlv.gv.at>
Date: 2007-10-12 07:05:40 CEST

On Donnerstag, 11. Oktober 2007, Jack Repenning wrote:
> On Oct 11, 2007, at 7:04 AM, Erik Huelsmann wrote:
> > On 10/11/07, Ph. Marek <philipp.marek@bmlv.gv.at> wrote:
> >> AFAIK the svn libraries and binaries already require openssl
> >> linking ... so
> >> that should already be included, no?
> > Not if you only build svn://, right?
> Tangenting back off the original proposal, seems like it would be a
> far more useful investment of time to enable encrypted storage on
> *nix when OpenSSL is available.
>
> We (speaking in his CollabNet voice, now) do have customers,
> prospective customers, and lost customers who get very hot-and-
> bothered by this storing of clear-text passwords. Some accept "it's
> not REALLY any worse than CVS," some accept "you can tell your users
> to turn that off," and some accept "well, on Windows and OS X it's
> much better," but some don't buy any of that (and even the latter is
> kind of a black eye for Linux and most other Unices).
Maybe the best course would be some using some agent ...

Even if the password is stored encrypted, it would
- have always the same (built-in) key, or
- the key would have to be stored somewhere, or
- we'd require some password to decrypt the password ;-/

Using gpg-agent, ssh-agent, or some such might be the easiest and best way ...
we could use kdewallet, or decrypt a gpg-encrypted file, or whatever the user
feels is best for his use.
That should even include smartcards!

Regards,

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 12 07:05:57 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.