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
