<div dir="ltr">I understood what you said.<br>And thank you for forwarding this mail to security-dev.<br>If it is decided to fix  this issue and this issue is not as much work as I thought.<br>If you give me the opportunity to change the code via PR, it will be a great honor for a lifetime as a Java developer. <div><br></div><div>Thanks :)</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">2023년 4월 29일 (토) 오전 2:04, Sean Mullan <<a href="mailto:sean.mullan@oracle.com" target="_blank">sean.mullan@oracle.com</a>>님이 작성:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[This should be discussed on the security alias so I am copying <br>
security-dev and -bcc-ing core-libs-dev]<br>
<br>
As Bernd noted, use of SHA1PRNG should ideally be replaced with a <br>
stronger secure random algorithm, so the impact of this issue is <br>
probably not that significant. That said, I think this is still worthy <br>
of fixing.<br>
<br>
On 4/28/23 7:40 AM, Bernd wrote:<br>
> There are two solutions I think.<br>
> <br>
> 1. Create a constructor for SecureRandom.<br>
<br>
#1 seems easy enough. We can add a SecureRandom(SecureRandomParameters) <br>
to sun.security.provider.SecureRandom. (The ctor can ignore the <br>
parameter and just call SecureRandom()).<br>
<br>
I can file an issue on your behalf.<br>
<br>
> 2. Compare using getConstructors instead of getConstrctor.<br>
<br>
--Sean<br>
</blockquote></div></div></div>