RE: Credentials held unencrypted in memory during runtime

For a simple workaround, just use 2 sets of credentials, one with write permissions, and one with read-only permissions. Cache the r/o permissions with Tortoise and require people to use the svn.exe command-line tool for commits. Never tell Tortoise the r/w password, but do let it persist the r/o password to disk. If the laptop is stolen, the r/o password is of little special value.

We do something similar to that here with AnkhSVN, as a matter of informal policy. We voluntarily prevent ourselves from accidentally using AnkhSVN as a check-in tool by simply never giving it any SVN credentials with check-in privileges. This allows us to use 90% of its core functionality, but still standardize on Tortoise for code reviews and check-ins.

If you don't trust your users not to instead store the r/w password, have your IT people install Tortoise and enter the r/o password, and figure out a way to lock down the r/o password so users can't change the cache.

Up to you how you want to prevent users from caching the r/w password in the plain text batch files they start writing to work with svn.exe.

That's about the best you can do, I think, with any SVN client implementation. To get any better than that, you would have to modify SVN itself to start supporting Windows AD or LDAP, etc, instead of the current password model. But that's a different mailing list.

-Eric

Honey Badger don't care about no credentials. He just goes in anyway. Nasty little badger.

-----Original Message-----
From: Pablo M. Dotro [mailto:pdotro_at_df.uba.ar]
Sent: Wednesday, April 13, 2011 6:29 AM
To: users_at_tortoisesvn.tigris.org
Subject: Re: Credentials held unencrypted in memory during runtime

On 13/04/2011 09:55 a.m., Feldhacker, Chris wrote:
> http://www.wandisco.com/subversion/tortoisesvn-support
> "Stefan Küng, the TortoiseSVN project's lead developer since 2003, heads WANdisco's team of professionals dedicated to the support, development and enhancement of this widely used Subversion client. This enables us to deliver critical fixes without any delay."
>
> I'd be curious if Stefan's views of secure coding best practices is also the official position of WANdisco...
> Anybody out there with an official support contract with WANdisco want to report this issue through official channels and see where it leads? It's always interesting to gauge just how much vendors selling support for open source products really can/cannot have an influence... Would WANdisco's response also be "go away"?
>
Going over the head of the project's lead developer in public, on his
own users list... not polite.
I would point *another* obvious angle: TortoiseSVN is open source. I am
sure that if the interested parties submit a patch that remedies this
perceived vulnerability, it will be considered. And even if it's not,
everyone is free to create a derivative and include it in their own builds.

-- 
Pablo M. Dotro
pdotro_at_df.uba.ar
Área de Servicios Informáticos
Laboratorios de Enseñanza
Departamento de Física (FCEyN - UBA)
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2719444
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2719606
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].