You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Alex O'Ree <al...@apache.org> on 2020/05/05 20:03:00 UTC
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
Posted by Michael Osipov <19...@gmx.net>.
> Gesendet: Dienstag, 05. Mai 2020 um 22:03 Uhr
> Von: "Alex O'Ree" <al...@apache.org>
> An: "Maven Users List" <us...@maven.apache.org>
> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Accessing a nexus repository requiring a client certificate
Posted by Alex O'Ree <al...@apache.org>.
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 <al...@apache.org> 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 <ol...@apache.org> 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 <sp...@gmail.com> 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 <ol...@apache.org> 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 <al...@apache.org>
>> 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 <michaelo@apache.org
>> >
>> > > > 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 <
>> michaelo@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 <
>> alexoree@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 <
>> > > michaelo@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 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-unsubscribe@maven.apache.org
>> > > > > >> For additional commands, e-mail: users-help@maven.apache.org
>> > > > > >>
>> > > > > >>
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> ---------------------------------------------------------------------
>> > > > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> > > > > For additional commands, e-mail: users-help@maven.apache.org
>> > > > >
>> > > > >
>> > > >
>> > > --
>> > > Olivier Lamy
>> > > http://twitter.com/olamy | http://linkedin.com/in/olamy
>> > >
>> >
>>
>>
>> --
>> Olivier Lamy
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>
Re: Accessing a nexus repository requiring a client certificate
Posted by Alex O'Ree <al...@apache.org>.
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 <ol...@apache.org> 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 <sp...@gmail.com> 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 <ol...@apache.org> 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 <al...@apache.org>
> 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 <mi...@apache.org>
> > > > 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 <
> michaelo@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 <
> alexoree@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 <
> > > michaelo@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 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-unsubscribe@maven.apache.org
> > > > > >> For additional commands, e-mail: users-help@maven.apache.org
> > > > > >>
> > > > > >>
> > > > > >
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: users-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > > --
> > > Olivier Lamy
> > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > >
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
Re: Accessing a nexus repository requiring a client certificate
Posted by Olivier Lamy <ol...@apache.org>.
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 <sp...@gmail.com> 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 <ol...@apache.org> 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 <al...@apache.org> 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 <mi...@apache.org>
> > > 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 <mi...@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 <al...@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 <
> > michaelo@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 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-unsubscribe@maven.apache.org
> > > > >> For additional commands, e-mail: users-help@maven.apache.org
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: users-help@maven.apache.org
> > > >
> > > >
> > >
> > --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
>
--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Accessing a nexus repository requiring a client certificate
Posted by Alex O'Ree <sp...@gmail.com>.
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 <ol...@apache.org> 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 <al...@apache.org> 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 <mi...@apache.org>
> > 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 <mi...@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 <al...@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 <
> michaelo@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 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-unsubscribe@maven.apache.org
> > > >> For additional commands, e-mail: users-help@maven.apache.org
> > > >>
> > > >>
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
Re: Accessing a nexus repository requiring a client certificate
Posted by Olivier Lamy <ol...@apache.org>.
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 <al...@apache.org> 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 <mi...@apache.org>
> 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 <mi...@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 <al...@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 <mi...@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 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-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: users-help@maven.apache.org
> > >>
> > >>
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Accessing a nexus repository requiring a client certificate
Posted by Alex O'Ree <al...@apache.org>.
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 <mi...@apache.org> 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 <mi...@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 <al...@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 <mi...@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 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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Accessing a nexus repository requiring a client certificate
Posted by Michael Osipov <mi...@apache.org>.
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 <mi...@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 <al...@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 <mi...@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 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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Accessing a nexus repository requiring a client certificate
Posted by Olivier Lamy <ol...@apache.org>.
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 <mi...@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 <al...@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 <mi...@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 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Accessing a nexus repository requiring a client certificate
Posted by Michael Osipov <mi...@apache.org>.
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 <al...@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 <mi...@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 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Accessing a nexus repository requiring a client certificate
Posted by Alex O'Ree <al...@apache.org>.
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 <al...@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 <mi...@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 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
Posted by Alex O'Ree <al...@apache.org>.
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 <mi...@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 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
Posted by Michael Osipov <mi...@apache.org>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org