United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6948909 Jarsigner removes MANIFEST.MF info for badly packages jar's
6948909 : Jarsigner removes MANIFEST.MF info for badly packages jar's

Details
Type:
Bug
Submit Date:
2010-04-30
Status:
Resolved
Updated Date:
2011-02-16
Project Name:
JDK
Resolved Date:
2010-05-25
Component:
core-libs
OS:
linux_ubuntu,linux,windows_7
Sub-Component:
java.util.jar
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u10,6u20,6u21
Fixed Versions:
6u21

Related Reports
Backport:
Backport:
Duplicate:
Duplicate:
Duplicate:
Relates:
Relates:
Relates:

Sub Tasks

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

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.
                                     
2010-05-05
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)
                                     
2010-05-05
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.
                                     
2010-05-05



Hardware and Software, Engineered to Work Together