Hi Martin,
I am still concerned about the odd workaround for this issue. Can you
comment on my previous comment that I raised?:
On 4/23/19 4:33 PM, Sean Mullan wrote:> However, I think there may be a
more subtle bug or configuration issue
> underlying this. It seems like this could come up in real scenarios. You
> should never disable a strong algorithm, even if it is unsupported, in
> order to establish a TLS session. It should be able to negotiate a
> session using a different algorithm.
>
> We have seen a similar issue with RSA-PSS like this with the SunMSCAPI
> provider but I think that was a bit different. Tony, or Xuelei, does
> this seem familiar?
>
> So, unless you have a good explanation for that, on the outset, I don't
> think the fix is appropriate and we should spend more time looking at
> this. In the interests of time, I would ProblemList this test and open a
> separate bug for this issue.
Thanks,
Sean
On 4/23/19 4:52 PM, Martin Balao wrote:
Hi Sean, Xuelei,
Thanks for your feedback. You're both right, the security property value
was not being considered (and my testing environments are not helping at
all, as I could not reproduce the bug).
Here it's Webrev.01:
* http://cr.openjdk.java.net/~mbalao/webrevs/8222805/8222805.webrev.01/
@Xuelei, is that what you meant?
Kind regards,
Martin.-
