On Tue, Dec 28, 2010 at 1:28 PM, Les Mikesell <lesmikes...@gmail.com> wrote: > On 12/28/10 11:11 AM, Nico Kadel-Garcia wrote: >> >> Disabled entirely would be better, and safer, than empty. Subversion's >> security models have historically been very lax. This is inherited >> from its origins in CVS, and the attitude that "if you don't trust >> your machine, you shouldn't be using it!!!". > > It's not exactly CVS's fault - it is extremely rare for any application to > manage it's own security at the level you want and unheard of for one that > is portable across platforms. And when they try, people complain that it > isn't integrated with the OS and is yet another password to write down or > forget.
CVS was written when the encryption resources were less available in terms of system resources and in terms of US encryption export regulations, and when the 24x7 connection we have now for central software repositories was quite unusual. So historically, it's unsurprising. It evolved over time into Internet wide repository access, when the clients were far fewer and online access was much more rare. Subversion was written much later. Continuing the security policies of CVS seems unwise, and you've seen me grouse about it before (and make some suggestions, and it's admittedly gotten better). But better client and server access control is also hardly "unheard of". Plenty of more modern tools take client and server security far more seriously, including cross-platform source control tools. Bitkeeper, git, Perforce, and mercurial all leap to mind as cross-platform source control tools that do a better job of this particular aspect. The only system I've seen in broad use with such poor security commonplace is CVS, and I've helped several companies from CVS to Subversion to get them doing *something* better than CVS. (I also helped set their guidelines for repository management and insistence on svn+ssh based access.) Password handling is a distinct issue than turning off, and *keeping* off, unnecessary access methods for a specific repository. Disabling unnecessary access by default is a basic security procedure, and would help protect new Subversion administrators from surprises.
