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

[Langer, Christoph]

Hi Matthias,

I have closed your bug JDK-8188901 in favor of the bug that Sherman had opened before: https://bugs.openjdk.java.net/browse/JDK-8188869.

Please post a webrev for the change as suggested by Claes.

Thanks & Best regards
Christoph

> -----Original Message-----
> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
> Behalf Of Baesken, Matthias
> Sent: Montag, 9. Oktober 2017 09:49
> To: core-libs-dev at openjdk.java.net
> Subject: RE: jdk9/10 reject zip/jar files where seconds value of timestamp is
> out of supported range 0 - 59
> 
> Hi Claes, thanks for your feedback.
> 
> Hello,
>      I opened a bug :  JDK-8188901   jdk9/10 reject zip/jar files where seconds
> value of timestamp is out of supported range 0 - 59
> 
> https://bugs.openjdk.java.net/browse/JDK-8188901
> 
> In case  the dosToJavaTime change  was  to use java.time  was really just a
> cleanup,
>  I would  like to submit a change and go back  to  Date, is that  ok ?
> 
> The  suggested workaround by  Xueming Shen
> 
> >really wanted to suggest to just unzip/jar & jar those jar files again,
> >as a workaround ...
> 
> Is a good idea for some people,  however in complex sceanarios  people do
> not even currently get  the name of the archive in the exception  .
> So it is an issue to identify what to unpack/pack for them .
> Another issue might be the usage of signed archives .
> 
> 
> 
> Best regards,
>                 Matthias
> 
> 
> >
> > Message: 2
> > Date: Fri, 6 Oct 2017 16:02:19 +0200
> > From: Claes Redestad <claes.redestad at oracle.com>
> > To: core-libs-dev at openjdk.java.net
> > Subject: Re: jdk9/10 reject zip/jar files where seconds value of
> > 	timestamp is out of supported range 0 - 59
> > Message-ID: <e915d444-5f5f-0b88-649c-ef3c567d346c at oracle.com>
> > Content-Type: text/plain; charset=utf-8; format=flowed
> >
> > 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.jav
> > a: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
> >
> >
> >