RFR : 8159035: com/sun/crypto/provider/Cipher/CTS/CTSMode.java test crashed due to unhandled case of cipher length value as 0
Seán Coffey
sean.coffey at oracle.com
Fri Aug 25 13:28:54 UTC 2017
Tony pointed out off-list that the change to encodeISOArray() might not
work.
"I'm not certain the change to encodeISOArray() is not going to work. In
8, that method can be replaced by an intrinsic and miss your additional
check. Unlike in 9 where implEncodeISOArray() is intrinsfied. It maybe
best to backport the method name change done in 9 too."
I replied :
"That's a fair point Tony. Without risking too much change for
jdk8u-dev, would it be ok to ensure that the len value is not <= 0
before we call the method itself. There are only two call sites.
Refactoring of various methods too place in JDK 9 and introduced
implEncodeISOArray in that class. [1]. I think the change I'm proposing
is just as useful and safer :
new webrev :
http://cr.openjdk.java.net/~coffeys/webrev.8159035.8u.02/webrev/"
The security-dev list got dropped. Re-adding here.
Regards,
Sean.
On 16/08/17 13:14, Seán Coffey wrote:
>
> Looking to backport this fix to jdk8u-dev. The bug report is not
> public but the JDK 9 review thread captures the details. The fix is
> similar. Some extra intrinsics work in jdk9 wasn't applicable for the
> jdk8u-dev port.
>
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044560.html
>
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8159035.8u/webrev/
> --
> Regards,
> Sean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170825/5a22410f/attachment.htm>
More information about the security-dev
mailing list