Accessing a nexus repository requiring a client certificate
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.
Aw: Accessing a nexus repository requiring a client certificate
> Gesendet: Dienstag, 05. Mai 2020 um 22:03 Uhr > Von: "Alex O'Ree" > An: "Maven Users List" > Betreff: Accessing a nexus repository requiring a client certificate > > 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. No, there is no code in HttpClient Wagon Provider to support that. Technically for HttpClient this is a no-brainer. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Accessing a nexus repository requiring a client certificate
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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Accessing a nexus repository requiring a client certificate
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 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. >
Re: Accessing a nexus repository requiring a client certificate
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 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 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. >> >
Re: Accessing a nexus repository requiring a client certificate
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 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 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Accessing a nexus repository requiring a client certificate
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 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 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 > 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: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Accessing a nexus repository requiring a client certificate
It completely depends how Resolver is created and how/when a Wagon instance is created. If Resolver exists once during a Maven session and hopefully Wagon only once, but I don't know. Another issue with the current code is that the client is never properly shut down. I.e.g, no sockets are freed and the peer has to handle broken connections. M Am 2020-05-17 um 23:42 schrieb Olivier Lamy: 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 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 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 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Accessing a nexus repository requiring a client certificate
Well after a few different experiments with what i've describe above, the issue i'm having setting ensuring that setting.xml parameters get passed into wagon. Currently, it looks like i need to change both maven core, some of the wagon based code and aether wagonTransporter. Hopefully aether maintainers will be open to this On Sun, May 17, 2020 at 5:47 PM Michael Osipov wrote: > It completely depends how Resolver is created and how/when a Wagon > instance is created. If Resolver exists once during a Maven session and > hopefully Wagon only once, but I don't know. Another issue with the > current code is that the client is never properly shut down. I.e.g, no > sockets are freed and the peer has to handle broken connections. > > M > > Am 2020-05-17 um 23:42 schrieb Olivier Lamy: > > 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 > 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 > 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 > >> 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: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Accessing a nexus repository requiring a client certificate
Aether is now maven-resolver project so maintainers will look at your proposal :) On Mon, 18 May 2020 at 10:11 am, Alex O'Ree wrote: > Well after a few different experiments with what i've describe above, the > issue i'm having setting ensuring that setting.xml parameters get passed > into wagon. Currently, it looks like i need to change both maven core, some > of the wagon based code and aether wagonTransporter. Hopefully aether > maintainers will be open to this > > > On Sun, May 17, 2020 at 5:47 PM Michael Osipov > wrote: > > > It completely depends how Resolver is created and how/when a Wagon > > instance is created. If Resolver exists once during a Maven session and > > hopefully Wagon only once, but I don't know. Another issue with the > > current code is that the client is never properly shut down. I.e.g, no > > sockets are freed and the peer has to handle broken connections. > > > > M > > > > Am 2020-05-17 um 23:42 schrieb Olivier Lamy: > > > 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 > > 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 > > 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 > > >> 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: users-unsubscr...@maven.apache.org > > >> For additional commands, e-mail: users-h...@maven.apache.org > > >> > > >> > > > > > > > > > - > > To unsubscribe, e-
Re: Accessing a nexus repository requiring a client certificate
Cool. i'll keep hacking away when i have time. Looks like it'll have to merged in order... wagon resolver maven proper assuming i can get it to work On Sun, May 17, 2020 at 8:15 PM Olivier Lamy wrote: > Aether is now maven-resolver project so maintainers will look at your > proposal :) > > On Mon, 18 May 2020 at 10:11 am, Alex O'Ree wrote: > > > Well after a few different experiments with what i've describe above, the > > issue i'm having setting ensuring that setting.xml parameters get passed > > into wagon. Currently, it looks like i need to change both maven core, > some > > of the wagon based code and aether wagonTransporter. Hopefully aether > > maintainers will be open to this > > > > > > On Sun, May 17, 2020 at 5:47 PM Michael Osipov > > wrote: > > > > > It completely depends how Resolver is created and how/when a Wagon > > > instance is created. If Resolver exists once during a Maven session and > > > hopefully Wagon only once, but I don't know. Another issue with the > > > current code is that the client is never properly shut down. I.e.g, no > > > sockets are freed and the peer has to handle broken connections. > > > > > > M > > > > > > Am 2020-05-17 um 23:42 schrieb Olivier Lamy: > > > > 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 > > > 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 > > > 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 < > micha...@apache.org> > > > >> 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
Re: Accessing a nexus repository requiring a client certificate
You may have to change some APIs Wagon is a very old API (back to when Maven2 was born... yup that's long time ago now :) ) so definitely it could be changed BUT we have to maintain a backward compat as much as we can On Mon, 18 May 2020 at 11:36, Alex O'Ree wrote: > Cool. i'll keep hacking away when i have time. Looks like it'll have to > merged in order... > wagon > resolver > maven proper > > assuming i can get it to work > > > On Sun, May 17, 2020 at 8:15 PM Olivier Lamy wrote: > > > Aether is now maven-resolver project so maintainers will look at your > > proposal :) > > > > On Mon, 18 May 2020 at 10:11 am, Alex O'Ree wrote: > > > > > Well after a few different experiments with what i've describe above, > the > > > issue i'm having setting ensuring that setting.xml parameters get > passed > > > into wagon. Currently, it looks like i need to change both maven core, > > some > > > of the wagon based code and aether wagonTransporter. Hopefully aether > > > maintainers will be open to this > > > > > > > > > On Sun, May 17, 2020 at 5:47 PM Michael Osipov > > > wrote: > > > > > > > It completely depends how Resolver is created and how/when a Wagon > > > > instance is created. If Resolver exists once during a Maven session > and > > > > hopefully Wagon only once, but I don't know. Another issue with the > > > > current code is that the client is never properly shut down. I.e.g, > no > > > > sockets are freed and the peer has to handle broken connections. > > > > > > > > M > > > > > > > > Am 2020-05-17 um 23:42 schrieb Olivier Lamy: > > > > > 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 > > > > 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 > > > > 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 < > > micha...@apache.org> > > > > >> 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 > > > > >>
Re: Accessing a nexus repository requiring a client certificate
roger that. All the changes i've made thus far should be non-breaking. Hopefully. And some good news to report, I had some initial success late last night. Tested on windows using the windows certificate store which is usually the odd ball test case. I'll make some forks and branches and open a PR shortly. I'm not super satisfied with it though. I feel that the code base has probably 3 or 4 too many locations for storing the same information in memory which i'm sure is due to evolutionary reasons. It'll be obvious in the PRs On Sun, May 17, 2020 at 9:59 PM Olivier Lamy wrote: > You may have to change some APIs > Wagon is a very old API (back to when Maven2 was born... yup that's long > time ago now :) ) > so definitely it could be changed BUT we have to maintain a backward compat > as much as we can > > On Mon, 18 May 2020 at 11:36, Alex O'Ree wrote: > > > Cool. i'll keep hacking away when i have time. Looks like it'll have to > > merged in order... > > wagon > > resolver > > maven proper > > > > assuming i can get it to work > > > > > > On Sun, May 17, 2020 at 8:15 PM Olivier Lamy wrote: > > > > > Aether is now maven-resolver project so maintainers will look at your > > > proposal :) > > > > > > On Mon, 18 May 2020 at 10:11 am, Alex O'Ree > wrote: > > > > > > > Well after a few different experiments with what i've describe above, > > the > > > > issue i'm having setting ensuring that setting.xml parameters get > > passed > > > > into wagon. Currently, it looks like i need to change both maven > core, > > > some > > > > of the wagon based code and aether wagonTransporter. Hopefully aether > > > > maintainers will be open to this > > > > > > > > > > > > On Sun, May 17, 2020 at 5:47 PM Michael Osipov > > > > wrote: > > > > > > > > > It completely depends how Resolver is created and how/when a Wagon > > > > > instance is created. If Resolver exists once during a Maven session > > and > > > > > hopefully Wagon only once, but I don't know. Another issue with the > > > > > current code is that the client is never properly shut down. I.e.g, > > no > > > > > sockets are freed and the peer has to handle broken connections. > > > > > > > > > > M > > > > > > > > > > Am 2020-05-17 um 23:42 schrieb Olivier Lamy: > > > > > > 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 < > micha...@apache.org> > > > > > 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 < > alexo...@apache.org> > > > > > 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 < > > > micha...@apache.org> > > > > > >>
Re: Accessing a nexus repository requiring a client certificate
PR's opened, feel free to review or whatever. I'm fully expecting that they won't be merged as is https://github.com/apache/maven-wagon/pull/67 https://github.com/apache/maven-resolver/pull/51 On Mon, May 18, 2020 at 6:18 PM Alex O'Ree wrote: > roger that. All the changes i've made thus far should be non-breaking. > Hopefully. > > And some good news to report, I had some initial success late last night. > Tested on windows using the windows certificate store which is usually the > odd ball test case. I'll make some forks and branches and open a PR > shortly. I'm not super satisfied with it though. I feel that the code base > has probably 3 or 4 too many locations for storing the same information in > memory which i'm sure is due to evolutionary reasons. It'll be obvious in > the PRs > > On Sun, May 17, 2020 at 9:59 PM Olivier Lamy wrote: > >> You may have to change some APIs >> Wagon is a very old API (back to when Maven2 was born... yup that's long >> time ago now :) ) >> so definitely it could be changed BUT we have to maintain a backward >> compat >> as much as we can >> >> On Mon, 18 May 2020 at 11:36, Alex O'Ree wrote: >> >> > Cool. i'll keep hacking away when i have time. Looks like it'll have to >> > merged in order... >> > wagon >> > resolver >> > maven proper >> > >> > assuming i can get it to work >> > >> > >> > On Sun, May 17, 2020 at 8:15 PM Olivier Lamy wrote: >> > >> > > Aether is now maven-resolver project so maintainers will look at your >> > > proposal :) >> > > >> > > On Mon, 18 May 2020 at 10:11 am, Alex O'Ree >> wrote: >> > > >> > > > Well after a few different experiments with what i've describe >> above, >> > the >> > > > issue i'm having setting ensuring that setting.xml parameters get >> > passed >> > > > into wagon. Currently, it looks like i need to change both maven >> core, >> > > some >> > > > of the wagon based code and aether wagonTransporter. Hopefully >> aether >> > > > maintainers will be open to this >> > > > >> > > > >> > > > On Sun, May 17, 2020 at 5:47 PM Michael Osipov > > >> > > > wrote: >> > > > >> > > > > It completely depends how Resolver is created and how/when a Wagon >> > > > > instance is created. If Resolver exists once during a Maven >> session >> > and >> > > > > hopefully Wagon only once, but I don't know. Another issue with >> the >> > > > > current code is that the client is never properly shut down. >> I.e.g, >> > no >> > > > > sockets are freed and the peer has to handle broken connections. >> > > > > >> > > > > M >> > > > > >> > > > > Am 2020-05-17 um 23:42 schrieb Olivier Lamy: >> > > > > > 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 < >> micha...@apache.org> >> > > > > 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 < >> alexo...@apache.org> >> > > > > 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 >> >