RFR: 8339280: jarsigner -verify performs cross-checking between CEN and LOC [v14]

Sean Mullan mullan at openjdk.org
Wed Mar 26 13:05:21 UTC 2025


On Wed, 26 Mar 2025 02:33:02 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file’s central directory and its local file entries.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated with Sean's comments

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1138:

> 1136:     private void crossCheckEntries(String jarName) throws Exception {
> 1137:         List<String> locEntries = new ArrayList<>();
> 1138:         List<String> cenEntries;

You can move this declaration to where you first use it (line 1177).

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1163:

> 1161:                 }
> 1162: 
> 1163:                 readEntry(jis);

I think this method is only needed in order to get the code signers, right? If so, it can be moved to just before line 1174.

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1168:

> 1166:                         crossChkWarnings.add(String.format(rb.getString(
> 1167:                                 "entry.1.present.in.jarfile.but.unreadable"),
> 1168:                                 entryName));

I think we should continue after this, since the JarInputStream entry doesn't exist, so no need to compare code signers.

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner.properties line 215:

> 213: manifest.attribute.1.present.when.reading.jarinputstream.but.missing.via.jarfile=Manifest attribute %s is present when reading via JarInputStream but missing when reading via JarFile
> 214: manifest.attribute.1.differs.jarfile.value.2.jarinputstream.value.3=Manifest attribute %1$s differs: JarFile value = %2$s, JarInputStream value = %3$s
> 215: Entry.1.present.when.reading.jarinputstream.but.missing.via.JarFile=Entry %s is present when reading via JarInputStream but missing when reading via JarFile

Lower case the name ("entry.1")

(to be consistent with other property names)

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner.properties line 216:

> 214: manifest.attribute.1.differs.jarfile.value.2.jarinputstream.value.3=Manifest attribute %1$s differs: JarFile value = %2$s, JarInputStream value = %3$s
> 215: Entry.1.present.when.reading.jarinputstream.but.missing.via.JarFile=Entry %s is present when reading via JarInputStream but missing when reading via JarFile
> 216: entry.1.present.in.jarfile.but.unreadable=Entry %s is present in JarFile but unreadable

Shouldn't this be the opposite of "entry.1.present.when.reading.jarinputstream.but.missing.via.JarFile":

"Entry %s is present when reading via JarFile but missing when reading via JarInputStream"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2014049119
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2014064384
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2014081079
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2014066571
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2014072968


More information about the security-dev mailing list