Manifest ignores last line if not terminated by line break

[Philipp Kunz]

Hi,

Without any impatience, but may I ask if someone has read the previous
message or if there is any opinion about it?

Regards,
Philipp

On Fri, 2019-02-15 at 22:30 +0100, Philipp Kunz wrote:
> Hi,
> 
> Manifest parsing an input stream given to the constructor or the read
> method ignores the contents of the last line unless terminated with a
> line break.
> 
> In course of my attempt to fix 8217375, I found that Manifest ignores
> the last line when not terminated with a line break whereas
> ManifestDigester throws an exception.
> Without ManifestDigester's different behavior, I'd have opted for
> parsing the last line also without a line break (or the last line
> being empty).
> But ManifestDigester cannot easily be changed that way, too, because
> the line breaks are part of the digested manifest portions.
> I don't think Manifest should accept any manifests that cannot later
> as well be signed and should therefore raise an error when there is
> no line break at the end of a manifest.
> Adding a new error condition adds potential for compatibility issues.
> On the other hand, I don't think the last 'ill'-terminated line
> should really be ignored silently.
> A good example how things can go wrong this way is
> JavaClassPathTest.java. It uses a one-line manifest without a
> trailing line break and m1.jar does not contain the expected Class-
> Path entry.
> In the long term the best option would probably be to re-unite
> Manifest's and ManifestDigester's parsing-related code the biggest
> challenge of which is not to change digests and thereby break
> existing jar signatures.
> 
> Attached is a patch with a proposed fix.
> 
> The bug number in
> test/jdk/java/util/jar/Manifest/NoLineBreakAtEndOfManifestFile.java
> is from another bug that lead me to it. If someone creates another
> bug it can be replaced. I haven't found an existing issue that
> matches.
> In test/jdk/tools/launcher/modules/classpath/JavaClassPathTest.java
> is a test case
> testJARManifestClassPathAttribute/testClassPathAttribute which I have
> no clue how this should really work. As far as I can tell the test is
> and was wrong but nevertheless passes.
> 
> Is there a chance to find a sponsor for fixing this?
> 
> Regards,
> Philipp