On 17 October 2010 08:52, Alan Barrett <a...@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
