Right, since nobody has replied I shall reply to my self!!
Now looking at the executable which was generated it is clear that it is a self extracting zip but its NOT in ZIP64 format which is VERY UNFORTUNATE indeed.
It seems that when signing ZIP files (self extractor ones or JAR files for that matter) that the COMMENT length record must be adjusted to account for the extra data added by the code signing and failure to do this will result in the ZIP file being deemed corrupted. UNFORTUNTELY this ZIP file header field which describes this comment length is only 2 bytes wide (ZIP64 format changes that ridiculously stupid limit). Now while in windows signtool might well add less than 64k of data to the end of the file alas in MacOS the codesign utility seems to add a staggering 190kB to the end of the file.
I had hoped to modify a tool which comes with launch4j (called sign4j) with the idea being to take the original unsigned executable, a signed copy of it and to produce an output file ith adjusted ZIP comment length header which could then be signed and subsequently still remain valid. ALAS due to the limitation of 64kb on the comment length it is not possible.
IS THERE ANY WAY ZIP64 FORMAT COULD BE USED INSTEAD????
SEEMS TO ME THAT THE MacOS capability in Jar2Exe is VERY BADLY THOUGHT OUT!
I ASK THE FOLLOWING QUESTION:
IS IT FIT FOR PURPOSE?
I certainly feel as though since code signing seems to not have been considered that I have been conned out of $145USD for a product that does not do what it says on the tin!
Right, since nobody has replied I shall reply to my self!!
Now looking at the executable which was generated it is clear that it is a self extracting zip but its NOT in ZIP64 format which is VERY UNFORTUNATE indeed.
It seems that when signing ZIP files (self extractor ones or JAR files for that matter) that the COMMENT length record must be adjusted to account for the extra data added by the code signing and failure to do this will result in the ZIP file being deemed corrupted. UNFORTUNTELY this ZIP file header field which describes this comment length is only 2 bytes wide (ZIP64 format changes that ridiculously stupid limit). Now while in windows signtool might well add less than 64k of data to the end of the file alas in MacOS the codesign utility seems to add a staggering 190kB to the end of the file.
I had hoped to modify a tool which comes with launch4j (called sign4j) with the idea being to take the original unsigned executable, a signed copy of it and to produce an output file ith adjusted ZIP comment length header which could then be signed and subsequently still remain valid. ALAS due to the limitation of 64kb on the comment length it is not possible.
IS THERE ANY WAY ZIP64 FORMAT COULD BE USED INSTEAD????
SEEMS TO ME THAT THE MacOS capability in Jar2Exe is VERY BADLY THOUGHT OUT!
I ASK THE FOLLOWING QUESTION:
IS IT FIT FOR PURPOSE?
I certainly feel as though since code signing seems to not have been considered that I have been conned out of $145USD for a product that does not do what it says on the tin!
Regards,
Dave