Everything looks fine to me. I’ve added myself as the CSR reviewer. In the Solution section, it probably should me “The existing warning introduced in JDK-8218021 is expanded to include symlink”. It is not a new warning.
Thanks, Max > On Aug 28, 2020, at 12:05 PM, Seán Coffey <sean.cof...@oracle.com> wrote: > > > On 28/08/2020 16:18, Weijun Wang wrote: >> 1. Add a comment on how to generate ZIPBYTES in the test. Not the byte[] >> declaration but how the original ZIP file is generated. > I'll add a comment block to the test: >> /* >> * Created using the createByteArray utility method. >> * The zipfile itself was created via this example: >> * $ ls -l z >> * lrwxrwxrwx 1 test test 4 Aug 27 18:33 z -> ../z >> * $ zip -ry test.zip z >> */ > >> >> 2. Does this require a CSR? The POSIX permission one had one. > > Fair point. I've logged one, just to be safe. > > regards, > Sean. > >> >> Thanks, >> Max >> >>> On Aug 28, 2020, at 10:17 AM, Seán Coffey <sean.cof...@oracle.com> wrote: >>> >>> I've been poking around the zip internals and am now able to locate the 16 >>> bits of interest. The position of these actual bits does appear to move >>> around from one test run to another. For now, I guess it's sufficient to >>> look for the pattern of interest in the signed zip file. New testcase added. >>> >>> http://cr.openjdk.java.net/~coffeys/webrev.8250968.v4/webrev/ >>> >>> regards, >>> Sean. >>> >>> On 27/08/2020 15:58, Weijun Wang wrote: >>>>> Looks like it was a conscious design decision to only allow recording of >>>>> POSIX permission bits for this field (& 0xFFF). I don't see anything >>>>> about symlink support in zipfs docs. >>>>> >>>> As long as that *byte* is there and it’s not difficult to locate, we can >>>> manually add the *bit* >>>> for symlink and see if jarsigner can keep it. >>>> >>>> —Max >>>> >>>>
