Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] Setting jgit SSL Key/Trust Store on a Per-Connection Basis

Hi Matthias,

Thank you for the quick reply and insight.  Yes, the changes that Chris is working on look like they would be a great fit for our use case.  Do you have an idea as to when these might be available in a released build (i.e., on Maven Central)?

Thanks again!

— Jeremy

On Feb 10, 2014, at 1:13 PM, Matthias Sohn <matthias.sohn@xxxxxxxxx> wrote:

On Mon, Feb 10, 2014 at 6:47 PM, Jeremy Barlow <jeremy.barlow@xxxxxxxxxxxxxx> wrote:
Hello.

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?

Have a look at the following changes Chris is working on which are introducing
an abstraction for creating HTTP connections and a new implementation based on
Apache httpclient as an alternative to the existing builtin code.

Please provide feedback if this would also cover your needs.


--
Matthias


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


Back to the top