RFR: 8218021: jarsigner strips the execute permission when signing a .zip file
Seán Coffey
sean.coffey at oracle.com
Fri Jan 17 13:07:21 UTC 2020
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.
>>
>>
More information about the core-libs-dev
mailing list