[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [jgit-dev] Setting jgit SSL Key/Trust Store on a Per-Connection Basis
I think that my change https://git.eclipse.org/r/#/c/15123/ could help
you. It introduces an abstraction for network connections used during
http(s) transports and introduces factories which can be registered to
produce this connections. By implementing an own factory (may as
subclass of JDKHttpConnectionFactory.java) one can manipulate the each
connection before it is given to JGit. This change is currently in
review and I can't say when it get's included.
My original motivation to do this was to enable JGit to run in
environments where we have to use connections which have an
org.apache.http.client.HttpClient interface. E.g. if JGit runs in a
cloud environment where you get http connections through a
cloud-specific API returning org.apache.http.client.HttpClient
instances. This feature is in https://git.eclipse.org/r/#/c/15124.
Instead of introducing ConnectionFactories we could also support the
git config params which deal with https authentication with
certificates. There are very old open changes of mine in
https://git.eclipse.org/r/#/c/3200. But I am not sure whether
keystores configured per repo are helping you. You tell about multiple
applications having different needs regarding keystores. Do these
applications work on shared repos or does every application has it's
own set of repos?
On Mon, Feb 10, 2014 at 11:15 PM, Jeremy Barlow
> 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:
>> 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
>> 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
> an abstraction for creating HTTP connections and a new implementation based
> Apache httpclient as an alternative to the existing builtin code.
> Please provide feedback if this would also cover your needs.
> jgit-dev mailing list