|
»
»
GNOME Keyring support
|
View:
New views
18 Messages
—
Rating Filter:
Alert me
|
 |
GNOME Keyring support
by Semyon Vadishev
::
Rate this Message:
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! |
|
|
Re: GNOME Keyring support
by lazee
::
Rate this Message:
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? |
|
|
Re: GNOME Keyring support
by Semyon Vadishev
::
Rate this Message:
Hi,
> 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. Agree. We're currently migrating to gradle, as a build tool, and Sonatype Nexus, as artifact repository, for all our projects. I think we will set up the environment in a week or two, so we will publish nightly builds as maven artifacts soon. We will release SVNKit 1.3.6 with GNOME Keyring support and some other enhancements a bit later. Meanwhile you may try builds from our trunk which are already in Maven repository — http://maven.tmatesoft.com/index.html#nexus-search;quick~svnkit. They are no stable yet, but they do support GNOME keyring. The description from my first email of the thread is still valid for these builds. If you're going to test authentication cache only, it's much safer to use remote operations — ls, info, etc. > 2. When do you expect 1.4.0 to be released? Usually we roll out the major release in a month after Subversion release. According to Subversion roadmap — http://subversion.apache.org/roadmap.html, there is certain features development still in progress. So we don't have schedule yet. The most important feature of svn 1.7 is a new working copy format with central metadata storage. It's based on SQLite database engine and we've already implemented basic support for this new storage. That means that first builds with full support of working copy operations will appear in reasonable time after Subversion release. At the same time there are also enhancement in FSFS backend and HTTP/DAV repository access. Some of them are backward compatible with the former versions. Probably we will roll out these particular improvements in minor releases after the major one. Please notice that the next major version of SVNKit is 1.7.0. We decided to have the major version number similar to Subversion one. Thank you for your feedback. Semen Vadishev, TMate Software, http://svnkit.com/ - Java [Sub]Versioning Library! http://sqljet.com/ - Java SQLite Library! On 3 May 2011 14:45, lazee wrote: > > 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? |
|
|
Re: GNOME Keyring support
by lazee
::
Rate this Message:
Thnx, I have now done some testing on 1.7.0-SNAPSHOT.
It seems that the Keychain support on Mac OSX (10.6.7) doesn't work anymore. With SvnKit 1.3.5 I am able to work against a local test repository. With 1.7.0-SNAPSHOT I get this error: SVNException: org.tmatesoft.svn.core.SVNAuthenticationException -> svn: Authentication required for '<http://svn.api.no:80> SVN' org.tmatesoft.svn.core.SVNAuthenticationException: svn: Authentication required for '<http://svn.api.no:80> SVN' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:47) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:41) at org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getNextAuthentication(DefaultSVNAuthenticationManager.java:218) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:564) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:280) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:268) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1007) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:179) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:480) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getLocations(SVNBasicDelegate.java:833) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:527) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2716) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2627) at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2202) Any changes in the API that I should be aware of?
|
|
|
Re: GNOME Keyring support
by lazee
::
Rate this Message:
This is the way I initialize the client:
clientManager = SVNClientManager.newInstance(); SVNRepositoryFactoryImpl.setup(); if (log.isDebugEnabled()) { SvnDebugLogger.initSvnDebugLogger(); } DAVRepositoryFactory.setup(); FSRepositoryFactory.setup();
|
|
|
Re: GNOME Keyring support
by Semyon Vadishev
::
Rate this Message:
I have tested 'jsvn' utility from 1.7.0 build on my OS X 10.5.8 and it
worked just fine. There are certain differences between 1.3.5 and 'maven' branch (maven artifacts built from this branch, which is approximately trunk), but there are no API changes. I'm afraid the problem is somehow related to maven dependencies — SVNKit fails to access OS X Keychain with no JNA binaries at runtime. Could you check that JNA library is in classpath when you running the code. Debug log would be helpful here. Find the description how to get it here — https://wiki.svnkit.com/Troubleshooting. There are also internal changes, especially those related to HTTP authentication mechanisms. If that possible, could you please test authentication against some svnserve daemon, i.e. using svn:// protocol, not http://. If all above is not relevant for your particular case, let's see what could be wrong with the code. So, you have login and password stored in the keychain, right? Please ensure you do — find "<http://svn.api.no:80> SVN" item and check that access to the item is granted for Java applications. Otherwise it's not clear for me how do you provide the credentials for the corresponding realm. As I can see, you use the authentication manager which by default don't have any callback to provide necessary credentials, that means this authentication manager uses cached version of credentials. That means 1.3.5 build can read this cached data, but 1.7.0 version is not able to do that, thus we have a bug. Not to bother you with such non-stable builds, you might want to wait until we merge gradle/maven changes back to trunk and 1.3.x branches. So you can try pure trunk version or pre-release 1.3.6 build soon. Also you may try old-school jar-based way. You can download necessary jars from our build server — 1.3.x https://teamcity.svnkit.com/repository/download/bt22/14050:id/deploy/org.tmatesoft.svn_1.3.5.7590.standalone.zip and trunk https://teamcity.svnkit.com/repository/download/bt3/14080:id/deploy/org.tmatesoft.svn_1.4.0.7613.standalone.zip. Log in as a guest if prompted. Thank you. Semen Vadishev, TMate Software, http://svnkit.com/ - Java [Sub]Versioning Library! http://sqljet.com/ - Java SQLite Library! On 3 May 2011 20:27, lazee wrote: > This is the way I initialize the client: > > clientManager = SVNClientManager.newInstance(); > SVNRepositoryFactoryImpl.setup(); > if (log.isDebugEnabled()) { > SvnDebugLogger.initSvnDebugLogger(); > } > DAVRepositoryFactory.setup(); > FSRepositoryFactory.setup(); > > > > lazee wrote: >> Thnx, I have now done some testing on 1.7.0-SNAPSHOT. >> >> It seems that the Keychain support on Mac OSX (10.6.7) doesn't work >> anymore. With SvnKit 1.3.5 I am able to work against a local test >> repository. With 1.7.0-SNAPSHOT I get this error: >> >> SVNException: org.tmatesoft.svn.core.SVNAuthenticationException -> svn: >> Authentication required for '<http://svn.api.no:80> SVN' >> org.tmatesoft.svn.core.SVNAuthenticationException: svn: Authentication >> required for '<http://svn.api.no:80> SVN' >> at >> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:47) >> at >> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:41) >> at >> org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getNextAuthentication(DefaultSVNAuthenticationManager.java:218) >> at >> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:564) >> at >> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:280) >> at >> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:268) >> at >> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) >> at >> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) >> at >> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1007) >> at >> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:179) >> at >> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:480) >> at >> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getLocations(SVNBasicDelegate.java:833) >> at >> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:527) >> at >> org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2716) >> at >> org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2627) >> at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2202) >> >> >> Any changes in the API that I should be aware of? >> >> >> >> Semyon Vadishev wrote: >>> Hi, >>> >>>> 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. >>> Agree. We're currently migrating to gradle, as a build tool, and >>> Sonatype Nexus, as artifact repository, for all our projects. I think we >>> will set up the environment in a week or two, so we will publish nightly >>> builds as maven artifacts soon. We will release SVNKit 1.3.6 with GNOME >>> Keyring support and some other enhancements a bit later. >>> >>> Meanwhile you may try builds from our trunk which are already in Maven >>> repository — >>> http://maven.tmatesoft.com/index.html#nexus-search;quick~svnkit. They >>> are no stable yet, but they do support GNOME keyring. The description >>> from my first email of the thread is still valid for these builds. >>> >>> If you're going to test authentication cache only, it's much safer to >>> use remote operations — ls, info, etc. >>> >>>> 2. When do you expect 1.4.0 to be released? >>> Usually we roll out the major release in a month after Subversion >>> release. According to Subversion roadmap — >>> http://subversion.apache.org/roadmap.html, there is certain features >>> development still in progress. So we don't have schedule yet. >>> >>> The most important feature of svn 1.7 is a new working copy format with >>> central metadata storage. It's based on SQLite database engine and we've >>> already implemented basic support for this new storage. That means that >>> first builds with full support of working copy operations will appear in >>> reasonable time after Subversion release. >>> >>> At the same time there are also enhancement in FSFS backend and HTTP/DAV >>> repository access. Some of them are backward compatible with the former >>> versions. Probably we will roll out these particular improvements in >>> minor releases after the major one. >>> >>> Please notice that the next major version of SVNKit is 1.7.0. We decided >>> to have the major version number similar to Subversion one. >>> >>> Thank you for your feedback. >>> >>> Semen Vadishev, >>> TMate Software, >>> http://svnkit.com/ - Java [Sub]Versioning Library! >>> http://sqljet.com/ - Java SQLite Library! >>> >>> >>> >>> On 3 May 2011 14:45, lazee wrote: >>>> 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? >>> >>> >>> >> |
|
|
Re: GNOME Keyring support
by Gnan Shabada
::
Rate this Message:
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
|
|
|
Re: GNOME Keyring support
by Semyon Vadishev
::
Rate this Message:
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! >> >> >> >> |
|
|
Re: GNOME Keyring support
by lazee
::
Rate this Message:
1. According to the test found in SVNJNAUtil.isJNAPresent() JNA is present in my build.
2. I have controlled that my login and password are in my keychain (After all it works fine with the 1.3.5 build). 3. I have created a test-app that can be downloaded here: www.jakobnielsen.net/etc/svnkit-test.zip The output from the app when running on 1.3.5 (Works fine): 0 [Tester.main()] INFO Tester - JNA is present according to SVNKIT! 53 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :FINE: Keep-Alive timeout detected 323 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT 706 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ 907 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT 1217 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ 1352 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT 1352 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT 1831 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ 1860 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ 2030 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT 2030 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT 2343 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ 2344 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ 2511 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT 2511 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT 2854 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ 2855 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ 3029 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT 3030 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT 3469 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ 3471 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ 3618 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT 3618 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT 3981 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ 3983 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ 4089 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT 4089 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT 4492 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ 4493 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ 4498 [Tester.main()] DEBUG InfoHandler - HandleInfo: org.tmatesoft.svn.core.wc.SVNInfo@4d12ee4f 4498 [Tester.main()] DEBUG InfoHandler - Setting repository info 4499 [Tester.main()] DEBUG Tester - Got info. Basedir : /people/jakob/test [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 11 seconds [INFO] Finished at: Sun May 08 18:26:50 CEST 2011 [INFO] Final Memory: 17M/265M [INFO] ------------------------------------------------------------------------ The output from the app when running on the 1.7.0-SNAPSHOT (Doesn't work): 0 [Tester.main()] INFO Tester - JNA is present according to SVNKIT! 23 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported working copy format 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported working copy format 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported working copy format 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported working copy format 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported working copy format 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported working copy format 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported working copy format 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported working copy format 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported working copy format 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported working copy format 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported working copy format 27 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported working copy format 265 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output stream requested... 266 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output stream requested... 266 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT 266 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output stream requested... 404 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ 816 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output stream requested... 816 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output stream requested... 816 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT 816 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output stream requested... 992 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ 993 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :FINE: svn: Authentication required for '<http://svn.something.no:80> SVN' 995 [Tester.main()] DEBUG Tester - SVNException: org.tmatesoft.svn.core.SVNAuthenticationException -> svn: Authentication required for '<http://svn.something.no:80> SVN' org.tmatesoft.svn.core.SVNAuthenticationException: svn: Authentication required for '<http://svn.something.no:80> SVN' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:47) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:41) at org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getNextAuthentication(DefaultSVNAuthenticationManager.java:218) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:565) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:280) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:268) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1007) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:179) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:480) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getLocations(SVNBasicDelegate.java:833) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:527) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2716) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2627) at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2202) at Tester.getRepositoryInfo(Tester.java:45) at Tester.run(Tester.java:39) at Tester.main(Tester.java:57) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:291) at java.lang.Thread.run(Thread.java:680) [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 6 seconds [INFO] Finished at: Sun May 08 18:14:31 CEST 2011 [INFO] Final Memory: 17M/265M [INFO] ------------------------------------------------------------------------ I do not like the "Unsupported working copy format" at all? I will set up a svn:/-test soon if this doesn't give you enough answers. I might also create a Maven build file so that I can test against a trunk build. Best regards Jakob Vad Nielsen
|
|
|
Re: GNOME Keyring support
by Semyon Vadishev
::
Rate this Message:
Hello Jakob,
Excuse me for the delay with this reply. > 1. According to the test found in SVNJNAUtil.isJNAPresent() JNA is present in > my build. > > 2. I have controlled that my login and password are in my keychain (After > all it works > fine with the 1.3.5 build). So it's not missing JNA library and it's not Keychain access problem. Unfortunately there are too many unstable changes in trunk which could lead to such behavior. If this problem is critical for you, it makes a lot of sense to use the latest stable versions, i.e. 1.3.x branch, instead of trunk. I've also created an issue in our tracker, you may find it here — http://issues.tmatesoft.com/issue/SVNKIT-6. > 3. I have created a test-app that can be downloaded here: > www.jakobnielsen.net/etc/svnkit-test.zip We're already using gradle + maven for trunk, but we decided to postpone applying the same scheme to 1.3.x branch. Here is the corresponding issue — http://issues.tmatesoft.com/issue/SVNKIT-3. Once we have snapshot builds for 1.3.x branch we will try to run the your code against the stable versions. > I do not like the "Unsupported working copy format" at all? I think it's expected message since your working copy seems to be in 1.6 format. To my knowledge Subversion 1.7 doesn't bump format version automatically. > I will set up a > svn:/-test soon if this doesn't give you enough answers. There are a few options how to localize the problem: 1. Try 1.3.x build. As I already mentioned there are no maven artifacts so far, but you may use available jars. 2. Try svn:// protocol to ensure the issue relates to HTTP authentication mechanism. 3. Try 'jsvn' utility from 1.7.0-alpha to check if there are certain problems with initialization of authentication manager. > I might also create a Maven build file so that I can test against a trunk > build. Do you mean that pom.xml located in svnkit-test archive? Semen Vadishev, TMate Software, http://svnkit.com/ - Java [Sub]Versioning Library! http://sqljet.com/ - Java SQLite Library! On 8 May 2011 18:34, lazee wrote: > 1. According to the test found in SVNJNAUtil.isJNAPresent() JNA is present in > my build. > > 2. I have controlled that my login and password are in my keychain (After > all it works > fine with the 1.3.5 build). > > 3. I have created a test-app that can be downloaded here: > www.jakobnielsen.net/etc/svnkit-test.zip > > The output from the app when running on 1.3.5 (Works fine): > > 0 [Tester.main()] INFO Tester - JNA is present according to SVNKIT! > 53 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :FINE: Keep-Alive timeout > detected > 323 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 706 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 907 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 1217 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 1352 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 1352 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 1831 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 1860 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 2030 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 2030 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 2343 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 2344 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 2511 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 2511 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 2854 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 2855 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 3029 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 3030 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 3469 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 3471 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 3618 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 3618 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 3981 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 3983 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 4089 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 4089 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 4492 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 4493 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 4498 [Tester.main()] DEBUG InfoHandler - HandleInfo: > org.tmatesoft.svn.core.wc.SVNInfo@4d12ee4f > 4498 [Tester.main()] DEBUG InfoHandler - Setting repository info > 4499 [Tester.main()] DEBUG Tester - Got info. Basedir : /people/jakob/test > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESSFUL > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 11 seconds > [INFO] Finished at: Sun May 08 18:26:50 CEST 2011 > [INFO] Final Memory: 17M/265M > [INFO] > ------------------------------------------------------------------------ > > > The output from the app when running on the 1.7.0-SNAPSHOT (Doesn't > work): > > 0 [Tester.main()] INFO Tester - JNA is present according to SVNKIT! > 23 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 27 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 265 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output > stream requested... > 266 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output > stream requested... > 266 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 266 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output > stream requested... > 404 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 816 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output > stream requested... > 816 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output > stream requested... > 816 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 816 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output > stream requested... > 992 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 993 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :FINE: svn: > Authentication required for '<http://svn.something.no:80> SVN' > 995 [Tester.main()] DEBUG Tester - SVNException: > org.tmatesoft.svn.core.SVNAuthenticationException -> svn: Authentication > required for '<http://svn.something.no:80> SVN' > org.tmatesoft.svn.core.SVNAuthenticationException: svn: Authentication > required for '<http://svn.something.no:80> SVN' > at > org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:47) > at > org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:41) > at > org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getNextAuthentication(DefaultSVNAuthenticationManager.java:218) > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:565) > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:280) > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:268) > at > org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) > at > org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) > at > org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1007) > at > org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:179) > at > org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:480) > at > org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getLocations(SVNBasicDelegate.java:833) > at > org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:527) > at > org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2716) > at > org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2627) > at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2202) > at Tester.getRepositoryInfo(Tester.java:45) > at Tester.run(Tester.java:39) > at Tester.main(Tester.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:291) > at java.lang.Thread.run(Thread.java:680) > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESSFUL > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 6 seconds > [INFO] Finished at: Sun May 08 18:14:31 CEST 2011 > [INFO] Final Memory: 17M/265M > [INFO] > ------------------------------------------------------------------------ > > > > I do not like the "Unsupported working copy format" at all? I will set up a > svn:/-test soon if this doesn't give you enough answers. > > I might also create a Maven build file so that I can test against a trunk > build. > > > Best regards > > Jakob Vad Nielsen > > > Semyon Vadishev wrote: >> I have tested 'jsvn' utility from 1.7.0 build on my OS X 10.5.8 and it >> worked just fine. >> >> There are certain differences between 1.3.5 and 'maven' branch (maven >> artifacts built from this branch, which is approximately trunk), but >> there are no API changes. >> >> I'm afraid the problem is somehow related to maven dependencies — SVNKit >> fails to access OS X Keychain with no JNA binaries at runtime. Could you >> check that JNA library is in classpath when you running the code. Debug >> log would be helpful here. Find the description how to get it here — >> https://wiki.svnkit.com/Troubleshooting. >> >> There are also internal changes, especially those related to HTTP >> authentication mechanisms. If that possible, could you please test >> authentication against some svnserve daemon, i.e. using svn:// protocol, >> not http://. >> >> If all above is not relevant for your particular case, let's see what >> could be wrong with the code. So, you have login and password stored in >> the keychain, right? Please ensure you do — find "<http://svn.api.no:80> >> SVN" item and check that access to the item is granted for Java >> applications. Otherwise it's not clear for me how do you provide the >> credentials for the corresponding realm. >> >> As I can see, you use the authentication manager which by default don't >> have any callback to provide necessary credentials, that means this >> authentication manager uses cached version of credentials. That means >> 1.3.5 build can read this cached data, but 1.7.0 version is not able to >> do that, thus we have a bug. >> >> Not to bother you with such non-stable builds, you might want to wait >> until we merge gradle/maven changes back to trunk and 1.3.x branches. So >> you can try pure trunk version or pre-release 1.3.6 build soon. >> >> Also you may try old-school jar-based way. You can download necessary >> jars from our build server — 1.3.x >> https://teamcity.svnkit.com/repository/download/bt22/14050:id/deploy/org.tmatesoft.svn_1.3.5.7590.standalone.zip >> and trunk >> https://teamcity.svnkit.com/repository/download/bt3/14080:id/deploy/org.tmatesoft.svn_1.4.0.7613.standalone.zip. >> Log in as a guest if prompted. >> >> Thank you. >> >> Semen Vadishev, >> TMate Software, >> http://svnkit.com/ - Java [Sub]Versioning Library! >> http://sqljet.com/ - Java SQLite Library! >> >> >> On 3 May 2011 20:27, lazee wrote: >>> This is the way I initialize the client: >>> >>> clientManager = SVNClientManager.newInstance(); >>> SVNRepositoryFactoryImpl.setup(); >>> if (log.isDebugEnabled()) { >>> SvnDebugLogger.initSvnDebugLogger(); >>> } >>> DAVRepositoryFactory.setup(); >>> FSRepositoryFactory.setup(); >>> >>> >>> >>> lazee wrote: >>>> Thnx, I have now done some testing on 1.7.0-SNAPSHOT. >>>> >>>> It seems that the Keychain support on Mac OSX (10.6.7) doesn't work >>>> anymore. With SvnKit 1.3.5 I am able to work against a local test >>>> repository. With 1.7.0-SNAPSHOT I get this error: >>>> >>>> SVNException: org.tmatesoft.svn.core.SVNAuthenticationException -> svn: >>>> Authentication required for '<http://svn.api.no:80> SVN' >>>> org.tmatesoft.svn.core.SVNAuthenticationException: svn: Authentication >>>> required for '<http://svn.api.no:80> SVN' >>>> at >>>> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:47) >>>> at >>>> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:41) >>>> at >>>> org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getNextAuthentication(DefaultSVNAuthenticationManager.java:218) >>>> at >>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:564) >>>> at >>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:280) >>>> at >>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:268) >>>> at >>>> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) >>>> at >>>> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) >>>> at >>>> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1007) >>>> at >>>> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:179) >>>> at >>>> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:480) >>>> at >>>> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getLocations(SVNBasicDelegate.java:833) >>>> at >>>> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:527) >>>> at >>>> org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2716) >>>> at >>>> org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2627) >>>> at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2202) >>>> >>>> >>>> Any changes in the API that I should be aware of? >>>> >>>> >>>> >>>> Semyon Vadishev wrote: >>>>> Hi, >>>>> >>>>>> 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. >>>>> Agree. We're currently migrating to gradle, as a build tool, and >>>>> Sonatype Nexus, as artifact repository, for all our projects. I think >>>>> we >>>>> will set up the environment in a week or two, so we will publish >>>>> nightly >>>>> builds as maven artifacts soon. We will release SVNKit 1.3.6 with GNOME >>>>> Keyring support and some other enhancements a bit later. >>>>> >>>>> Meanwhile you may try builds from our trunk which are already in Maven >>>>> repository — >>>>> http://maven.tmatesoft.com/index.html#nexus-search;quick~svnkit. They >>>>> are no stable yet, but they do support GNOME keyring. The description >>>>> from my first email of the thread is still valid for these builds. >>>>> >>>>> If you're going to test authentication cache only, it's much safer to >>>>> use remote operations — ls, info, etc. >>>>> >>>>>> 2. When do you expect 1.4.0 to be released? >>>>> Usually we roll out the major release in a month after Subversion >>>>> release. According to Subversion roadmap — >>>>> http://subversion.apache.org/roadmap.html, there is certain features >>>>> development still in progress. So we don't have schedule yet. >>>>> >>>>> The most important feature of svn 1.7 is a new working copy format with >>>>> central metadata storage. It's based on SQLite database engine and >>>>> we've >>>>> already implemented basic support for this new storage. That means that >>>>> first builds with full support of working copy operations will appear >>>>> in >>>>> reasonable time after Subversion release. >>>>> >>>>> At the same time there are also enhancement in FSFS backend and >>>>> HTTP/DAV >>>>> repository access. Some of them are backward compatible with the former >>>>> versions. Probably we will roll out these particular improvements in >>>>> minor releases after the major one. >>>>> >>>>> Please notice that the next major version of SVNKit is 1.7.0. We >>>>> decided >>>>> to have the major version number similar to Subversion one. >>>>> >>>>> Thank you for your feedback. >>>>> >>>>> Semen Vadishev, >>>>> TMate Software, >>>>> http://svnkit.com/ - Java [Sub]Versioning Library! >>>>> http://sqljet.com/ - Java SQLite Library! >>>>> >>>>> >>>>> >>>>> On 3 May 2011 14:45, lazee wrote: >>>>>> 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? >>>>> >>>>> >> >> >> |
|
|
Re: GNOME Keyring support
by Semyon Vadishev
::
Rate this Message:
Hello Jakob,
1.3.x snapshots are already available in our maven repository. Can you please test this version of SVNKit? Thanks in advance. Semen Vadishev, TMate Software, http://svnkit.com/ - Java [Sub]Versioning Library! http://sqljet.com/ - Java SQLite Library! On May 8, 2011 20:34 , lazee wrote: > 1. According to the test found in SVNJNAUtil.isJNAPresent() JNA is present in > my build. > > 2. I have controlled that my login and password are in my keychain (After > all it works > fine with the 1.3.5 build). > > 3. I have created a test-app that can be downloaded here: > www.jakobnielsen.net/etc/svnkit-test.zip > > The output from the app when running on 1.3.5 (Works fine): > > 0 [Tester.main()] INFO Tester - JNA is present according to SVNKIT! > 53 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :FINE: Keep-Alive timeout > detected > 323 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 706 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 907 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 1217 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 1352 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 1352 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 1831 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 1860 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 2030 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 2030 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 2343 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 2344 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 2511 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 2511 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 2854 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 2855 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 3029 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 3030 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 3469 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 3471 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 3618 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 3618 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 3981 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 3983 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 4089 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 4089 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 4492 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 4493 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 4498 [Tester.main()] DEBUG InfoHandler - HandleInfo: > org.tmatesoft.svn.core.wc.SVNInfo@4d12ee4f > 4498 [Tester.main()] DEBUG InfoHandler - Setting repository info > 4499 [Tester.main()] DEBUG Tester - Got info. Basedir : /people/jakob/test > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESSFUL > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 11 seconds > [INFO] Finished at: Sun May 08 18:26:50 CEST 2011 > [INFO] Final Memory: 17M/265M > [INFO] > ------------------------------------------------------------------------ > > > The output from the app when running on the 1.7.0-SNAPSHOT (Doesn't > work): > > 0 [Tester.main()] INFO Tester - JNA is present according to SVNKIT! > 23 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 27 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 265 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output > stream requested... > 266 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output > stream requested... > 266 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 266 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output > stream requested... > 404 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 816 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output > stream requested... > 816 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output > stream requested... > 816 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 816 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output > stream requested... > 992 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 993 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :FINE: svn: > Authentication required for '<http://svn.something.no:80> SVN' > 995 [Tester.main()] DEBUG Tester - SVNException: > org.tmatesoft.svn.core.SVNAuthenticationException -> svn: Authentication > required for '<http://svn.something.no:80> SVN' > org.tmatesoft.svn.core.SVNAuthenticationException: svn: Authentication > required for '<http://svn.something.no:80> SVN' > at > org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:47) > at > org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:41) > at > org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getNextAuthentication(DefaultSVNAuthenticationManager.java:218) > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:565) > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:280) > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:268) > at > org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) > at > org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) > at > org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1007) > at > org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:179) > at > org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:480) > at > org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getLocations(SVNBasicDelegate.java:833) > at > org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:527) > at > org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2716) > at > org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2627) > at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2202) > at Tester.getRepositoryInfo(Tester.java:45) > at Tester.run(Tester.java:39) > at Tester.main(Tester.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:291) > at java.lang.Thread.run(Thread.java:680) > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESSFUL > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 6 seconds > [INFO] Finished at: Sun May 08 18:14:31 CEST 2011 > [INFO] Final Memory: 17M/265M > [INFO] > ------------------------------------------------------------------------ > > > > I do not like the "Unsupported working copy format" at all? I will set up a > svn:/-test soon if this doesn't give you enough answers. > > I might also create a Maven build file so that I can test against a trunk > build. > > > Best regards > > Jakob Vad Nielsen > > > Semyon Vadishev wrote: >> I have tested 'jsvn' utility from 1.7.0 build on my OS X 10.5.8 and it >> worked just fine. >> >> There are certain differences between 1.3.5 and 'maven' branch (maven >> artifacts built from this branch, which is approximately trunk), but >> there are no API changes. >> >> I'm afraid the problem is somehow related to maven dependencies — SVNKit >> fails to access OS X Keychain with no JNA binaries at runtime. Could you >> check that JNA library is in classpath when you running the code. Debug >> log would be helpful here. Find the description how to get it here — >> https://wiki.svnkit.com/Troubleshooting. >> >> There are also internal changes, especially those related to HTTP >> authentication mechanisms. If that possible, could you please test >> authentication against some svnserve daemon, i.e. using svn:// protocol, >> not http://. >> >> If all above is not relevant for your particular case, let's see what >> could be wrong with the code. So, you have login and password stored in >> the keychain, right? Please ensure you do — find "<http://svn.api.no:80> >> SVN" item and check that access to the item is granted for Java >> applications. Otherwise it's not clear for me how do you provide the >> credentials for the corresponding realm. >> >> As I can see, you use the authentication manager which by default don't >> have any callback to provide necessary credentials, that means this >> authentication manager uses cached version of credentials. That means >> 1.3.5 build can read this cached data, but 1.7.0 version is not able to >> do that, thus we have a bug. >> >> Not to bother you with such non-stable builds, you might want to wait >> until we merge gradle/maven changes back to trunk and 1.3.x branches. So >> you can try pure trunk version or pre-release 1.3.6 build soon. >> >> Also you may try old-school jar-based way. You can download necessary >> jars from our build server — 1.3.x >> https://teamcity.svnkit.com/repository/download/bt22/14050:id/deploy/org.tmatesoft.svn_1.3.5.7590.standalone.zip >> and trunk >> https://teamcity.svnkit.com/repository/download/bt3/14080:id/deploy/org.tmatesoft.svn_1.4.0.7613.standalone.zip. >> Log in as a guest if prompted. >> >> Thank you. >> >> Semen Vadishev, >> TMate Software, >> http://svnkit.com/ - Java [Sub]Versioning Library! >> http://sqljet.com/ - Java SQLite Library! >> >> >> On 3 May 2011 20:27, lazee wrote: >>> This is the way I initialize the client: >>> >>> clientManager = SVNClientManager.newInstance(); >>> SVNRepositoryFactoryImpl.setup(); >>> if (log.isDebugEnabled()) { >>> SvnDebugLogger.initSvnDebugLogger(); >>> } >>> DAVRepositoryFactory.setup(); >>> FSRepositoryFactory.setup(); >>> >>> >>> >>> lazee wrote: >>>> Thnx, I have now done some testing on 1.7.0-SNAPSHOT. >>>> >>>> It seems that the Keychain support on Mac OSX (10.6.7) doesn't work >>>> anymore. With SvnKit 1.3.5 I am able to work against a local test >>>> repository. With 1.7.0-SNAPSHOT I get this error: >>>> >>>> SVNException: org.tmatesoft.svn.core.SVNAuthenticationException -> svn: >>>> Authentication required for '<http://svn.api.no:80> SVN' >>>> org.tmatesoft.svn.core.SVNAuthenticationException: svn: Authentication >>>> required for '<http://svn.api.no:80> SVN' >>>> at >>>> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:47) >>>> at >>>> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:41) >>>> at >>>> org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getNextAuthentication(DefaultSVNAuthenticationManager.java:218) >>>> at >>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:564) >>>> at >>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:280) >>>> at >>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:268) >>>> at >>>> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) >>>> at >>>> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) >>>> at >>>> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1007) >>>> at >>>> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:179) >>>> at >>>> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:480) >>>> at >>>> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getLocations(SVNBasicDelegate.java:833) >>>> at >>>> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:527) >>>> at >>>> org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2716) >>>> at >>>> org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2627) >>>> at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2202) >>>> >>>> >>>> Any changes in the API that I should be aware of? >>>> >>>> >>>> >>>> Semyon Vadishev wrote: >>>>> Hi, >>>>> >>>>>> 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. >>>>> Agree. We're currently migrating to gradle, as a build tool, and >>>>> Sonatype Nexus, as artifact repository, for all our projects. I think >>>>> we >>>>> will set up the environment in a week or two, so we will publish >>>>> nightly >>>>> builds as maven artifacts soon. We will release SVNKit 1.3.6 with GNOME >>>>> Keyring support and some other enhancements a bit later. >>>>> >>>>> Meanwhile you may try builds from our trunk which are already in Maven >>>>> repository — >>>>> http://maven.tmatesoft.com/index.html#nexus-search;quick~svnkit. They >>>>> are no stable yet, but they do support GNOME keyring. The description >>>>> from my first email of the thread is still valid for these builds. >>>>> >>>>> If you're going to test authentication cache only, it's much safer to >>>>> use remote operations — ls, info, etc. >>>>> >>>>>> 2. When do you expect 1.4.0 to be released? >>>>> Usually we roll out the major release in a month after Subversion >>>>> release. According to Subversion roadmap — >>>>> http://subversion.apache.org/roadmap.html, there is certain features >>>>> development still in progress. So we don't have schedule yet. >>>>> >>>>> The most important feature of svn 1.7 is a new working copy format with >>>>> central metadata storage. It's based on SQLite database engine and >>>>> we've >>>>> already implemented basic support for this new storage. That means that >>>>> first builds with full support of working copy operations will appear >>>>> in >>>>> reasonable time after Subversion release. >>>>> >>>>> At the same time there are also enhancement in FSFS backend and >>>>> HTTP/DAV >>>>> repository access. Some of them are backward compatible with the former >>>>> versions. Probably we will roll out these particular improvements in >>>>> minor releases after the major one. >>>>> >>>>> Please notice that the next major version of SVNKit is 1.7.0. We >>>>> decided >>>>> to have the major version number similar to Subversion one. >>>>> >>>>> Thank you for your feedback. >>>>> >>>>> Semen Vadishev, >>>>> TMate Software, >>>>> http://svnkit.com/ - Java [Sub]Versioning Library! >>>>> http://sqljet.com/ - Java SQLite Library! >>>>> >>>>> >>>>> >>>>> On 3 May 2011 14:45, lazee wrote: >>>>>> 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? >>>>> >>>>> >> >> >> |
|
|
Re: GNOME Keyring support
by lazee
::
Rate this Message:
Nice! I sure will try it right now!
|
|
|
Re: GNOME Keyring support
by lazee
::
Rate this Message:
Hi Semen,
http://maven.tmatesoft.com/content/groups/public seems to be password protected, which makes it hard to add it as a Maven repository in my pom.xml. /Jakob
|
|
|
Re: GNOME Keyring support
by Semyon Vadishev
::
Rate this Message:
> http://maven.tmatesoft.com/content/groups/public seems to be password
> protected Sorry, try this one — http://maven.tmatesoft.com/content/repositories/snapshots/ Semen Vadishev, TMate Software, http://svnkit.com/ - Java [Sub]Versioning Library! http://sqljet.com/ - Java SQLite Library! On May 30, 2011 13:54 , lazee wrote: > Hi Semen, > > http://maven.tmatesoft.com/content/groups/public seems to be password > protected, which makes it hard to add it as a Maven repository in my > pom.xml. > > /Jakob > > > Semyon Vadishev wrote: >> Hello Jakob, >> >> 1.3.x snapshots are already available in our maven repository. Can you >> please test this version of SVNKit? >> >> Thanks in advance. >> >> Semen Vadishev, >> TMate Software, >> http://svnkit.com/ - Java [Sub]Versioning Library! >> http://sqljet.com/ - Java SQLite Library! >> >> >> On May 8, 2011 20:34 , lazee wrote: >>> 1. According to the test found in SVNJNAUtil.isJNAPresent() JNA is >>> present in >>> my build. >>> >>> 2. I have controlled that my login and password are in my keychain (After >>> all it works >>> fine with the 1.3.5 build). >>> >>> 3. I have created a test-app that can be downloaded here: >>> www.jakobnielsen.net/etc/svnkit-test.zip >>> >>> The output from the app when running on 1.3.5 (Works fine): >>> >>> 0 [Tester.main()] INFO Tester - JNA is present according to SVNKIT! >>> 53 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :FINE: Keep-Alive >>> timeout >>> detected >>> 323 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 706 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 907 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 1217 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 1352 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 1352 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 1831 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 1860 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 2030 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 2030 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 2343 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 2344 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 2511 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 2511 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 2854 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 2855 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 3029 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 3030 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 3469 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 3471 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 3618 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 3618 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 3981 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 3983 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 4089 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 4089 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 4492 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 4493 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 4498 [Tester.main()] DEBUG InfoHandler - HandleInfo: >>> org.tmatesoft.svn.core.wc.SVNInfo@4d12ee4f >>> 4498 [Tester.main()] DEBUG InfoHandler - Setting repository info >>> 4499 [Tester.main()] DEBUG Tester - Got info. Basedir : >>> /people/jakob/test >>> [INFO] >>> ------------------------------------------------------------------------ >>> [INFO] BUILD SUCCESSFUL >>> [INFO] >>> ------------------------------------------------------------------------ >>> [INFO] Total time: 11 seconds >>> [INFO] Finished at: Sun May 08 18:26:50 CEST 2011 >>> [INFO] Final Memory: 17M/265M >>> [INFO] >>> ------------------------------------------------------------------------ >>> >>> >>> The output from the app when running on the 1.7.0-SNAPSHOT (Doesn't >>> work): >>> >>> 0 [Tester.main()] INFO Tester - JNA is present according to SVNKIT! >>> 23 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 27 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 265 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output >>> stream requested... >>> 266 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output >>> stream requested... >>> 266 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 266 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output >>> stream requested... >>> 404 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 816 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output >>> stream requested... >>> 816 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output >>> stream requested... >>> 816 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 816 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output >>> stream requested... >>> 992 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 993 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :FINE: svn: >>> Authentication required for '<http://svn.something.no:80> SVN' >>> 995 [Tester.main()] DEBUG Tester - SVNException: >>> org.tmatesoft.svn.core.SVNAuthenticationException -> svn: Authentication >>> required for '<http://svn.something.no:80> SVN' >>> org.tmatesoft.svn.core.SVNAuthenticationException: svn: Authentication >>> required for '<http://svn.something.no:80> SVN' >>> at >>> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:47) >>> at >>> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:41) >>> at >>> org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getNextAuthentication(DefaultSVNAuthenticationManager.java:218) >>> at >>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:565) >>> at >>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:280) >>> at >>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:268) >>> at >>> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) >>> at >>> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) >>> at >>> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1007) >>> at >>> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:179) >>> at >>> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:480) >>> at >>> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getLocations(SVNBasicDelegate.java:833) >>> at >>> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:527) >>> at >>> org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2716) >>> at >>> org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2627) >>> at >>> org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2202) >>> at Tester.getRepositoryInfo(Tester.java:45) >>> at Tester.run(Tester.java:39) >>> at Tester.main(Tester.java:57) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >>> at java.lang.reflect.Method.invoke(Method.java:597) >>> at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:291) >>> at java.lang.Thread.run(Thread.java:680) >>> [INFO] >>> ------------------------------------------------------------------------ >>> [INFO] BUILD SUCCESSFUL >>> [INFO] >>> ------------------------------------------------------------------------ >>> [INFO] Total time: 6 seconds >>> [INFO] Finished at: Sun May 08 18:14:31 CEST 2011 >>> [INFO] Final Memory: 17M/265M >>> [INFO] >>> ------------------------------------------------------------------------ >>> >>> >>> >>> I do not like the "Unsupported working copy format" at all? I will set up >>> a >>> svn:/-test soon if this doesn't give you enough answers. >>> >>> I might also create a Maven build file so that I can test against a trunk >>> build. >>> >>> >>> Best regards >>> >>> Jakob Vad Nielsen >>> >>> >>> Semyon Vadishev wrote: >>>> I have tested 'jsvn' utility from 1.7.0 build on my OS X 10.5.8 and it >>>> worked just fine. >>>> >>>> There are certain differences between 1.3.5 and 'maven' branch (maven >>>> artifacts built from this branch, which is approximately trunk), but >>>> there are no API changes. >>>> >>>> I'm afraid the problem is somehow related to maven dependencies — SVNKit >>>> fails to access OS X Keychain with no JNA binaries at runtime. Could you >>>> check that JNA library is in classpath when you running the code. Debug >>>> log would be helpful here. Find the description how to get it here — >>>> https://wiki.svnkit.com/Troubleshooting. >>>> >>>> There are also internal changes, especially those related to HTTP >>>> authentication mechanisms. If that possible, could you please test >>>> authentication against some svnserve daemon, i.e. using svn:// protocol, >>>> not http://. >>>> >>>> If all above is not relevant for your particular case, let's see what >>>> could be wrong with the code. So, you have login and password stored in >>>> the keychain, right? Please ensure you do — find "<http://svn.api.no:80> >>>> SVN" item and check that access to the item is granted for Java >>>> applications. Otherwise it's not clear for me how do you provide the >>>> credentials for the corresponding realm. >>>> >>>> As I can see, you use the authentication manager which by default don't >>>> have any callback to provide necessary credentials, that means this >>>> authentication manager uses cached version of credentials. That means >>>> 1.3.5 build can read this cached data, but 1.7.0 version is not able to >>>> do that, thus we have a bug. >>>> >>>> Not to bother you with such non-stable builds, you might want to wait >>>> until we merge gradle/maven changes back to trunk and 1.3.x branches. So >>>> you can try pure trunk version or pre-release 1.3.6 build soon. >>>> >>>> Also you may try old-school jar-based way. You can download necessary >>>> jars from our build server — 1.3.x >>>> https://teamcity.svnkit.com/repository/download/bt22/14050:id/deploy/org.tmatesoft.svn_1.3.5.7590.standalone.zip >>>> and trunk >>>> https://teamcity.svnkit.com/repository/download/bt3/14080:id/deploy/org.tmatesoft.svn_1.4.0.7613.standalone.zip. >>>> Log in as a guest if prompted. >>>> >>>> Thank you. >>>> >>>> Semen Vadishev, >>>> TMate Software, >>>> http://svnkit.com/ - Java [Sub]Versioning Library! >>>> http://sqljet.com/ - Java SQLite Library! >>>> >>>> >>>> On 3 May 2011 20:27, lazee wrote: >>>>> This is the way I initialize the client: >>>>> >>>>> clientManager = SVNClientManager.newInstance(); >>>>> SVNRepositoryFactoryImpl.setup(); >>>>> if (log.isDebugEnabled()) { >>>>> SvnDebugLogger.initSvnDebugLogger(); >>>>> } >>>>> DAVRepositoryFactory.setup(); >>>>> FSRepositoryFactory.setup(); >>>>> >>>>> >>>>> >>>>> lazee wrote: >>>>>> Thnx, I have now done some testing on 1.7.0-SNAPSHOT. >>>>>> >>>>>> It seems that the Keychain support on Mac OSX (10.6.7) doesn't work >>>>>> anymore. With SvnKit 1.3.5 I am able to work against a local test >>>>>> repository. With 1.7.0-SNAPSHOT I get this error: >>>>>> >>>>>> SVNException: org.tmatesoft.svn.core.SVNAuthenticationException -> >>>>>> svn: >>>>>> Authentication required for '<http://svn.api.no:80> SVN' >>>>>> org.tmatesoft.svn.core.SVNAuthenticationException: svn: Authentication >>>>>> required for '<http://svn.api.no:80> SVN' >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:47) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:41) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getNextAuthentication(DefaultSVNAuthenticationManager.java:218) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:564) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:280) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:268) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1007) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:179) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:480) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getLocations(SVNBasicDelegate.java:833) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:527) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2716) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2627) >>>>>> at >>>>>> org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2202) >>>>>> >>>>>> >>>>>> Any changes in the API that I should be aware of? >>>>>> >>>>>> >>>>>> >>>>>> Semyon Vadishev wrote: >>>>>>> Hi, >>>>>>> >>>>>>>> 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. >>>>>>> Agree. We're currently migrating to gradle, as a build tool, and >>>>>>> Sonatype Nexus, as artifact repository, for all our projects. I think >>>>>>> we >>>>>>> will set up the environment in a week or two, so we will publish >>>>>>> nightly >>>>>>> builds as maven artifacts soon. We will release SVNKit 1.3.6 with >>>>>>> GNOME >>>>>>> Keyring support and some other enhancements a bit later. >>>>>>> >>>>>>> Meanwhile you may try builds from our trunk which are already in >>>>>>> Maven >>>>>>> repository — >>>>>>> http://maven.tmatesoft.com/index.html#nexus-search;quick~svnkit. They >>>>>>> are no stable yet, but they do support GNOME keyring. The description >>>>>>> from my first email of the thread is still valid for these builds. >>>>>>> >>>>>>> If you're going to test authentication cache only, it's much safer to >>>>>>> use remote operations — ls, info, etc. >>>>>>> >>>>>>>> 2. When do you expect 1.4.0 to be released? >>>>>>> Usually we roll out the major release in a month after Subversion >>>>>>> release. According to Subversion roadmap — >>>>>>> http://subversion.apache.org/roadmap.html, there is certain features >>>>>>> development still in progress. So we don't have schedule yet. >>>>>>> >>>>>>> The most important feature of svn 1.7 is a new working copy format >>>>>>> with >>>>>>> central metadata storage. It's based on SQLite database engine and >>>>>>> we've >>>>>>> already implemented basic support for this new storage. That means >>>>>>> that >>>>>>> first builds with full support of working copy operations will appear >>>>>>> in >>>>>>> reasonable time after Subversion release. >>>>>>> >>>>>>> At the same time there are also enhancement in FSFS backend and >>>>>>> HTTP/DAV >>>>>>> repository access. Some of them are backward compatible with the >>>>>>> former >>>>>>> versions. Probably we will roll out these particular improvements in >>>>>>> minor releases after the major one. >>>>>>> >>>>>>> Please notice that the next major version of SVNKit is 1.7.0. We >>>>>>> decided >>>>>>> to have the major version number similar to Subversion one. >>>>>>> >>>>>>> Thank you for your feedback. >>>>>>> >>>>>>> Semen Vadishev, >>>>>>> TMate Software, >>>>>>> http://svnkit.com/ - Java [Sub]Versioning Library! >>>>>>> http://sqljet.com/ - Java SQLite Library! >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 3 May 2011 14:45, lazee wrote: >>>>>>>> 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? >>>>>>> >>>> >>>> >> >> |
|
|
Re: GNOME Keyring support
by lazee
::
Rate this Message:
Hmm,
I've added : <repositories> <repository> <id>tmatesoft</id> <snapshots> <enabled>true</enabled> </snapshots> <!--<url>http://maven.tmatesoft.com/content/groups/public</url>--> <url>http://maven.tmatesoft.com/content/repositories/snapshots</url> </repository> </repositories> to my pom.xml. And sets: <dependency> <groupId>org.tmatesoft.svnkit</groupId> <artifactId>svnkit</artifactId> <version>1.3.6-SNAPSHOT</version> </dependency> But Maven says: Downloading: http://maven.tmatesoft.com/content/repositories/snapshots/org/tmatesoft/svnkit/svnkit/1.3.6-SNAPSHOT/svnkit-1.3.6-SNAPSHOT.pom [INFO] Unable to find resource 'org.tmatesoft.svnkit:svnkit:pom:1.3.6-SNAPSHOT' in repository tmatesoft (http://maven.tmatesoft.com/content/repositories/snapshots) Might be something I'm doing wrong here?. I could install this package manually, but that makes it hard to test on further changes in this branch. Given that I'll have to do it for every new snapshot. /Jakob
|
|
|
Re: GNOME Keyring support
by lazee
::
Rate this Message:
I've managed to build the 1.3.6-SNAPSHOT from http://svn.svnkit.com/repos/svnkit/branches/1.3.x (Hopefully this is correct?)
But I still get this error on my Linux test server. Might be something I'm doing wrong though? The source code is available here : https://github.com/lazee/JRBC Error: svn: Authentication required for '<http://foo.local:80> SVN' SVNException: org.tmatesoft.svn.core.SVNAuthenticationException -> svn: Authentication required for '<http://svn.foo.no:80> SVN' org.tmatesoft.svn.core.SVNAuthenticationException: svn: Authentication required for '<http://svn.foo.no:80> SVN' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:47) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:41) at org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getFirstAuthentication(DefaultSVNAuthenticationManager.java:182) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:563) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:280) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:268) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1007) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:179) at org.tmatesoft.svn.core.wc.SVNBasicClient.getRevisionNumber(SVNBasicClient.java:482) at org.tmatesoft.svn.core.wc.SVNBasicClient.getLocations(SVNBasicClient.java:876) at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:534) at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2571) at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2494) at net.jakobnielsen.jrbc.svn.SvnSupport.getRepositoryInfo(SvnSupport.java:119)
|
|
|
Re: GNOME Keyring support
by Semyon Vadishev
::
Rate this Message:
Hi,
> I've managed to build the 1.3.6-SNAPSHOT from > http://svn.svnkit.com/repos/svnkit/branches/1.3.x (Hopefully this is > correct?) Yes, that's correct version to use. We've restarted our Maven repository. If this repository was the reason of the failure yesterday, it must be fixed now. > But I still get this error on my Linux test server. Might be something I'm > doing wrong though? I had a look into your code, and it seems repository access always relies on cached credentials, which generally is not acceptable for tools like yours. I'd implement some proper authentication provider just like this one we have already implemented for our command line interface — https://svn.svnkit.com/repos/svnkit/branches/1.3.x/svnkit-cli/src/main/java/org/tmatesoft/svn/cli/SVNConsoleAuthenticationProvider.java Find usages of the class, they are quite straightforward. All it does — asks user for login, password, client certificate file, passphrase, etc. If caching is supported in corresponding environment, credentials cached automatically once user successfully authenticated. Regarding password storages: - Currently caching works fine on Windows and OS X (both 10.5.x and 10.6.x). - On Linux with GNOME you have to set certain system variable to make it work — I've described that in my initial email of this thread. - On Linux with KDE SVNKit is not able to securely save passwords, though Subversion does support that. - With other operating systems and desktop environments both Subversion and SVNKit can save passwords in plain text only, i.e. not securely. I'm afraid on your Linux server SVNKit failed to find necessary GNOME libraries to work with keyring. As result it could not read password from the cache and could not authenticate when repository requested credentials. Semen Vadishev, TMate Software, http://svnkit.com/ - Java [Sub]Versioning Library! http://sqljet.com/ - Java SQLite Library! On May 31, 2011 16:37 , lazee wrote: > I've managed to build the 1.3.6-SNAPSHOT from > http://svn.svnkit.com/repos/svnkit/branches/1.3.x (Hopefully this is > correct?) > > But I still get this error on my Linux test server. Might be something I'm > doing wrong though? > > The source code is available here : https://github.com/lazee/JRBC > > Error: > > svn: Authentication required for '<http://foo.local:80> SVN' > SVNException: org.tmatesoft.svn.core.SVNAuthenticationException -> svn: > Authentication required for '<http://svn.foo.no:80> SVN' > org.tmatesoft.svn.core.SVNAuthenticationException: svn: Authentication > required for '<http://svn.foo.no:80> SVN' > at > org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:47) > at > org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:41) > at > org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getFirstAuthentication(DefaultSVNAuthenticationManager.java:182) > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:563) > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:280) > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:268) > at > org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) > at > org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) > at > org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1007) > at > org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:179) > at > org.tmatesoft.svn.core.wc.SVNBasicClient.getRevisionNumber(SVNBasicClient.java:482) > at > org.tmatesoft.svn.core.wc.SVNBasicClient.getLocations(SVNBasicClient.java:876) > at > org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:534) > at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2571) > at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2494) > at > net.jakobnielsen.jrbc.svn.SvnSupport.getRepositoryInfo(SvnSupport.java:119) > > > > > > > Semyon Vadishev wrote: >> Hello Jakob, >> >> 1.3.x snapshots are already available in our maven repository. Can you >> please test this version of SVNKit? >> >> Thanks in advance. >> >> Semen Vadishev, >> TMate Software, >> http://svnkit.com/ - Java [Sub]Versioning Library! >> http://sqljet.com/ - Java SQLite Library! >> >> >> On May 8, 2011 20:34 , lazee wrote: >>> 1. According to the test found in SVNJNAUtil.isJNAPresent() JNA is >>> present in >>> my build. >>> >>> 2. I have controlled that my login and password are in my keychain (After >>> all it works >>> fine with the 1.3.5 build). >>> >>> 3. I have created a test-app that can be downloaded here: >>> www.jakobnielsen.net/etc/svnkit-test.zip >>> >>> The output from the app when running on 1.3.5 (Works fine): >>> >>> 0 [Tester.main()] INFO Tester - JNA is present according to SVNKIT! >>> 53 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :FINE: Keep-Alive >>> timeout >>> detected >>> 323 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 706 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 907 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 1217 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 1352 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 1352 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 1831 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 1860 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 2030 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 2030 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 2343 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 2344 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 2511 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 2511 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 2854 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 2855 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 3029 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 3030 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 3469 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 3471 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 3618 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 3618 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 3981 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 3983 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 4089 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 4089 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 4492 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 4493 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 4498 [Tester.main()] DEBUG InfoHandler - HandleInfo: >>> org.tmatesoft.svn.core.wc.SVNInfo@4d12ee4f >>> 4498 [Tester.main()] DEBUG InfoHandler - Setting repository info >>> 4499 [Tester.main()] DEBUG Tester - Got info. Basedir : >>> /people/jakob/test >>> [INFO] >>> ------------------------------------------------------------------------ >>> [INFO] BUILD SUCCESSFUL >>> [INFO] >>> ------------------------------------------------------------------------ >>> [INFO] Total time: 11 seconds >>> [INFO] Finished at: Sun May 08 18:26:50 CEST 2011 >>> [INFO] Final Memory: 17M/265M >>> [INFO] >>> ------------------------------------------------------------------------ >>> >>> >>> The output from the app when running on the 1.7.0-SNAPSHOT (Doesn't >>> work): >>> >>> 0 [Tester.main()] INFO Tester - JNA is present according to SVNKIT! >>> 23 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 27 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >>> working copy format >>> 265 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output >>> stream requested... >>> 266 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output >>> stream requested... >>> 266 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 266 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output >>> stream requested... >>> 404 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 816 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output >>> stream requested... >>> 816 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output >>> stream requested... >>> 816 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >>> 816 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output >>> stream requested... >>> 992 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >>> 993 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :FINE: svn: >>> Authentication required for '<http://svn.something.no:80> SVN' >>> 995 [Tester.main()] DEBUG Tester - SVNException: >>> org.tmatesoft.svn.core.SVNAuthenticationException -> svn: Authentication >>> required for '<http://svn.something.no:80> SVN' >>> org.tmatesoft.svn.core.SVNAuthenticationException: svn: Authentication >>> required for '<http://svn.something.no:80> SVN' >>> at >>> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:47) >>> at >>> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:41) >>> at >>> org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getNextAuthentication(DefaultSVNAuthenticationManager.java:218) >>> at >>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:565) >>> at >>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:280) >>> at >>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:268) >>> at >>> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) >>> at >>> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) >>> at >>> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1007) >>> at >>> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:179) >>> at >>> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:480) >>> at >>> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getLocations(SVNBasicDelegate.java:833) >>> at >>> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:527) >>> at >>> org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2716) >>> at >>> org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2627) >>> at >>> org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2202) >>> at Tester.getRepositoryInfo(Tester.java:45) >>> at Tester.run(Tester.java:39) >>> at Tester.main(Tester.java:57) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >>> at java.lang.reflect.Method.invoke(Method.java:597) >>> at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:291) >>> at java.lang.Thread.run(Thread.java:680) >>> [INFO] >>> ------------------------------------------------------------------------ >>> [INFO] BUILD SUCCESSFUL >>> [INFO] >>> ------------------------------------------------------------------------ >>> [INFO] Total time: 6 seconds >>> [INFO] Finished at: Sun May 08 18:14:31 CEST 2011 >>> [INFO] Final Memory: 17M/265M >>> [INFO] >>> ------------------------------------------------------------------------ >>> >>> >>> >>> I do not like the "Unsupported working copy format" at all? I will set up >>> a >>> svn:/-test soon if this doesn't give you enough answers. >>> >>> I might also create a Maven build file so that I can test against a trunk >>> build. >>> >>> >>> Best regards >>> >>> Jakob Vad Nielsen >>> >>> >>> Semyon Vadishev wrote: >>>> I have tested 'jsvn' utility from 1.7.0 build on my OS X 10.5.8 and it >>>> worked just fine. >>>> >>>> There are certain differences between 1.3.5 and 'maven' branch (maven >>>> artifacts built from this branch, which is approximately trunk), but >>>> there are no API changes. >>>> >>>> I'm afraid the problem is somehow related to maven dependencies — SVNKit >>>> fails to access OS X Keychain with no JNA binaries at runtime. Could you >>>> check that JNA library is in classpath when you running the code. Debug >>>> log would be helpful here. Find the description how to get it here — >>>> https://wiki.svnkit.com/Troubleshooting. >>>> >>>> There are also internal changes, especially those related to HTTP >>>> authentication mechanisms. If that possible, could you please test >>>> authentication against some svnserve daemon, i.e. using svn:// protocol, >>>> not http://. >>>> >>>> If all above is not relevant for your particular case, let's see what >>>> could be wrong with the code. So, you have login and password stored in >>>> the keychain, right? Please ensure you do — find "<http://svn.api.no:80> >>>> SVN" item and check that access to the item is granted for Java >>>> applications. Otherwise it's not clear for me how do you provide the >>>> credentials for the corresponding realm. >>>> >>>> As I can see, you use the authentication manager which by default don't >>>> have any callback to provide necessary credentials, that means this >>>> authentication manager uses cached version of credentials. That means >>>> 1.3.5 build can read this cached data, but 1.7.0 version is not able to >>>> do that, thus we have a bug. >>>> >>>> Not to bother you with such non-stable builds, you might want to wait >>>> until we merge gradle/maven changes back to trunk and 1.3.x branches. So >>>> you can try pure trunk version or pre-release 1.3.6 build soon. >>>> >>>> Also you may try old-school jar-based way. You can download necessary >>>> jars from our build server — 1.3.x >>>> https://teamcity.svnkit.com/repository/download/bt22/14050:id/deploy/org.tmatesoft.svn_1.3.5.7590.standalone.zip >>>> and trunk >>>> https://teamcity.svnkit.com/repository/download/bt3/14080:id/deploy/org.tmatesoft.svn_1.4.0.7613.standalone.zip. >>>> Log in as a guest if prompted. >>>> >>>> Thank you. >>>> >>>> Semen Vadishev, >>>> TMate Software, >>>> http://svnkit.com/ - Java [Sub]Versioning Library! >>>> http://sqljet.com/ - Java SQLite Library! >>>> >>>> >>>> On 3 May 2011 20:27, lazee wrote: >>>>> This is the way I initialize the client: >>>>> >>>>> clientManager = SVNClientManager.newInstance(); >>>>> SVNRepositoryFactoryImpl.setup(); >>>>> if (log.isDebugEnabled()) { >>>>> SvnDebugLogger.initSvnDebugLogger(); >>>>> } >>>>> DAVRepositoryFactory.setup(); >>>>> FSRepositoryFactory.setup(); >>>>> >>>>> >>>>> >>>>> lazee wrote: >>>>>> Thnx, I have now done some testing on 1.7.0-SNAPSHOT. >>>>>> >>>>>> It seems that the Keychain support on Mac OSX (10.6.7) doesn't work >>>>>> anymore. With SvnKit 1.3.5 I am able to work against a local test >>>>>> repository. With 1.7.0-SNAPSHOT I get this error: >>>>>> >>>>>> SVNException: org.tmatesoft.svn.core.SVNAuthenticationException -> >>>>>> svn: >>>>>> Authentication required for '<http://svn.api.no:80> SVN' >>>>>> org.tmatesoft.svn.core.SVNAuthenticationException: svn: Authentication >>>>>> required for '<http://svn.api.no:80> SVN' >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:47) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:41) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getNextAuthentication(DefaultSVNAuthenticationManager.java:218) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:564) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:280) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:268) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1007) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:179) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:480) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getLocations(SVNBasicDelegate.java:833) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:527) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2716) >>>>>> at >>>>>> org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2627) >>>>>> at >>>>>> org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2202) >>>>>> >>>>>> >>>>>> Any changes in the API that I should be aware of? >>>>>> >>>>>> >>>>>> >>>>>> Semyon Vadishev wrote: >>>>>>> Hi, >>>>>>> >>>>>>>> 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. >>>>>>> Agree. We're currently migrating to gradle, as a build tool, and >>>>>>> Sonatype Nexus, as artifact repository, for all our projects. I think >>>>>>> we >>>>>>> will set up the environment in a week or two, so we will publish >>>>>>> nightly >>>>>>> builds as maven artifacts soon. We will release SVNKit 1.3.6 with >>>>>>> GNOME >>>>>>> Keyring support and some other enhancements a bit later. >>>>>>> >>>>>>> Meanwhile you may try builds from our trunk which are already in >>>>>>> Maven >>>>>>> repository — >>>>>>> http://maven.tmatesoft.com/index.html#nexus-search;quick~svnkit. They >>>>>>> are no stable yet, but they do support GNOME keyring. The description >>>>>>> from my first email of the thread is still valid for these builds. >>>>>>> >>>>>>> If you're going to test authentication cache only, it's much safer to >>>>>>> use remote operations — ls, info, etc. >>>>>>> >>>>>>>> 2. When do you expect 1.4.0 to be released? >>>>>>> Usually we roll out the major release in a month after Subversion >>>>>>> release. According to Subversion roadmap — >>>>>>> http://subversion.apache.org/roadmap.html, there is certain features >>>>>>> development still in progress. So we don't have schedule yet. >>>>>>> >>>>>>> The most important feature of svn 1.7 is a new working copy format >>>>>>> with >>>>>>> central metadata storage. It's based on SQLite database engine and >>>>>>> we've >>>>>>> already implemented basic support for this new storage. That means >>>>>>> that >>>>>>> first builds with full support of working copy operations will appear >>>>>>> in >>>>>>> reasonable time after Subversion release. >>>>>>> >>>>>>> At the same time there are also enhancement in FSFS backend and >>>>>>> HTTP/DAV >>>>>>> repository access. Some of them are backward compatible with the >>>>>>> former >>>>>>> versions. Probably we will roll out these particular improvements in >>>>>>> minor releases after the major one. >>>>>>> >>>>>>> Please notice that the next major version of SVNKit is 1.7.0. We >>>>>>> decided >>>>>>> to have the major version number similar to Subversion one. >>>>>>> >>>>>>> Thank you for your feedback. >>>>>>> >>>>>>> Semen Vadishev, >>>>>>> TMate Software, >>>>>>> http://svnkit.com/ - Java [Sub]Versioning Library! >>>>>>> http://sqljet.com/ - Java SQLite Library! >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 3 May 2011 14:45, lazee wrote: >>>>>>>> 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? >>>>>>> >>>> >>>> >> >> |
|
|
Re: GNOME Keyring support
by lazee
::
Rate this Message:
Ok, I'll implement such a provider and make it work. Thanks for your time and your great product!
/Jakob
|
| Free embeddable forum powered by Nabble | Forum Help |
