Manifest ignores last line if not terminated by line break

[Lance Andersen]

Its on my list, just have not time to look at it

> On Feb 22, 2019, at 6:16 AM, Philipp Kunz <philipp.kunz at paratix.ch> wrote:
> 
> 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

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>