On Windows 2000 or later, svn 1.2 and above uses standard Windows APIs to encrypt the data, so only the user can decrypt the cached password.

On Mac OS X, svn 1.4 and later uses the system Keychain facility to encrypt/store your svn password.

Subversion 1.6 will address this issue for UNIX/Linux. Support for GNOME Keyring and KWallet has been implemented, both of which facilitate storing passwords on disk encrypted. These programs need to be available at compile-time and and at run-time. Otherwise, the client will fall back to caching your password in plaintext, but it has also been changed to never cache a password in plaintext without asking first.

With Subversion 1.5 and earlier, on UNIX/Linux, the password can only be stored in plaintext in ~/.subversion/auth/. Notice, however, that the directory which contains the cached passwords (usually ~/.subversion/auth/) has permissions of 700, meaning only you can read them.

However, if you're really worried, you can permanently turn off password caching. With an svn 1.0 client, just set 'store-auth-creds = no' in your run-time config file. With an svn 1.1 client or later, you can use the more narrowly-defined 'store-passwords = no' (so that server certs are still cached). More information on password cacheing is in chapter 6 of the "Nightly Build" Subversion book, under "Client Credentials Caching".

Lastly, we point out that CVS has been caching passwords for years in the .cvspass file. It may look like the passwords in .cvspass are encrypted, but in fact they're only lightly scrambled with an algorithm that's the moral equivalent to rot13. They can be cracked instantly. The only utility of the scrambling is to prevent users (like root) from accidentally seeing the password. Nobody's cared enough to do this for Subversion yet; if you're interested, send patches to the dev@ list.

Answered by M P , an ibibo Master, at 7:25 PM on October 06, 2008