hing out of norm here since ultimately it is using JSSE
>>>> spec
>>>> > for
>>>> > > SSL Connection.
>>>> > >
>>>> > > I will try to respond to code comments in couple of weeks since I
>>>> am
ouple of weeks since I am
>>> out
>>> > > for few weeks. Will keep you guys posted.
>>> > >
>>> > > Thanks
>>> > > Maulin
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>&g
;
>> > clement_pelle...@ibi.com>
>> > > wrote:
>> > >
>> > >> Many of these points came up before.
>> > >>
>> > >> I had great hope when Maulin suggested the custom factory could
>> > >> return an SSLCon
t; return an SSLContext instead of SSLEngine. SSLContext 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.
> > >>
> > >>
SSLContext instead of SSLEngine. SSLContext 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
had with the Mode.
>>
>> 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.
>
e-
> From: Rajini Sivaram [mailto: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
isiva...@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 R
e to provide the
>> SSLContext
>> >>>>> object instead and keep SslFactory more-or-less as it is today with
>> some
>> >>>>> additional responsibility of createEngine() method.
>> >>>>>
>> >>>>> Thanks
>> &g
>>>>>> > configuration/building pluggable and that's it!
> >>>>>> >
> >>>>>> > Thanks
> >>>>>> > Maulin
> >>>>>> >
> >>>>>> >
> >>>&g
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > On Mon, Oct 7, 2019 at 5:47 AM Pellerin, Clement <
>>>>>> clement_pelle...@ibi.com>
>>>>>> > wrote:
>
umbling blocks 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?
>>>>>
>&g
t;>> >>
>>>> >> 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 prov
stom 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]
>>> Se
Context
>> 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
>
sign JCE providers using a certificate
> >> 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
is not signed. Getting the
>> certificate 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 Mess
certificate 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
't require signed JCE
> providers, 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-5
---
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 configuration extensible
In other words, Kafka doesn't necessarily need to derive another
interface/mechanism to make SSLEn
ks. We can always compromise
>> 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: Ma
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/engi
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 configura
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 imp
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 you
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 KeySerializer
ng 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 S
PM
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 kn
19 4:40 PM
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 atte
> 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
im
;> Lets do this in steps. You had a question on getConfiguredInstance().
>> >>
>> >> The method getConfiguredInstance(key, Class) implemented in
>> >> AbstractConfig is how the MetricsReporter and other extension points
>> are
>> >> intantiat
Does 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: R
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
gt;> 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
>>
>> He
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-wr
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 and
lass and call it in both places. That SslEngine
> validation class would not be part of the public API and therefore we don't
> need to fuss about its API.
>
> -Original Message-----
> From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
> Sent: Tuesday, September 17
aulin 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 bo
configurableConfigs() method (there is only the subset in
> > 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
possible to trigger a reconfiguration when none of the 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/
eir extension point
> > >> implementations.
> > >>
> > >> You suggest not to augment ConfigDef with custom configs, so that
> takes
> > >> care of the recursive dependency.
> > >> I just noticed reconfigurableConfigs() returns Set and tha
change its semantics to a URL. Regardless, my point is the custom
> >> 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.
> >>
> >&g
;
> >> On Thu, Sep 12, 2019 at 5:26 PM Pellerin, Clement <
> >> clement_pelle...@ibi.com>
> >> wrote:
> >>
> >> > I'm confused. Can you launch a reconfiguration without a config change
> >> or
> >> > not?
&
replace all SSL configs with a
>> single name.
>>
>> 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
slEngineFactory is to remove
> 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
> > Ss
ot;AlterConfig 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/engi
nfigure should 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 con
sage-
>> 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
>> 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
gt;
>
> -Original Message-
> 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 custo
ight be a better
> approach.
>
> Thanks
> Maulin
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Sep 10, 2019 at 9:06 PM Pellerin, Clement <
> clement_pelle...@ibi.com>
> wrote:
>
> > Regarding what I labe
n it is called. SslEngineFactory
> 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@ka
-Original 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 topi
own SSL configs.
>
> -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 ne
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
ment
Sent: 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 SslEng
ur sample code once 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,
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 a
61 matches
Mail list logo
