Jarsigner compatibility issue invalidating existing signatures
Philipp Kunz
philipp.kunz at paratix.ch
Thu Mar 7 15:27:30 UTC 2019
Hi,
Following up [1], [2] and to some extent [3] find a new patch attached.
Apart from ManifestDigester having problems parsing manifests with \r
for the line break, manifests without a trailing blank line are not
processed correctly in all cases. As an example, look at the existing
diffend.sh test which produces a jar diffend.new.jar file with an
invalid signature on lines 88..93. Jarsigner fails to detect this and
so does the test. The resulting manifest is missing a blank line after
the main attributes section and looks like this:
Manifest-Version: 1.0
Created-By: 1.7.0-internal (Sun Microsystems Inc.)
Today: Monday
Name: 1
SHA1-Digest: 5fpE8rMcH7VTtgIec2DQfV2R/14=
Another speciality is that endOfSection contains a blank line if and
only if that blank line is at the very end of the manifest file (or
stream or byte array). This makes digestWorkaround useless in that case
because digestWorkaround is then the same as digest without workaround.
Initially I thought, the missing lines after the last section could be
compensated by digestWorkaround which essentially produces a digest
without the trailing blank line but digestWorkaround is not applied to
main attributes and if successful would set
SignatureFileVerifier.workaround flag that would remain set for
subsequent digests which are processed in the order of the entries of
the signature file which is hard to predict and certainly does not
support to assume that the last manifest entry would be verified last.
As a starting point for further discussions, I'd like to suggest that
jarsigner keeps main attributes without a trailing blank line if there
are no files contained in the jar to sign. I wonder if this is worth it
but at least I believe that this is the most backwards-compatible
option possible. A trailing line is then added only when necessary and
the resulting jarfile would be invalid without as in the example above
with diffend.sh.
Any feedback and opinions welcome.
Regards,
Philipp
[1] https://mail.openjdk.java.net/pipermail/security-dev/2019-January/0
19200.html
[2] https://mail.openjdk.java.net/pipermail/security-dev/2019-January/0
19213.html
[3] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February
/058774.html
[4] https://bugs.openjdk.java.net/browse/JDK-8217375
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20190307/4a2f36f1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8217375.patch
Type: text/x-patch
Size: 315333 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20190307/4a2f36f1/8217375.patch>
More information about the security-dev
mailing list