JSSE
>>>> spec
>>>> > for
>>>> > > SSL Connection.
>>>> > >
>>>> > > I will try to respond to code comments in couple of weeks since I
>>>> am out
>>>> > > for few weeks. Will
;> > > for few weeks. Will keep you guys posted.
>>> > >
>>> > > Thanks
>>> > > Maulin
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>&g
gt; > > wrote:
>> > >
>> > >> Many of these points came up before.
>> > >>
>> > >> I had great hope when Maulin suggested the custom factory could
>> > >> return an SSLContext instead of SSLEngine. SSLContext factories a
Context factories are
> > >> common,
> > >> whereas I have never seen an SSLEngine factory being used before.
> > >> He must have hit the same problem I had with the Mode.
> > >>
> > >> If the Mode can be removed, can we find a way to r
factories are
> >> common,
> >> whereas I have never seen an SSLEngine factory being used before.
> >> He must have hit the same problem I had with the Mode.
> >>
> >> If the Mode can be removed, can we find a way to return an SSLContext
> now?
>
; If the Mode can be removed, can we find a way to return an SSLContext now?
>> What is so special about Kafka that it needs to hardcode the Mode when
>> everyone
>> else works with the SSLContext and ignores the other mode they don't use.
>>
>> -Original Message-
>>
:rajinisiva...@gmail.com]
> Sent: Wednesday, February 5, 2020 10:03 AM
> To: dev
> Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration
> extensible
>
> One more point:
> 5) We should also add a method to SslEngineFactory that returns
> `Set
> reconfigura
...@gmail.com]
Sent: Wednesday, February 5, 2020 10:03 AM
To: dev
Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration extensible
One more point:
5) We should also add a method to SslEngineFactory that returns `Set
reconfigurableConfigs()`
On Wed, Feb 5, 2020 at 1:50 PM Rajini
;> SSLContext
>> >>>>> object instead and keep SslFactory more-or-less as it is today with
>> some
>> >>>>> additional responsibility of createEngine() method.
>> >>>>>
>> >>>>> Thanks
>> >>>>> M
ion/building pluggable and that's it!
> >>>>>> >
> >>>>>> > Thanks
> >>>>>> > Maulin
> >>>>>> >
> >>>>>> >
> >>>>>> >
> >>>>>>
gt;>>> >
>>>>>> >
>>>>>> >
>>>>>> > On Mon, Oct 7, 2019 at 5:47 AM Pellerin, Clement <
>>>>>> clement_pelle...@ibi.com>
>>>>>> > wrote:
>>>>>> >
>>>&
we have are:
>>>>> 1) reuse of the validation code in the existing SslFactory
>>>>> 2) the client/server mode on the SSLEngine
>>>>>
>>>>> How do you deal with those issues in your new proposal?
>>>>>
>>>>>
Changing the order of the JCE providers in the java.security file
>>>> affects
>>>> >> all java applications so you probably don't want to do it there.
>>>> Changing
>>>> >> the order of the JCE providers in the JVM instance affects all code
>>
SslFactory that returns an
>>> SSLContext previously created elsewhere in the application. Can your new
>>> proposal handle this use case?
>>>
>>> -Original Message-
>>> From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
>>> Sent: F
xt
>> previously created elsewhere in the application. Can your new proposal
>> handle this use case?
>>
>> -----Original Message-
>> From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
>> Sent: Friday, October 11, 2019 2:13 AM
>> To: dev@kafka.apache.org
>>
>> signed by Oracle's JCE Code Signing Certification Authority.
> >>
> >>
> https://www.oracle.com/technetwork/java/javase/tech/getcodesigningcertificate-361306.html
> >> JCE will refuse to load your provider if it is not signed. Getting the
> >> certificate
te is a pain and it takes time. You also have to worry about the
>> certificate expiration date. There are JVMs that don't require signed JCE
>> providers, but you cannot limit Kafka to just those JVMs.
>>
>> -Original Message-
>> From: Maulin Vasavada [mailto
also have to worry about the
>> certificate expiration date. There are JVMs that don't require signed JCE
>> providers, but you cannot limit Kafka to just those JVMs.
>>
>> -Original Message-
>> From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
>&
s, but you cannot limit Kafka to just those JVMs.
>
> -Original Message-
> From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
> Sent: Friday, October 4, 2019 5:31 PM
> To: dev@kafka.apache.org
> Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuratio
[mailto:maulin.vasav...@gmail.com]
Sent: Friday, October 4, 2019 5:31 PM
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration extensible
In other words, Kafka doesn't necessarily need to derive another
interface/mechanism to make SSLEngine pluggable. That interface
ise
>> on the reusability of the reconfiguration checks. On the other hand, we
>> really have to learn more about the client/server mode customization
>> because that's unavoidable at the moment.
>>
>> -Original Message-
>> From: Maulin Vasavada [mailto:maulin.v
tion
> because that's unavoidable at the moment.
>
> -Original Message-
> From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
> Sent: Friday, October 4, 2019 4:13 AM
> To: dev@kafka.apache.org
> Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configur
t the client/server mode customization because that's
unavoidable at the moment.
-Original Message-
From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
Sent: Friday, October 4, 2019 4:13 AM
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration
Hi all
I've been having more thoughts on SSLEngine vs SSLContext pluggability
(reasons for hiatus from my side until now). Based on my further research
and understanding, various TLS implementations
https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations , makes it
clear that there are
Ack. I should be able to get back to this on Friday.
On Mon, Sep 23, 2019 at 10:35 AM Pellerin, Clement
wrote:
> When I worked on KIP-383 I was told the way to pass extra arguments to an
> instance is to add extra arguments to configure. I would now suggest we do
> like the KeySerializer. If
When I worked on KIP-383 I was told the way to pass extra arguments to an
instance is to add extra arguments to configure. I would now suggest we do like
the KeySerializer. If you look in KafkaProducer, it creates a KeySerializer
using AbstractConfig. getConfiguredInstance(). Since
ning what you were saying?
> Do we make the checks mandatory or not?
> Do we support all the use cases we want?
>
> -Original Message-
> From: Pellerin, Clement
> Sent: Friday, September 20, 2019 5:24 PM
> To: dev@kafka.apache.org
> Subject: RE: [DISCUSS] KIP-519: Make SSL co
To: dev@kafka.apache.org
Subject: RE: [DISCUSS] KIP-519: Make SSL context/engine configuration extensible
The KIP now says: We believe that making SSLEngine creation pluggable is worth
to allow SSL experts to write their own implementation having the SSL domain
knowledge and keep them free of knowing
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration extensible
Thanks Clement for your thoughts. According to my current experience
rewriting the code twice I would say I did what you suggest in the last
point - " We must make an attempt, if
From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
> Sent: Friday, September 20, 2019 2:40 AM
> To: dev@kafka.apache.org
> Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration
> extensible
>
> Overall my thinking is - When somebody wants to customize creation of
>
: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration extensible
Overall my thinking is - When somebody wants to customize creation of
SSLEngine, most likely they are more expert in dealing with SSL domain
related stuff than "Kafka's reconfigurability" aspect. As a custom
impl
. You had a question on getConfiguredInstance().
>> >>
>> >> The method getConfiguredInstance(key, Class) implemented in
>> >> AbstractConfig is how the MetricsReporter and other extension points
>> are
>> >> intantiated. Creating the extension poi
this proposal address all the reasons you had not to do exactly what
> other extension points are doing?
>
> -Original Message-
> From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
> Sent: Thursday, September 19, 2019 10:21 PM
> To: dev@kafka.apache.org
> Subject: Re: [D
not to do exactly what other
extension points are doing?
-Original Message-
From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
Sent: Thursday, September 19, 2019 10:21 PM
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration extensible
Hi C
om: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
>> Sent: Wednesday, September 18, 2019 4:37 PM
>> To: dev@kafka.apache.org
>> Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration
>> extensible
>>
>> Hi Clement
>>
>> Here are
in Vasavada [mailto:maulin.vasav...@gmail.com]
> Sent: Wednesday, September 18, 2019 4:37 PM
> To: dev@kafka.apache.org
> Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration
> extensible
>
> Hi Clement
>
> Here are my thoughts based on my latest re-writ
Message-
From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
Sent: Wednesday, September 18, 2019 4:37 PM
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration extensible
Hi Clement
Here are my thoughts based on my latest re-write attempt
gt; need to fuss about its API.
>
> -Original Message-
> From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
> Sent: Tuesday, September 17, 2019 2:28 AM
> To: dev@kafka.apache.org
> Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration
> extensible
Vasavada [mailto:maulin.vasav...@gmail.com]
Sent: Tuesday, September 17, 2019 2:28 AM
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration extensible
Hi Clement/Rajini
When I read your responses - I swing between both of your suggestions :) I
see both
gt; reconfigurableConfigs()). Non-validated configs might be of the wrong
> type,
> > be out of range, or missing since the default value is not applied. This
> is
> > a burden to the extension point developer and Kafka should provide
> > utilities for this.
> >
> > Can you
known configs have
> changed.
>
>
> -----Original Message-----
> From: Rajini Sivaram [mailto:rajinisiva...@gmail.com]
> Sent: Monday, September 16, 2019 5:29 AM
> To: dev
> Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration
> extensible
>
> Hi Ma
ou suggest not to augment ConfigDef with custom configs, so that
> takes
> > >> care of the recursive dependency.
> > >> I just noticed reconfigurableConfigs() returns Set and that
> does
> > >> not force the creation of a ConfigKey for custom configs.
>
implementation should decide all the reconfigurable properties. By the
> way,
> >> my original use case for KIP-383 was to replace all SSL configs with a
> >> single name.
> >>
> >> It is still not clear in your email if the keystore/truststore exception
>
> clement_pelle...@ibi.com>
> >> wrote:
> >>
> >> > I'm confused. Can you launch a reconfiguration without a config change
> >> or
> >> > not?
> >> >
> >> > If I understand the test case correctly, the des
t;> It is still not clear in your email if the keystore/truststore exception
>> is handled locally in SslFactory or by the initiator of the whole
>> AlterConfig. That determines whether "AlterConfig without config changes"
>> always goes through or is usually
ove
> the
> > need to specify the keystore and truststore locations. The special
> handling
> > to detect changes in keystore/truststore should be pushed to
> > DefaultSslEngineFactory and all calls to reconfigure should reach the
> > SslEngineFactory instan
terConfig without config changes" always goes
through or is usually blocked early by the initiator.
-Original Message-
From: Rajini Sivaram [mailto:rajinisiva...@gmail.com]
Sent: Thursday, September 12, 2019 2:05 PM
To: dev
Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine co
reach the
> SslEngineFactory instance. Am I missing something?
>
> -Original Message-
> From: Rajini Sivaram [mailto:rajinisiva...@gmail.com]
> Sent: Thursday, September 12, 2019 12:01 PM
> To: dev
> Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration
>
>> From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
>> Sent: Thursday, September 12, 2019 2:24 AM
>> To: dev@kafka.apache.org
>> Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration
>> extensible
>>
>> Thanks Clement and Rajin
>> From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
>> Sent: Thursday, September 12, 2019 2:24 AM
>> To: dev@kafka.apache.org
>> Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration
>> extensible
>>
>> Thanks Clement and Rajin
describes that design pattern.
>
> -Original Message-
> From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
> Sent: Thursday, September 12, 2019 2:24 AM
> To: dev@kafka.apache.org
> Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration
> extensible
>
.
-Original Message-
From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
Sent: Thursday, September 12, 2019 2:24 AM
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration extensible
Thanks Clement and Rajini. Let me digest what both of you said. Clearly I
> From: Rajini Sivaram [mailto:rajinisiva...@gmail.com]
> Sent: Wednesday, September 11, 2019 4:25 PM
> To: dev
> Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration
> extensible
>
> Kafka already has the notion of custom configs. And we support
> reconfigu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Sep 10, 2019 at 9:06 PM Pellerin, Clement <
> clement_pelle...@ibi.com>
> wrote:
>
> > Regarding what I labeled the simplest solution below, SslConfigs could
> >
Factory
> would no longer be immutable, so maybe it is worth reconsidering how
> reconfigure works for it.
>
> -Original Message-
> From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
> Sent: Wednesday, September 11, 2019 3:29 AM
> To: dev@kafka.apache.org
> Subje
Message-
From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
Sent: Wednesday, September 11, 2019 3:29 AM
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration extensible
Hi all,
Since the "custom config" seems the main topic of interest l
--Original Message-
> From: Pellerin, Clement
> Sent: Tuesday, September 10, 2019 11:36 AM
> To: dev@kafka.apache.org
> Subject: [EXTERNAL]RE: [DISCUSS] KIP-519: Make SSL context/engine
> configuration extensible
>
> Another solution could be a new standard ssl config that hol
11:36 AM
To: dev@kafka.apache.org
Subject: [EXTERNAL]RE: [DISCUSS] KIP-519: Make SSL context/engine configuration
extensible
Another solution could be a new standard ssl config that holds a list of extra
custom configs to accept.
Using a custom SslEngineFactory with custom configs would require
: Tuesday, September 10, 2019 9:35 AM
To: dev@kafka.apache.org
Subject: [EXTERNAL]RE: [DISCUSS] KIP-519: Make SSL context/engine configuration
extensible
Custom config is a term I invented to mean a config that does not exist in
Kafka but is specified by a custom implementation of SslEngineFactory
to say it exists.
When I wrote KIP-383, I felt I needed a prototype before I could solidify the
proposal.
That's part of the reason why there was never a third iteration.
-Original Message-
From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
Sent: Tuesday, September 10, 2019 2:26
Hi Clement/Rajini/Colin
Please review our latest updates on the KIP and let me know your thoughts.
Clement, please let me know if my understanding about the "custom configs"
is correct based on what I wrote in the KIP.
Thanks
Maulin
On Mon, Sep 9, 2019 at 3:28 PM Maulin Vasavada
wrote:
> Hi
61 matches
Mail list logo
