[
https://issues.apache.org/jira/browse/LANG-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17873518#comment-17873518
]
Gilles Sadowski commented on LANG-1750:
---------------------------------------
bq. And I also think the change of behavior on RandomStringUtils was a nasty
surprise, that you wouldn't want on a library.
Sorry for that. It was discussed at length in private because the previous
behaviour was flagged as a security issue. And the decision was taken based on
a majority of stating that the change would specifically _not_ entail the
behaviour that hit you. The majority was wrong.
bq. 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......
In the short term that may seem like so, but sharing code has a lot more
advantages than this occasional hiccup.
Rather then rolling your own copies of existing functionality, everyone would
be better off if you to join force with the project's developers (so that your
use-case becomes routinely tested against proposed changes).
> 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)
