The third version is now out (minus test cases), and is ready in the
webrev.03 directory.
http://cr.openjdk.java.net/~wetmore/6425477/
The only change is the API as we discussed.
Brad
On 1/9/2013 7:21 PM, Brad Wetmore wrote:
Thanks for the feedback. I also received some privately which had
similar comments.
Wrapping up several emails into some bullet points:
1. I like Sean's suggested tweak to the API. I'm thinking of adjusting
it slightly.
2. Xuelei has a point about my fallback of "most preferred"
implementation may not actually be strong. And like Max, I've also had
concerns about "which provider".
In my previous proposal laundry list for SecureRandom, I had something
like:
securerandom.strongAlgorithms=algname1,algname2.provname1,algname3
which addresses both issues. The property will contain a list of algs
or algs/providers, and we'll iterate through them. If we can't create
an instance of one of these, return a null.
public static SecureRandom getStrongSecureRandom()
Given these comments, I think I'm going to move forward on this. The
application will do:
SecureRandom sr = SecureRandom.getStrongSecureRandom();
if (sr == null) {
// Decide if this is a problem, and whether to recover.
// sr = new SecureRandom(); or return;
}
3. Sean wrote:
> There's an assumption that the securerandom.strongAlgorithm has been
> configured appropriately.
Exactly, we'll ship with default values for each platform, and
programs/deployers can add/subtract as needed.
4. Xuelei wrote:
> The 2nd one is to define a SPI method (pros: the
> admin won't need to set the property. The admin does not always know
> what kind of providers will be used at runtime).
If I'm reading this comment right, given the pros of the current
approach, I hesitate letting implementations make comparative strength
decisions.
Thanks! I should have a new version out tonight.
Brad
