On 10.08.2010 20:57, Greg Hudson wrote:
> On Tue, 2010-08-10 at 14:24 -0400, C. Michael Pilato wrote:
>
>> The foremost bit of client configuration that CollabNet's Subversion
>> customers are demanding (besides auto-props, which I think we all agree on)
>> is a way for the server to set a policy which dictates that clients may not
>> use plaintext or other insecure password storage mechanisms.
>>
> I don't expect anyone to consider my opinion blocking, but I think this
> is a questionable area for any kind of software to delve into. I've
> only seen this kind of client control in one other context (a branded
> Jabber client), and never in an open source project. (*)
>
> Lots and lots of clients are able to remember passwords: web browsers,
> email clients, IM clients. Lots of central IT organizations (MIT's
> included) don't like this feature and recommend that users not use it.
> Lots of users do it anyway. I don't know of a single piece of
> widely-used client software which allows the server to turn off password
> memory.
>
The issue isn't storing passwords, but storing them insecurely, i.e., in
plaintext on disk. Which is what Subversion does by default unless it
specificaly supports secure password storage on the client system --
IIRC the supported systems are Windows (with CryptoAPI), MacOS (with
Keychain) and Linux (with Kwallet or gnome-keychain, which I suppose
aren't really limited to Linux).
I think it's perfectly valid for a shop to force its users to store
passwords securely, but I wonder if server-side configuration is the way
to do it -- I'd rather expect them to provide the right sort of client
for the right sort of system.
> (*) Actually, on consideration, there was some flap about the "okay to
> print" flag in PDF documents, or something related to that. I can't
> remember how it turned out.
>
Received on 2010-08-10 23:13:10 CEST