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! > > > >
1. It would be nice if you've had a Maven repository with nightly builds. This would have made it much easier to test this. 2. When do you expect 1.4.0 to be released? -- View this message in context: http://old.nabble.com/GNOME-Keyring-support-tp31183957p31530451.html Sent from the SVNKit - Users mailing list archive at Nabble.com.
