[RFR] 8216362: Incorrect jar file error message when there is an invalid manifest
sean.mullan at oracle.com
Wed Jan 9 17:13:28 UTC 2019
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.
> 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.
> 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.
More information about the core-libs-dev