On Wed, Sep 14, 2005 at 03:22:45PM +0200, Alexander Kitaev wrote:
> Hello All,
>
> > So clearly these files must be being consulted for the
> > passphrase. So why aren't they consulted for the key file?
> I suppose there is a bug in JavaSVN, that should be fixed soon.
>
> > I also assume that if I delete them then I will have to give
> > all parameters to the eclipse command which is sort of OK for
> > me but, as Roberto said earlier, on a multi-use machine
> > histories then contain the plain passphrase so it is much
> > better for Subclipse to enter into a dialogue to get username
> > and passphrase.
> That is default JavaSVN behaviour that more or less mimics Subversion's one
> - Subversion (on *nix and OS X) caches credentials information in
> ~/.subversion/auth directory, storing passwords as plain text, on windows
> passwords are encrypted with WinAPI, that is not available from Java. For
> ssh connection putting passphrase into [tunnels] section of config files
> also means storing it as plain text. The only secure way is to use
> ssh-agent, that uses its own protocol and OS pipes and there are no (as far
> as I know) java ssh libraries that supports ssh-agent. Another way is to
> make sure that ~/.subversion (i.e. your home directory) is not readable by
> other users.
>
The problem is that for systems where you are not the sole individual
with root access, this breaks down. I put passphrases on my gpg and ssh
keys for a reason. I don't want that information stored in plain text
or cached in any way, which is why things like gpg-agent and ssh-agent
exist. As far as I know, ssh-agent (or something similar) exists for
Windows, so it must be possible to implement some sort of cross-platform
solution. Though, I think that we be more in the purview of the JSch
developers.
> Fortunately, JavaSVN is a java library and thus fully configurable - it may
> use Subversion way to store credentials (that is default), or doesn't store
> them at all, or use, for instance, Eclipse workspace auth storage (that is
> encrypted) to store credentials. I think for Subclipse the last option is
> the best solution. JavaSVN may still use proxy, ssl and other options from
> standard subversion configuration (that btw may contain proxy password or
> password for ssl cert storage as plain text) and keep passwords, passphrases
> and other information in Eclipse auth storage (at least newly created ones,
> it still may take cached passwords from Subversion directory if there are
> any).
>
As long as the user can chooese wether or not the information is cached.
> The problem with this solution is that Subclipse uses JavaSVN through the
> SVNClient API (JavaHL) that is not as friendly as JavaSVN API :) Anyway it
> is possible to make this customization for Subclipse and I hope to complete
> it this week.
>
Excellent.
> Thanks for your patience and not giving up with JavaSVN - your feedback
> helps to make it better.
>
We are here to serve :-)
> PS
>
> BTW, if you, by any chance, have an idea on how to name JavaSVN library -
> you're welcome :) I'm asking because, AFAIK, software product that is not
> developed by Sun may not contain "Java" in its name. And as more projects
> are using JavaSVN, more dangerous this issue becomes; So, I'm looking for a
> good new name for the library. Please send your suggestions to
> alex@tmate.org. Thanks!
>
Maybe jsvn? Except that may conjure images of a Java implementation of
the svn client/server. I think that libjsvn would preferable.
-Roberto
--
Roberto C. Sanchez
http://familiasanchez.net/~roberto
- application/pgp-signature attachment: stored
Received on Thu Sep 15 01:16:02 2005