[
https://issues.apache.org/jira/browse/LANG-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17873501#comment-17873501
]
Marco Hoek commented on LANG-1750:
----------------------------------
[~erans]
Thanks for the suggestion, I will certainly have a look at that option and then
decide how to rewrite. And I also think the change of behavior on
RandomStringUtils was a nasty surprise, that you wouldn't want on a library.
That does mean, that for my intended purpose, I might end up writing my own
routine altogether, because I feel all this added complexity on using these
libraries for my purpose is getting more of a burden, than that is helping
me......
> Using RandomStringUtils.insecure() still leads to using the secure() random
> ---------------------------------------------------------------------------
>
> Key: LANG-1750
> URL: https://issues.apache.org/jira/browse/LANG-1750
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
> Affects Versions: 3.16.0
> Reporter: Marco Hoek
> Assignee: Gary D. Gregory
> Priority: Major
> Fix For: 3.17.0
>
>
> In RandomStringUtils v3.16, the use of secure() vs insecure() is used to be
> able to choose which random generator to use. However, consider the following
> code path:
>
> a) RandomStringUtils.insecure().nextAlphanumeric(length)
> leads to the instance method 'nextAlphanumeric, which in turn calls:
> b) static method RandomStringUtils.random(count, true, true)
> which in turn calls
> c) static method RandomStringUtils.secure().next(count, letters, numbers)
>
> Conclusion: where I want to use the "insecure" option path, I end up having
> the call forwarded to the "secure" random provider anyway. Where I then run
> into the problem of having too low entropy and experiencing terrible
> performance.... (see LANG-1748)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
