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

Sean Mullan sean.mullan at oracle.com
Wed Jan 9 20:46:31 UTC 2019

Looks good.


On 1/9/19 3:42 PM, Lance Andersen wrote:
> Here is the webrev for the changes:
> 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 
>> <mailto: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>

More information about the core-libs-dev mailing list