RFR: 8218021: jarsigner strips the execute permission when signing a .zip file

[Seán Coffey]

Hi Philipp,

On 17/01/2020 12:40, Philipp Kunz wrote:
> Hi Sean,
>
> Nice patch. I wonder why permissions should be preserved only in zip
> files. Jar files also are zip files, according to the jar file specs,
> and hence, shouldn't jar files benefit of preserving permissions, too?
Thanks for your comments. The jar tool has never been interested in the 
posix
permissions fields for the individual entries. Such a change could yield 
more
interoperability issues. Such a change would also need much more 
consideration

The zip tool on the other hand has always populated this field and I 
think the case
at hand is unique here (preserving attributes already created by 
non-java tools)
>
> The file name extension is most often zip for zip files and jar for jar
> files but is that really a safe assumption? I would not expect it
> always. Removing
Yes, I didn't see any easy way to distinguish a zip file from a jar file 
without being
more invasive and scanning file attributes for that file. I could take 
that approach
if it's deemed necessary.

regards,
Sean.
>
>> if (zf.getName().toLowerCase().endsWith(".zip")) {
> along with similar code in ZipFile would avoid discussing that question
> and the test would not have to check that files with another name
> extension than zip don't preserve permissions.
>
> Philipp
>
>
> On Fri, 2020-01-17 at 10:59 +0000, Seán Coffey wrote:
>> Hi,
>>
>> Looking to introduce some JDK private functionality which will help
>> preserve internal zip file attribute permissions when jarsigner is
>> run
>> on a zip file. Some of the logic is taken from the recent work
>> carried
>> out in this area for zipfs API.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8218021
>> http://cr.openjdk.java.net/~coffeys/webrev.8218021/webrev/
>>
>> regards,
>> Sean.
>>
>>