JDK-6948909 : Jarsigner removes MANIFEST.MF info for badly packages jar's
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version: 6u10,6u20,6u21
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,linux_ubuntu,windows_7
  • CPU: x86
  • Submitted: 2010-04-30
  • Updated: 2011-02-16
  • Resolved: 2010-05-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u21 b05Fixed 7Fixed OpenJDK6Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Server VM (build 16.3-b01, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Linux smlwx010 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:10:02 UTC 2010 i686 GNU/Linux

EXTRA RELEVANT SYSTEM CONFIGURATION :
Ubuntu provided SUN JDK packages

A DESCRIPTION OF THE PROBLEM :
Signing a jar file with MANIFEST.MF not as first entry or containing INDEX.LIST without the manifest in there causes all manifest information to be lost after siging. This was not the case in java 1.6.0_16

I have found similar issues but none describe this regression.

This issue causes some of our legacy OSGi-compatible jars to be broken after signing.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create a jar file using a zip tool and cause the META-INF/MANIFEST.MF not to be the first file.
Sign it
Compare initial MANIFEST.MF with signed MANIFEST.MF

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
no difference (except for signing info)
ACTUAL -
Only signing info in signed manifest, all initial info lost

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
reassemble the incorrectly packaged jar

Comments
EVALUATION Update after examining customer's zip files: 1. One zip file has MANIFEST.MF with "\n" as newline. Should be fixed. 2. One zip file's MANIFEST.MF has only one newline at the end. Will be fixed also. Although this is an input error but still a regression.
05-05-2010

WORK AROUND 1. Prepare the jar file using the jar command, not zip. If there's no existing MANIFEST.MF, the jar command will create one for you. Otherwise, use the "-m" option to include manifest information from specified manifest file. The jar command will reformat the specified manifest file so that all newline characters are "\r\n". 2. Sign the jar with a previous jarsigner (before 6u18)
05-05-2010

EVALUATION This is a regression of 6u18. 6543940 added a new method to precisely copy manifest header attributes so that resigned jars still verifies ok with the old signature. An error was introduced in this copy method. It detected two consequent newlines (\r\n) as the end of the header, but in fact, a newline can be \n or \r or \r\n. If the original MANIFEST.MF does not use \r\n as newline, the whole header will be ignored. The method should be enhanced to detect all possible formats of newlines. Also, the method should only be called when the orginal jar is already signed. This was the only case 6543940 was trying to solve.
05-05-2010