Oh Yes I agree the current API would need major (breaking?) changes. But openConnectionInternal creating client would not reuse http connection (or you have another idea?) It was a bit of hackish to have http connection pooling due to current design but especially with https it saves some IO.
On Mon, 18 May 2020 at 01:53, Michael Osipov <[email protected]> wrote: > Alex, I will get back to you in a couple of days because it is a lot of > work. But already agree, the current approach in Wagon makes it > impossible to hook in TLS mutual auth and #openConnectionInternal() must > create the client upon call. > > M > > Am 2020-05-17 um 17:31 schrieb Alex O'Ree: > > Pinging you back again on this. Adding support for this (i think) it > going > > to require some significant changes to the abstract http client wagon > > class. Client certificate authentication, on a per endpoint basis,would > > require separate ssl socket factories, which is constructed before the > > pooling http client connection manager. Having everything static makes > this > > difficult to implement without potentially breaking any other plugin that > > uses this class programmatically. Would perhaps changing > > 'openConnectionInternal' be a better option for hooking this? I.e. if we > > have a user defined key/trust setup, make a new configuration within this > > method, otherwise fallback to the default static pool? > > > > > > > > > > On Mon, May 11, 2020 at 7:10 PM Alex O'Ree <[email protected]> wrote: > > > >> I did some work on this over the weekend. Maintaining backwards > >> compatibility is going to be challenging due to the http connection pool > >> being static. Since the http client now needs to be specific to a > >> repository or destination, i'm not sure if that configuration will still > >> work. Anyhow, i ended up down a rat role of trying to understand why > some > >> of the unit tests were failing and making it worse in the process. > >> > >> On Wed, May 6, 2020 at 6:38 AM Michael Osipov <[email protected]> > wrote: > >> > >>> Am 2020-05-05 um 22:03 schrieb Alex O'Ree: > >>>> I was looking over the docs for the settings.xml file and noted that > it > >>>> looks like it's possible to access a nexus repository using a client > >>>> certificate of sorts. It's not clear the docs if a JKS can be used or > >>> if it > >>>> must be a ssh private key or what. > >>>> > >>>> http://maven.apache.org/settings.html#servers > >>>> > >>>> I wanted to confirm that the linked docs is still accurate? I have a > few > >>>> different use cases and may need to reference a client cert key pair > in > >>> a > >>>> JKS or perhaps from the windows certificate store for authentication > to > >>> the > >>>> nexus repository. Is still a supported configuration by maven? I found > >>> some > >>>> references to support here: > >>> https://issues.apache.org/jira/browse/MNG-1560 > >>>> which references setting maven options for javax.net.ssl.* settings. > >>>> Considering the environment, i'll probably need to be able to specify > >>> the > >>>> key alias name too, just in case there's multiple certificates > >>> available. > >>>> > >>> > >>> MNG-5583. I have intentionally closed this one since no was willing to > >>> work on it. If someone wants to work on it, I'd be happy to discuss. > >>> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
