|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?