[
https://issues.apache.org/jira/browse/CASSANDRA-9384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17419739#comment-17419739
]
Stefan Miklosovic edited comment on CASSANDRA-9384 at 9/24/21, 12:37 PM:
-------------------------------------------------------------------------
I came to the very same conclusions in 16990 and I havent checked this already
exists so I closed it as duplication.
While I was testing this, with 31 and I created a user, after I bumped it to
0.4, I could not even create a user anymore. If you currently set it to 31,
there is a bug right ... and exactly because of that it will generate a
password upon the user creation almost instantly because there is this
overflow. But if we fix this or if a user tries the previous number - 30, it
will not overflow, but the change from 31 to 30 causes it to time-out - because
it takes so much time to salt it so many times that the CQL command itself will
time out.
Same holds for whatever higher number, like 20, for example. It still hangs on
my notebook (fairly modern one). Even it fails, that user WILL appear in the
system_auth.roles table after like ... 2-3 minutes, depends how fast your pc
is. So the query fails on timeout but the user creation succeeds eventually in
the background. So I am wondering who is this feature actually good for if it
become a "trial and error" until you hit the sweet spot when salting does not
take eternity and you will fit in cql timeout limit.
In general, I do agree with what [~djoshi] and [~jjirsa] proposed - upgrade the
lib for trunk and fail on 31 and dont upgrade on whatever else (3.0.x, 3.11.x,
4.0.x) but fail it unless there is the special property to make it unsafe.
The fact this property is not documented anywhere is a bummer, I would add it
to cassandra-env.sh at the bottom and commeted it out (both with
allow_unsafe_bcrypt).
If this is what we agree on, [~djoshi], in case you do not have time to do
this, are you ok if I take over?
was (Author: stefan.miklosovic):
I came to the very same conclusions in 16990 and I havent checked this already
exists so I closed it as duplication.
While I was testing this, with 31 and I created a user, after I bumped it to
0.4, I could not even create a user anymore. If you currently set it to 31,
there is a bug right ... and exactly because of that it will generate a
password upon the user creation almost instantly because there is this
overflow. But if we fix this or if a user tries the previous number - 30, it
will not overflow, but the change from 31 to 30 causes it to time-out - because
it takes so much time to salt it so many times that the CQL command itself will
time out.
Same holds for whatever higher number, like 20, for example. It still hangs on
my notebook (fairly modern one). Even it fails, that user WILL appear in the
system_auth.roles table after like ... 2-3 minutes, depends how fast your pc
is. So the query fails on timeout but the user creation succeeds eventually in
the background. So I am wondering who is this feature actually good for if it
become a "trial and error" until you hit the sweet spot when salting does not
take eternity and you will fit in cql timeout limit.
> Update jBCrypt dependency to version 0.4
> ----------------------------------------
>
> Key: CASSANDRA-9384
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9384
> Project: Cassandra
> Issue Type: Bug
> Reporter: Sam Tunnicliffe
> Assignee: Dinesh Joshi
> Priority: Normal
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://bugzilla.mindrot.org/show_bug.cgi?id=2097
> Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4
> indicate that this is now fixed, so we should update.
> Thanks to [~Bereng] for identifying the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
