On 2008-01-02 at 11:32 +0100, Aristotle Pagaltzis wrote: > Which is reasonably doable without the aid of tools, because you > can easily inspect these files: Subversion stores *everything*, > and that includes the passwords, in pure, untarnished clear text. > > A marvel. > > That anyone ever thought this fuming pile of manure is great.
This is fairly common for authenticated repository systems, that I've seen. I mean, it's not like ~/.cvspass is anything other than fool-yourself obfuscation. Perforce uses environment variables, which aren't particularly secure (hello, ps(1)) and yet it's used in SOX environments. *sigh* svn does at least let you not store passwords, by using an authentication mechanism not based on passwords. I do not use svn+ssh but with pubkey auth I'd be surprised if any passwords had to be stored. Instead I use GSSAPI. It's just a matter of telling Apache use use mod_auth_kerb and serving over https; the libneon subversion client library explicitly disables Negotiate auth unless the access protocol is https. I've assumed that this is to avoid having to write layer wrapping and to just be able to rely upon servers not asking for GSSAPI session protection layers when already using TLS. The svn client tools, cadaver, they all Just Work with GSSAPI. Safari, Firefox after enabling it, yup (and don't need to use the https variant of the site). Not sure if MSIE does, I think that I didn't bother since I wasn't using domain signin but MIT Kerberos for Windows so that I could have tokens for whatever remote sites I had accounts for. I suspect MSIE would work, if you used this in a Windows Domain setup. Untested, but I vaguely recall that MSIE introduced Negotiate so I'd for once be surprised if MS did get this wrong. Now, there's no special support for this server-side, so your authenticated id is just the fully-qualified u...@domain but that's at least The Right Thing. I get around it with AuthzSVNAccessFile which defines the groups and defining a group for the same name as 'user' which contains 'user' and 'u...@domain'. Of course, you need to have unique DNS for Kerberos to be happy. That's why I use IPv6 and why svn.spodhuis.org is IPv6-only. But there's /svn, /ksvn, /viewvc and /kviewvc on that. (Two modules are publicly readable, if anyone's interested). So I could see why libneon chickened out but that doesn't mean that I don't have some resigned vague hate for the lack of stackable IO layers in the standard C libraries; I need to look closer at sfio. I had some ... irritation when I finally figured out the https restriction and then had to wander over my svn:externals references changing the URLs. *sigh* -Phil
