Re: [jgit-dev] Setting jgit SSL Key/Trust Store on a Per-Connection Basi

[Jeremy Barlow <jeremy.barlow@xxxxxxxxxxxxxx>]

Hi Chris,

Thank you for this follow-up information.

I think that for the use cases we are aware of for the near term, the changes you have proposed around the introduction of a new HttpConnectionFactory (15123 and 15124) would provide the basic extensibility that we need.  We know that we'll have different applications running within the same JVM process that need to use SSL and may require different certificate management configurations.

We don't know yet how many of these applications might need to use jgit, though, and, for any cases where more than one might be present, whether they would always be operating on separate repos and/or would need to use different certificate management configurations.

The ability to configure the SSL parameters differently per the repository configuration (3199 and 3200) is definitely intriguing.  I could see where this could offer us more flexibility.

I think the ideal functionality for us would be to have the ability for the direct client performing the operations against the repository (e.g., a fetch or push) to be the one which sets the SSL configuration parameters it would like to have used and not have those parameters affect any other client.  In conjunction with your changes for (3199 and 3200), I could see where something close to this could be achieved with the approach of having the client configuring the parameters through the FileBasedConfig object obtained from the Repository, although I'm not sure if the changes made to that in memory copy of the FileBasedConfig might be written back to disk and unintentionally picked up by another client using the same repository.

In any event, I think both of the sets of changes you are proposing would be very valuable and am open to any additional feedback you may have for us on our use cases.

Thanks again!

--- Jeremy

On Wed, Feb 12, 2014 at 3:49 AM, Christian Halstrick <christian.halstrick@xxxxxxxxx> wrote:

Hi Jeremy,

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/3199 and
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?

Ciao
  Chris
Ciao
  Chris

On Mon, Feb 10, 2014 at 11:15 PM, Jeremy Barlow
<jeremy.barlow@xxxxxxxxxxxxxx> wrote:
> 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.
>
> https://git.eclipse.org/r/#/c/15123/
> https://git.eclipse.org/r/#/c/15124/
>
> --
> Matthias
>
>
>

> _______________________________________________
> jgit-dev mailing list
> jgit-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jgit-dev
>