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!
