Hi Sherman, thanks for getting back and bringing up these points.
(1) There is a "masked" security concern regarding adding the "ownership/permission" into the jar file.
"Security concern:
The current signed jar spec only protects the name and content of the jar entries. If any extra info is added, its value will not be used in the signing/verifying process. This means anyone can change these info in a signed jar and the user has no way to check if the file is genuine."
I didn't know that. However, as the default behavior does not change, these permission bits will not be propagated/used, unless the developer uses the API or the user of the jar tool enables the new option. One should probably add comments about this signing issue in the documentation then. Is there any way to augment jar signing to (conditionally?) include the external attributes field?
(2) Regarding the implementation whats the motivation of use the high byte of the "external file attributes" vs to use the info-zip as suggested in the report? I've not looked into zip/unzip implementation, which one is zip/unzip using?
"A group known as INFO-zip has devised a number of different extensions for ZIP for Unix. Their first and second extension attempts added support for UID and GID but not permissions. The third Unix extension, also known as the "ASi" or "un" extension, provides for file permissions and symlinks also. These extensions have become de-facto standards, and have not changed now since 1996."
I'm not aware of a document of specification for the INFO-zip extensions regarding UID, GID and even permissions. Maybe you can share this with me. But I've checked InfoZip's Zip and UnZip sources at https://sourceforge.net/projects/infozip/files/ and found they're using the CENATX field ( >> 16) like my patch does. Best regards Christoph