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