OK, go ahead!
Thanks,
Xuelei
On 5/9/2016 7:08 AM, Wang Weijun wrote:
>
>> On May 8, 2016, at 10:26 PM, Xuelei Fan wrote:
>>
>> On 5/8/2016 9:06 PM, Wang Weijun wrote:
>>> Ping again.
>>>
On May 3, 2016, at 10:26 AM, Wang Weijun wrote:
Hi All
Please take a review at
>>>
I would say that there are certain member-objects of SecureRandom that
should be transient like the seed, but some things like the provider
implementation might have a legit use case to serialize. I'd rather
there be an error in Deserializing a SecureRandom instance with a
provider error than a dif
> On May 9, 2016, at 4:22 AM, Michael StJohns wrote:
>
> Does anyone else think there's something wrong with SecureRandom being
> serializable? In general, the internal state of a random number generator
> shouldn't be extract-able or even savable.
You are right. That's why we decide to make
> On May 8, 2016, at 10:26 PM, Xuelei Fan wrote:
>
> On 5/8/2016 9:06 PM, Wang Weijun wrote:
>> Ping again.
>>
>>> On May 3, 2016, at 10:26 AM, Wang Weijun wrote:
>>>
>>> Hi All
>>>
>>> Please take a review at
>>>
>>> http://cr.openjdk.java.net/~weijun/8154523/webrev.00
>>>
>>> Basically,
Does anyone else think there's something wrong with SecureRandom being
serializable? In general, the internal state of a random number
generator shouldn't be extract-able or even saveable.
I realize this behavior has probably been in the class since the
beginning - but I hadn't actually read
On 5/8/2016 9:06 PM, Wang Weijun wrote:
> Ping again.
>
>> On May 3, 2016, at 10:26 AM, Wang Weijun wrote:
>>
>> Hi All
>>
>> Please take a review at
>>
>> http://cr.openjdk.java.net/~weijun/8154523/webrev.00
>>
>> Basically, a reset in SHA1PRNG should forget the internal state and cached
>> ou
Ping again.
> On May 3, 2016, at 10:26 AM, Wang Weijun wrote:
>
> Hi All
>
> Please take a review at
>
> http://cr.openjdk.java.net/~weijun/8154523/webrev.00
>
> Basically, a reset in SHA1PRNG should forget the internal state and cached
> output.
>
> Thanks
> Max
>
