RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files

[Weijun Wang]

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.coffey at 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.coffey at 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
>>>> 
>>>>