Hi all, The current situation makes certain work-flows, unworkable. It also encourages the use of a modified or out-dated client, to "get the job done", which then itself becomes a security risk more generally.
Reverting to the "old way" and adding a compile-time option is viable, IMHO, only as a temporary solution in the absence of something better. Common pre-built distribution binaries benefit the user with convenience *and* security. From what I have read, it seems that a compile-time option will not be the final word on the matter. As for "auth add", as I understand it, this leaves open some security concerns, so would not be the final word on the matter either. The issue manifests itself at the client side. I will suggest it can be solved looking at the server side. This is my RFC (and bearing in mind I'm just an interested user/admin rather than a dev): - There should be a single option in the repository config to define whether that repo permits client-side plaintext password storage (or perhaps define which are the permitted/denied caching methods). - The configuration option should apply to the entire repository, that is it should be path independent. - The configuration option should apply regardless of client username. - The configuration option should apply regardless of read/write request. - The configuration may differ per repository, if the server instance serves multiple repos. - So I think it belongs in svnserve.conf. Then, either: - during authentication the client shall signal to the server the password storage method in use and the server shall deny auth if it cares - and/or the client shall have means to query the server as to permitted storage methods and determine its own behaviour accordingly - in any case, the user's work-flow should be unchanged from that as it has ever been. Default behaviours: - The default unconfigured behaviour should be that the server signals to the client that plaintext password storage is prohibited. - There should be no compile-time option in either the server or client to alter this behaviour. - There should be no run-time option in the client to alter this behaviour (obviously). Backwards compatibility: - When accessing an older server, the new client behaviour should be as it is currently. That is the user has no way to enable plaintext password storage. - For older version clients, the behaviour should be whatever it is currently for that version. - If that is unacceptable, the server could deny auth to prior version clients, with a separate run-time option to control this. In any case, if it's a problem, it's also one which is unaddressed by the current situation. - In case of an already stored plaintext password, use of this will be permitted only if the repository enables it. Benefits: - No change to client UI, documentation, or work-flow. - It is a simple matter for the admin to allow plaintext password storage for clients of their repository. - It provides for multiple repo's running from a single svnserve instance to dictate differing security models. - It provides for the user to access multiple repo's from their same client software, intentionally mixing password caching methods, and without fear of leaking important credentials. - Enforcement is at the central admin's discretion, as must be expected from an "Enterprise Class" solution. Flaws: - The scheme is dependent upon client software honouring the rules and can be defeated with hacked/rebuilt/ported client software, as is the case currently. - There are many authentication schemes. I don't know, but this could entail a lot of work. - Probably some things I haven't thought of. Sorry for rambling on. ;) I hope it may be of use, even if for now the "old way" is resumed. Bernard.
