On Wed, 2005-09-14 at 15:22 +0200, Alexander Kitaev wrote:
> > 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.
Yes please.
If the key info is going to be cached then why is there any need to
specify any information as properties? (I don't use configuration
files.) I would have thought that if the cache file exists then there
could be a dialogue to confirm this and if it doesn't exist then a
dialogue associated with the connection could add the needed
information. But I guess this is just restating what your plan was
anyway?
> 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.
As far as I can tell the svn command relies on ssh-agent. Certainly it
does not write any files in ~/.subversion/auth for me. I would be
outraged if subversion was storing my passphrase in plain text on the
filestore.
> 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).
>
> 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.
>
> Thanks for your patience and not giving up with JavaSVN - your feedback
> helps to make it better.
No problem. That is the idea :-)
> 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!
Speaking from a position of total ignorance about the JavaSVN code, I
would have guessed org.tmate.JavaSVN as the package name.
--
Russel.
====================================================
Dr Russel Winder +44 20 7585 2200
41 Buckmaster Road +44 7770 465 077
London SW11 1EN, UK russel@russel.org.uk
Received on Thu Sep 15 01:49:42 2005