|Re: [jgit-dev] Setting jgit SSL Key/Trust Store on a Per-Connection Basis|
We are looking to make https client connections with the jgit libraries. The only method I have found so far with the stock jgit libraries to set the key and trust stores to be used for SSL is via setting the jvm process global “javax.net.ssl” system properties — keyStore, keyStorePassword, trustStore, trustStorePassword. While this works fine, it does not allow us to meet our particular use case.
At any given time, we may have multiple “applications” running within the same jvm process where each of those applications could have different needs with respect to the SSL key store and trust store that they use. We would like to avoid having to implement a thread synchronization mechanism amongst these applications such that the “javax.net.ssl” properties could be set for the duration of a connection.
One potential workaround that we have seen is that we can create a custom jgit TransportProtocol and associated Transport and call into Transport.register() at application startup in order to have it be used for http/https connections. With this, we can implement custom SSL behaviors that are held local to those class instances without affecting the global jvm SSL state. With this approach, we would ideally like to create a Transport class which derives from org.eclipse.jgit.transport.TransportHttp but which would live in our own namespace — so as not to co-opt the Eclipse namespace. Unfortunately, we aren’t able to do this either, though, in that a number of the classes and methods in the org.eclipse.jgit.transport namespace are package-private, including the TransportHttp constructors and other classes that the TransportHttp implementation uses like HttpAuthMethod.
Is there a better approach available that might meet our needs? If the custom Transport implementation would be the best option, would the Eclipse community be open to making more of the functionality in the org.eclipse.jgit.transport namespace public so that it would be accessible to implementations outside of this namespace to use?
Back to the top