RFR : 8159035: com/sun/crypto/provider/Cipher/CTS/CTSMode.java test crashed due to unhandled case of cipher length value as 0

[Anthony Scarpino]

Looks good

Tony

> On Aug 25, 2017, at 6:28 AM, Seán Coffey <sean.coffey at oracle.com> wrote:
> 
> 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/5ca7867c/attachment.htm>