Security fixes are back; other fixes can go in. Time for build 18?

[Joseph D. Darcy]

Andrew John Hughes wrote:
> 2009/12/9 Joseph D. Darcy <Joe.Darcy at sun.com>:
>   
>> Andrew John Hughes wrote:
>>     
>>> 2009/12/8 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>>
>>>       
>>>> 2009/12/8 Joseph D. Darcy <Joe.Darcy at sun.com>:
>>>>
>>>>         

[snip]
>>>>
>>>>
>>>>         
>>> No sooner did I write that than it built:
>>>
>>> http://cr.openjdk.java.net/~andrew/tz/webrev.01/
>>>
>>>       
>> Approved.
>>
>>     
>>> The remaining three tz fixes are:
>>>
>>> changeset:   639:67c41d740e6d
>>> user:        peytoia
>>> date:        Mon Sep 08 15:21:55 2008 +0900
>>> summary:     6466476: (tz) Introduction of tzdata2005r can introduce
>>> incompatility issues with some JDK1.1 3-letter TZ Ids
>>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/67c41d740e6d
>>>
>>> changeset:   1693:92b6482e7719
>>> user:        peytoia
>>> date:        Mon Aug 31 14:53:05 2009 +0900
>>> summary:     6456628: (tz) Default timezone is incorrectly set
>>> occasionally on Linux
>>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/92b6482e7719
>>>
>>>
>>>       
>> These other backports approved.
>>
>>     
>>> and http://cr.openjdk.java.net/~andrew/tz/webrev.02 which needs a bug ID.
>>>
>>>       
>> Approved to use 6908946 "(tz) Sync JDK 7 tz changes into OpenJDK 6" for this
>> change.
>>
>> Thanks,
>>
>> -Joe
>>
>>     
>
> Thanks. All of them are now in OpenJDK6.
>
> There is one more backport lurking in IcedTea6:
>
> http://cr.openjdk.java.net/~andrew/tz/webrev.03/
>
> The actual code fix went in to OpenJDK7 in the black hole between the
> two (b22): http://mail.openjdk.java.net/pipermail/security-dev/2009-August/001153.html
>  There should be a bug ID as a result -- presumably, you can discover
> that internally?
>   

Donning my fedora and brandishing a bullwhip, the bug id for this change 
was 6584033 "(tz) wrong buffer length in TimeZone_md.c"; from sccsdiff:

------- TimeZone.java -------
606,610c606
<       if (hasPermission()) {
<           defaultTimeZone = tz;
<       } else {
<           defaultZoneTL.set(tz);
<       }
---
 >       defaultTimeZone = tz;
640a637
 >               defaultZoneTL.set(null);

There was another file involved in this change, 
windows/native/java/util/TimeZone_md.c:

------- TimeZone_md.c -------
199a200
 >         bufSize = sizeof(val);
347c348
<     valueSize = MAX_ZONE_CHAR;
---
 >     valueSize = MAX_MAPID_LENGTH;

This is also the current difference between the OpenJDK 6 and JDK 7 
versions of this file.

> The test case included in the webrev is from Mark Wielaard and is
> contributed through Red Hat's SCA.
>   

There appears to be some test coverage of this change in still-closed 
regression tests.

> CCing i18n-dev in case they have any input; it would be nice to have
> the test case in 7 too as well as the fix.
>   

I'll approve this change going back if the change from the JDK 7 version 
of TimeZone.java and TimeZone_md.c are both applied to OpenJDK 6 and if 
the @bug line in the test includes 6584033.

Thanks,

-Joe