I have verified that the CryptoRandom class is part of a standalone library with (1) should be thread-safe since it cannot dictate how it will be used by callers; (2) the authors clearly intended this library to be thread-safe (based on "thread-safe" comments in its source code).
And in all likelihood it is thread-safe - but that's due to being lucky - not competent.
The larger issue is that we have a widely-used crypto software which is clearly (1) not designed well; (2) not implemented well.
How much trust one is willing to place into current and future versions by the same author(s) is up to you.
Well, "(1) should be thread-safe since it cannot dictate how it will be used by callers" doesn't hold. For instance most of .NET classes are not thread-safe because thread-safety has a cost. So it's a question of documentation (it's well documented in .NET).
But "(2) the authors clearly intended this library to be thread-safe" means that piece of code is bad. So you have a point here.
To be a little more specific, the class itself is not marked as thread-safe. Only the AddEntropy() and GetRandomBytes() methods are so marked. So it would technically be permissible for any other part of the class to not be thread-safe.
But since it's a singleton, having a non-thread-safe initializer is cutting that distinction a little fine.
Given the discussion expressed in this chain and the fact that this is a reasonably small open source project. How many times could a solution have been submitted to the project for this and other noticed issues in the time it was discussed?
I'm sure the author would be very happy to see a sudden influx of contributions to the project, and we'd all have a better product in the end too.
Seems odd the spirit of open source in this respect tends to be more about pointing out the failures of the author than to collectively improve the actual product.
That's a fair point. If this was on Github I might take that to heart and submit a PR. Since it's hosted on Sourceforge, which I don't have an account on and don't want to given their recent behavior, I'm not going to.
And in all likelihood it is thread-safe - but that's due to being lucky - not competent.
The larger issue is that we have a widely-used crypto software which is clearly (1) not designed well; (2) not implemented well.
How much trust one is willing to place into current and future versions by the same author(s) is up to you.