Hey Tom,
"The intent behind sasl.scram.password.change.enabled was to give the admins
the choice about whether they're willing for passwords to be sent to the
broker in the clear (after all they know their deployment and network
best)."
I can see one advantage which is testing during development
Hi Viktor and Colin,
Thanks for taking a look.
The intent behind sasl.scram.password.change.enabled was to give the admins
the choice about whether they're willing for passwords to be sent to the
broker in the clear (after all they know their deployment and network
best). I'm fine with removing i
On Mon, Oct 21, 2019, at 03:59, Viktor Somogyi-Vass wrote:
> Hey Tom,
>
> Bringing over the conversation from KIP-500 and also adding my
> observations. Let me capture them in points.
>
> 1. Perhaps I'm a bit aggressive in introducing new features but I'm not
> sure if we need sasl.scram.password
Hey Tom,
Bringing over the conversation from KIP-500 and also adding my
observations. Let me capture them in points.
1. Perhaps I'm a bit aggressive in introducing new features but I'm not
sure if we need sasl.scram.password.change.enabled. As I understand it
controls whether your can use the Adm
Hi All,
I've written KIP-506 proposing an RPC and Admin interface for setting SCRAM
user passwords. I think there could be an interesting discussion over the
relative merits of hashing on the broker or client. In any case I'd be
grateful for any comments you may have:
https://cwiki.apache.org/con
