On 17 October 2010 08:52, Alan Barrett <apb_at_cequrux.com> wrote:
> On Sun, 17 Oct 2010, Nico Kadel-Garcia wrote:
>> > What he really wants is an alternate-universe Subversion which never
>> > had the plaintext password storage feature in the first place.
>>
>> I'd settle for being able to block that local use on the server side:
>
> OK, so you want a feature in which the client reports to the server
> "here are some important aspects of my configuration", and the server
> replies "I don't like <this> aspect of your configuration, so I refuse
> to work with you". I suggest that you write up a proposal for such a
> feature, or begin a focused discussion about how such a feature could
> work and could be useful.
>
> --apb (Alan Barrett)
>
The reality is if you don't trust the client, then you don't trust the
client so how can you trust it to report what it supports correctly?
It would be trivial to fork svn to lie and report that it only stored
passwords encrypted, stick that forked client on my machine and hey
presto, away I go storing my password in plaintext.
I think that the best compromise would be for the SVN client to report
its capabilities like the SVN 1.5+ clients do:
You can have a start-commit hook. It can reject commits from clients
that don't have the "mergeinfo" capability.
http://svnbook.red-bean.com/en/1.5/svn.ref.reposhooks.start-commit.html
And that sorts out Nico's requirement for blocking the insecure 1.4
clienst in Redhat EL/CentOS
Add a capability called "keyringenabled" to Subversion and now Nico
will probably be much happier... but of course he doesn't trust his
users so he cannot trust that they report "keyringenabled"
correctly... but he might be pragmatic enough to accept that as a
compromise.
and that's probably a feature we could add in 1.6.14 with only minor
effort (most of the work being deciding what the feature name should
be ;-) )
-Stephen
Received on 2010-10-18 09:57:06 CEST