Looks good.
--Sean
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.mul...@oracle.com
<mailto:sean.mul...@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.ander...@oracle.com <mailto:lance.ander...@oracle.com>
