Thank you for your input, Jun, Colina and Rajini! It seems not that quick
responding either :)
I would like to maintain that the SSL trust store is conceptually different
from the other pieces
of configuration that is mentioned such as key stores and GSSAPI keytabs. The
trust store is
not secr
Hi Noa,
My understanding was the KIP-398 is proposing to look up only SSL
truststores from CLASSPATH, not files that contain actual credentials like
SSL keystores. In production scenarios, lots of users tend to use
certificates signed by trusted CAs, so you don't actually need to configure
a trust
Hi Noa,
I think Jun makes a good point that this would be better as a generic
mechanism, not specific to SSL. With KIP-421: Support resolving externalized
secrets in AbstractConfig, we should be able to do something like that. We
could have a ClasspathConfigProvider. Then this could be used
Hi, Noa,
Thanks for the KIP and sorry for the late response.
The KIP itself looks reasonable. My only concern is that it's very specific
to SSL. We have other configurations that also depend on files (e.g. keytab
in Sasl GSSAPI). It would be inconsistent that we only support the
CLASSPATH: syntax
I believe that I have addressed the concerns raised in this discussion. It
seems reasonable to start a vote in about two days. Please raise any concerns
you may have and I will be happy to attempt to address them.
/noa
> On 10 Dec 2018, at 10:53, Noa Resare wrote:
>
> Thank you for your comme
Thank you for your comments, see replies inline.
> On 9 Dec 2018, at 01:33, Harsha wrote:
>
> Hi Noa,
> Based on KIP"s motivation section
> "If we had the ability to load a trust store from the classpath as well as
> from a file, the trust store could be shipped in a jar that could be
Hi Noa,
Based on KIP"s motivation section
"If we had the ability to load a trust store from the classpath as well as from
a file, the trust store could be shipped in a jar that could be declared as a
dependency and piggyback on the distribution infrastructure already in place."
It loo
> On 6 Dec 2018, at 20:16, Rajini Sivaram wrote:
>
> Hi Noa,
>
> Thanks for the KIP. A few comments/questions:
>
> 1. If we support filenames starting with `classpath:` by requiring
> `file:`prefix,
> then we are presumably not supporting files starting `file:`. Not
> necessarily an issue, b
Hi Noa,
Thanks for the KIP. A few comments/questions:
1. If we support filenames starting with `classpath:` by requiring
`file:`prefix,
then we are presumably not supporting files starting `file:`. Not
necessarily an issue, but we do need to document any restrictions.
2. On the broker-side, trust
Hi Neo,
thanks for the KIP, the proposal sounds useful!
Also I agree on both assumptions that you made:
- users whose current truststore location starts with classpath: should be
very few and extremely far between (and arguably made questionable choices
when naming their files/directories), I per
10 matches
Mail list logo
