[RFR] 8216362: Incorrect jar file error message when there is an invalid manifest

[Lance Andersen]

Here is the webrev for the changes:

 http://cr.openjdk.java.net/~lancea/8216362/webrev.00/index.html <http://cr.openjdk.java.net/~lancea/8216362/webrev.00/index.html>

Best
Lance
> On Jan 9, 2019, at 12:13 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> On 1/8/19 7:17 PM, Philipp Kunz wrote:
>> Manifest.read throws an exception with the jar file name passed to the constructor the manifest was constructed with and not passed to the call to the read that throws the exception because the jarFilename variable is not reset after successful construction with read and will be used by subsequent calls to read if read is called (again) after the manifest has been constructed. The call to the constructor could be in a different context than the call to read and the jar file name could therefore be exposed in an unexpected context. After I first thought it was just annoying to get an unrelated jar file name in an exception message I see now a security concern as well.
> 
> That's a good point (and good catch!). I think we need to adjust the code so that if read is called and it throws an Exception it only contains the jar file name if called by the constructors in which the jar file name is passed as a parameter. Perhaps break up the read method into a private and public one with the private one containing an additional boolean parameter that is set to true if called by the constructor, otherwise it is false. If the boolean parameter is true, the jar file name is put in the exception, otherwise it is not.
> 
> I also think we should fix this in 12, so I raised the priority to 3.
> 
> --Sean
>> At first glance and in terms of expectable code changes to the questionable constructor of Manifest the above mentioned seems to be overlapping with issue JDK-8216362 but then JDK-8216362 is about the jar file name missing in an error message when it should be present and not the other way round. Attached is a patch for JDK-8216362 as it is described at the moment.
>> Philipp
>> On Tue, 2019-01-08 at 13:07 -0500, Sean Mullan wrote:
>>> In this case, the caller is passing in the filename through the public
>>> JarFile API so as long as it is not modified it should be ok. The
>>> concerns I raised previously are situations where the caller did not
>>> pass in the file or the JDK converts a relative path to an absolute
>>> path, which could reveal sensitive details about the filesystem.
>>> 
>>> --Sean

 <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>