[
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, 11:53 AM:
-------------------------------------------------------------------------
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, depend 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 eterniny and you will fit in cql timeout limit.
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. 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, depend 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 eterniny 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]
