Hello Gnan, > I am > trying to do this on OpenVMS and doesnot seem to be working. I still see > password in clear during authentication and prompting me to store passwords > in plain-text. I'm afraid there is no option for SVNKit to securely store passwords on OpenVMS, i.e. SVNKit supports only plain-text storage on this system.
GNOME Keyring is a part of GNOME environment which is available for POSIX-compliant systems only, support of this password storage aimed mostly to Linux distributions. I had to mention that in my initial email, excuse me. Semen Vadishev, TMate Software, http://svnkit.com/ - Java [Sub]Versioning Library! http://sqljet.com/ - Java SQLite Library! On 4 May 2011 01:30, Gnan Shabada wrote: > Hi Semyon > Does this release of SVNKit need Java 1.6 to support gnome-keyring? I am > trying to do this on OpenVMS and doesnot seem to be working. I still see > password in clear during authentication and prompting me to store passwords > in plain-text. Any help is appreciated > > thanks > Gnan > > > > > > > Semyon Vadishev wrote: >> Hello everyone, >> >> Some time ago we've implemented experimental GNOME Keyring support for >> SVNKit. Generally it allows to keep any sensitive data (passwords, >> certificate passphrases, etc) in GNOME Keyring. >> >> We've already done some internal testing and now we decided to ask the >> community to adopt the existing code for your needs and test it as well. >> >> You may find the latest version of SVNKit with GNOME Keyring support at >> https://teamcity.svnkit.com/repository/download/bt22/13537:id/deploy/org.tmatesoft.svn_1.3.5.7544.standalone.zip >> (login as guest if prompted). >> >> Please notice that the corresponding code uses native binaries, so JNA >> library has to be on classpath in order to make things work. JNA library >> is included to the distribution. >> >> By default SVNKit doesn't try to use GNOME Keyring. To enable this >> feature you have to set 'svnkit.library.gnome-keyring.enabled' property >> to 'true'. >> >> Let's consider the following use cases: >> >> >> >> I. You use svn or jsvn utilities. >> >> To test SVNKit-based command line utility, jsvn, please do the following: >> >> 1) Ensure you won't corrupt existing authentication data: >> >> $ copy -r ~/.subversion/auth ~/.subversion/auth.backup >> >> 2) Ensure you have Keyring support enabled: >> >> $ export SVNKIT_OPTIONS="${SVNKIT_OPTIONS} >> -Dsvnkit.library.gnome-keyring.enabled=true" >> >> 3) Ensure Subversion configuration allows SVNKit to use GNOME Keyring as >> password storage: >> >> ~/.subversion/config file has "password-stores = gnome-keyring" line or >> corresponding line is ignored. No option means using password storage >> available for the operating system. >> >> 4) Run those commands you usually use. Ensure that jsvn behaves as >> expected and doesn't ask you to store passwords in plain text. >> >> $ jsvn ls $repo >> >> $ jsvn checkout $repo $wc >> >> $ jsvn commit $wc >> >> 5) Try to use jsvn in non-interactive mode: >> >> $ jsvn ls --non-interactive $repo >> >> $ jsvn checkout --non-interactive $repo $wc >> >> $ jsvn commit --non-interactive $wc >> >> In this mode jsvn must skip prompting you for any details. In case >> credentials were requested by the repository and they are not yet >> cached, jsvn has to exit with error. >> >> >> >> II. You integrate SVNKit into client-side application. >> >> You might already noticed some changes in classes related to >> authentication, resp. DefaultSVNAuthenticationManager, >> ISVNAuthenticationStorageOptions, ISVNHostOptionsProvider, etc. They are >> not public API, but could be used in certain cases. We made these >> changes in order to support OS X Keychain and now Keyring-related code >> breaks the binary compatibility for this classes, too. >> >> If you're user of DefaultSVNAuthenticationManager interface there are >> three places to look into: >> >> 1) ISVNAuthenticationStorageOptions interface. Its basic usage looks >> like follows: >> >> ISVNAuthenticationStorageOptions authStorageOpts = new >> ISVNAuthenticationStorageOptions() { >> >> // Enable or disable non-interactive mode >> public boolean isNonInteractive() throws SVNException { >> return false; >> } >> >> // In interactive mode prompts user for credentials >> public ISVNAuthStoreHandler getAuthStoreHandler() throws SVNException >> { >> return null; >> } >> >> public boolean isSSLPassphrasePromptSupported() { >> return false; >> } >> >> // In interactive mode asks user for the name of keyring to use >> public ISVNGnomeKeyringPasswordProvider >> getGnomeKeyringPasswordProvider() { >> return null; >> } >> }; >> >> DefaultSVNAuthenticationManager manager = >> (DefaultSVNAuthenticationManager) >> SVNWCUtil.createDefaultAuthenticationManager(); >> manager.setAuthenticationStorageOptions(authStorageOpts); >> >> As you can see there is an analogy between #isNonInteractive() method >> and 'non-interactive' command line option. >> >> 2) ISVNHostOptionsProvider and ISVNHostOptions interfaces. >> >> One could find analogy between ~/.subversion/servers configuration file >> and ISVNHostOptions class. The last one is API for the corresponding >> configuration options. E.g. in order to disable any authentication >> storage, provide necessary implementation of >> ISVNHostOptions#isAuthStorageEnabled() and make authentication manager >> use this implementation. >> >> 3) DefaultSVNOptions class. >> >> Finally, if you want to mimic ~/.subversion/config configuration options >> provide necessary instance of DefaultSVNOptions class. E.g. you can >> restrict usage of certain password storage types via corresponding >> implementation of DefaultSVNOptions#getPasswordStorageTypes(). >> >> >> >> III. You integrate SVNKit into server-side application. >> >> All the information above is also relevant for server-side integration, >> but be carefully when switching to the new version of SVNKit. Since OS X >> Keychain and GNOME Keyring support is enabled, always enable >> non-interactive mode for DefaultSVNAuthenticationManager. Otherwise your >> code most likely will get stuck during password storage access. See >> ISVNAuthenticationStorageOptions#isNonInteractive(). >> >> >> >> Considering these use cases, please keep in mind a known issue related >> to Keyring: >> >> If Keyring daemon is not running, Subversion client initializes it via >> DBus mechanism once needed. SVNKit is not able to do that. So >> application users have to be sure, that keyring daemon is properly >> loaded and initialized to work with. >> >> Thanks in advance! >> >> -- >> Semen Vadishev, >> TMate Software, >> http://svnkit.com/ - Java [Sub]Versioning Library! >> http://sqljet.com/ - Java SQLite Library! >> >> >> >>
