jdk9/10 reject zip/jar files where seconds value of timestamp is out of supported range 0 - 59

[Claes Redestad]

Hi,

it appears this is a difference where java.util.Date is carrying the 
overflow(s), while the
java.time-based implementation is more strict.  Same issue assumedly 
exist for most
fields in the dos format (minutes can be 0-63, hours 0-31, days 0-31...).

The dosToJavaTime implementation was changed to use java.time mostly as 
a cleanup
(https://bugs.openjdk.java.net/browse/JDK-8066644), but this difference 
in strictness was
overlooked..

Most compelling option for now might be to revert to the code in 8:

     public static long dosToJavaTime8(long dtime) {
         @SuppressWarnings("deprecation") // Use of date constructor.
         Date d = new Date((int)(((dtime >> 25) & 0x7f) + 80),
                           (int)(((dtime >> 21) & 0x0f) - 1),
                           (int)((dtime >> 16) & 0x1f),
                           (int)((dtime >> 11) & 0x1f),
                           (int)((dtime >> 5) & 0x3f),
                           (int)((dtime << 1) & 0x3e));
         return d.getTime();
     }

/Claes

On 2017-10-06 14:24, Baesken, Matthias wrote:
> Hello,
>
> When iterating on the zip entries (and printing the time stamps)  of an old  sqljdbc.jar    the exception
>
> "java.time.DateTimeException: Invalid value for SecondOfMinute (valid values 0 - 59): 60"
> occured (issue has been seen on Windows).
>
> Looks like the  dosToJavaTime function in  ZipUtils.java  of jdk9/jdk10 is a bit more "sensitive"
> about the input it gets, compared to jdk8.
> In both implementations :
>
> java.base/share/classes/java/util/zip/ZipUtils.java
> jdk.zipfs/share/classes/jdk/nio/zipfs/ZipUtils.java
>
>
> the computation of the "seconds" values is done by
>
> public static long dosToJavaTime(long dtime) {
> ...
> (int) ((dtime << 1) & 0x3e));
> ...
> }
>
> 0x3e is  binary 111110 or  decimal 62,  so larger values than the supported maximum 59 can occur
> (maybe only with old/problematic archives but still we had such an example).
>
> When looking a bit more closely into it, we found that the "second = 60" value  was coming from a  long value  930973758
> that was passed to  ZipUtils.dosToJavaTime as  dtime argument.
>
> (found this out by adding an enhanced chained exception to jdk9 showing the dtime value passed to dosToJavaTime).
>
> Here is an example of the iteration on entries of such a "bad" zip file :
>
> C:\JVM\openjdk10\bin\java  ZipIterate
>
> Iterate von ZipFile:
> --------------------------------------
> name of ZipEntry:com/microsoft/sqlserver/jdbc/AppDTVImpl$SetValueOp.class
> Exception in thread "main" java.time.DateTimeException: Invalid value for SecondOfMinute (valid values 0 - 59): 60
>          at java.base/java.time.temporal.ValueRange.checkValidValue(ValueRange.java:311)
>          at java.base/java.time.temporal.ChronoField.checkValidValue(ChronoField.java:714)
>          at java.base/java.time.LocalTime.of(LocalTime.java:322)
>          at java.base/java.time.LocalDateTime.of(LocalDateTime.java:337)
>          at java.base/java.util.zip.ZipUtils.dosToJavaTime(ZipUtils.java:101)
>          at java.base/java.util.zip.ZipUtils.extendedDosToJavaTime(ZipUtils.java:114)
>          at java.base/java.util.zip.ZipEntry.getTime(ZipEntry.java:198)
>          at ZipIterate.main(ZipIterate.java:37)
>
>
>
> A similar problem (dealing with days/months not seconds out of supported range) is described here :
> https://bugs.openjdk.java.net/browse/JDK-8184940
> "JDK 9 rejects zip files where the modified day or month is 0"
>
>
> Compared to jdk8,  this is a regression so I think it would be good to have a better handling of problematic out of range seconds-values.
>
> Do you think it would be sufficient to adjust the out of range seconds to the supported max-value 59 ?
> Or is something more sophisticated prefered ?
> I found the enhanced chained exception showing the  dtime long values helpful too, should I submit it ?
>
> Best regards,
>              Matthias