RFR JDK-8211806: TLS 1.3 handshake server name indication is missing on a session resume

[Jamil Nimeh]

Hello all,

This addresses an issue where the client hello in a resumed TLS 1.3 
session lacks the server_name client hello extension.  This can cause 
servers who use this extension field to direct traffic to websites to 
present other certificate chains for other websites than the one the 
client actually desires (and specified in the original client hello 
where the extension is present).


JBS: https://bugs.openjdk.java.net/browse/JDK-8211806

Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8211806/

Happy Friday!

--Jamil

Re: DSA default algorithm for keytool -genkeypair. Bad choice?

[Weijun Wang]

I see.

The conf file is not smart enough to deal with default values for -sigalg, 
which can be different from different -keyalg/-keysize values.

Thanks
Max

> On Oct 13, 2018, at 12:39 AM, Michael StJohns  wrote:
> 
> I wasn't thinking so much a re-write as just forking the code and fixing the 
> things that need to be fixed while leaving the old version to wither on the 
> vine.  The usage page for the "new" program would indicate that there are no 
> defaults  anymore and that users should use the conf file approach if they 
> want to establish some.
> 
> This is more about not having to deal with the backwards compatibility issues.
> 
> Later, Mike
> 
> 
> On 10/12/2018 8:24 AM, Weijun Wang wrote:
>> At least, this single annoyance does not deserve a rewrite, the 
>> compatibility impact should be quite low.
>> 
>> So far, I've heard these requests related to keytool:
>> 
>> 1. Make it GNU-style, say, "keytool -list -keystore cacerts" to "keytool 
>> list --keystore=cacerts".
>> 
>> 2. Add more functions, say, -importprivatekey.
>> 
>> 3. Make some functions as APIs, say, -genkeypair, -certreq.
>> 
>> but still need no rewrite.
>> 
>> --Max
>> 
>> 
>> 
>>> On Oct 12, 2018, at 12:06 AM, Michael StJohns  wrote:
>>> 
>>> Any thought to just deprecating keytool as such and adding a new tool with 
>>> more modern semantics?e.g. don't mess with what people are using 
>>> (except for including a deprecation message), but fork the keytool source 
>>> tree and do some developments to "ktts" - Key tool - the sequel.   A lot 
>>> more freedom to rethink the syntax and semantics of key pair and key store 
>>> generation.
>>> 
>>> Mike
>>> 
>>> On 10/11/2018 11:44 AM, Sean Mullan wrote:
 I think if we all really think we are better off in the long run not 
 having defaults, we probably want to do this over 2 releases and give an 
 advance warning that the change is coming. In JDK 12, we could emit a 
 warning, ex:
 
 $ keytool -genkeypair ...
 Warning: the default keypair alg (DSA) is a legacy algorithm and is no 
 longer recommended. In the next release of the JDK, defaults will be 
 removed and the -keyalg option must be specified.
 
 (that's a bit wordy, but you get the idea)
 
 --Sean
 
 On 10/11/18 9:30 AM, Adam Petcher wrote:
> On 10/10/2018 5:05 PM, Anthony Scarpino wrote:
> 
>> On 10/10/2018 07:42 AM, Weijun Wang wrote:
>>> If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I 
>>> wonder if RSASSA-PSS signature can always use legacy RSA keys) or EC? 
>>> We don't have an option to specify ECCurve in keytool yet (a string 
>>> -keysize).
>>> 
>>> --Max
>>> 
>>> 
>> 
>> I would rather get rid of the default completely.
> +1
> 
> In addition to the usual problems with defaults, there is also the issue 
> that the user doesn't specify how the key pair can be used. The current 
> default produces a key that can only be used with signatures, but if we 
> change the default, then the key may also be used for encryption (RSA) or 
> key agreement (EC). I worry about the problems that can arise if we 
> change the default in a way that increases the capability of the key pair 
> that is produced.
> 
> 

Re: RFR: 8209862:CipherCore performance improvement

[Anthony Scarpino]

I'm ok with the changes.

Tony

On 10/10/2018 09:26 AM, Seán Coffey wrote:

Thanks for the review Adam. I've corrected those style issues.

Now waiting on 2nd Reviewer.

Regards,
Sean.

On 08/10/18 19:18, Adam Petcher wrote:


The organization is better now, thanks. The code looks good to me, but 
I would like to request another review from Tony (or someone else who 
is familiar with this code) before you push. There is a lot of 
complexity here, and it is hard for me to be sure that everything will 
behave the same after the change. It will be helpful to have another 
person examine the new code to ensure that it is correct.


Minor style issues(addressing them is optional):

Lines 848, 915, and 969 are longer than 80 characters
Line 1075: no space before ? character


On 10/2/2018 1:51 PM, Seán Coffey wrote:


Good points from Adam and Tony. I've taken them both on board. Sergey 
has already eliminated a lot of duplicate code but there was further 
optimizing possible in the two doFinal(..) methods. I've introduced a 
new 'fillOutputBuffer' method to help. Please review :


https://cr.openjdk.java.net/~coffeys/webrev.8209862.v2/webrev/

regards,
Sean.


On 01/10/2018 15:32, Adam Petcher wrote:
Looks like a nice improvement, but is it possible to do this without 
duplicating code? For example, code almost identical to this also 
appears starting on line 860:


971 } else { // encrypting
972 try {
973 outLen = finalNoPadding(finalBuf, finalOffset, output,
974 outputOffset, finalBufLen);
975 } finally {
976 // reset after doFinal() for GCM encryption
977 requireReinit = (cipherMode == GCM_MODE);
978 if (finalBuf != input) {
979 // done with internal finalBuf array. Copied to output
980 Arrays.fill(finalBuf, (byte) 0x00);
981 }
982 }
983 }
It may be possible to factor out the entire if/else statement and 
some of the code around it into a separate method and do the short 
buffer check and save/restore around it. Ideally, each doFinal 
method would have only a small amount of code to either allocate the 
array or check array lengths, and then they would call the same 
private method to do most of the work.


I would suggest a noreg-sqe label on the ticket to document that 
existing regression tests are used to ensure correctness of the 
modified code.


Minor code style comments: check for long lines (e.g. line 856) and 
missing spaces after commas in actual parameter lists (also e.g. 
line 856). Also, line 1076 is missing space around the '?' and ':' 
characters. I can check the code again and give you the complete 
list after we sort out the code duplication.



On 10/1/2018 9:11 AM, Seán Coffey wrote:
JDK-8207775 introduced some performance regressions in the 
ciphercore area. Sergey Kuksenko has been looking at this and has 
contributed the following patch:


http://cr.openjdk.java.net/~skuksenko/crypto/8209862/
bug report : https://bugs.openjdk.java.net/browse/JDK-8209862

I've been reviewing it and ran functionality and TCK testing. 
Didn't see any issues. Sergey has also confirmed that the patch 
helps to alleviate the performance issues introduced. More details 
regards approach for fix are in the bug description.


Thanks Sergey! I'm looking for another review from security team.

Re: DSA default algorithm for keytool -genkeypair. Bad choice?

[Michael StJohns]

I wasn't thinking so much a re-write as just forking the code and fixing 
the things that need to be fixed while leaving the old version to wither 
on the vine.  The usage page for the "new" program would indicate that 
there are no defaults  anymore and that users should use the conf file 
approach if they want to establish some.


This is more about not having to deal with the backwards compatibility 
issues.


Later, Mike


On 10/12/2018 8:24 AM, Weijun Wang wrote:

At least, this single annoyance does not deserve a rewrite, the compatibility 
impact should be quite low.

So far, I've heard these requests related to keytool:

1. Make it GNU-style, say, "keytool -list -keystore cacerts" to "keytool list 
--keystore=cacerts".

2. Add more functions, say, -importprivatekey.

3. Make some functions as APIs, say, -genkeypair, -certreq.

but still need no rewrite.

--Max




On Oct 12, 2018, at 12:06 AM, Michael StJohns  wrote:

Any thought to just deprecating keytool as such and adding a new tool with more modern 
semantics?e.g. don't mess with what people are using (except for including a 
deprecation message), but fork the keytool source tree and do some developments to 
"ktts" - Key tool - the sequel.   A lot more freedom to rethink the syntax and 
semantics of key pair and key store generation.

Mike

On 10/11/2018 11:44 AM, Sean Mullan wrote:

I think if we all really think we are better off in the long run not having 
defaults, we probably want to do this over 2 releases and give an advance 
warning that the change is coming. In JDK 12, we could emit a warning, ex:

$ keytool -genkeypair ...
Warning: the default keypair alg (DSA) is a legacy algorithm and is no longer 
recommended. In the next release of the JDK, defaults will be removed and the 
-keyalg option must be specified.

(that's a bit wordy, but you get the idea)

--Sean

On 10/11/18 9:30 AM, Adam Petcher wrote:

On 10/10/2018 5:05 PM, Anthony Scarpino wrote:


On 10/10/2018 07:42 AM, Weijun Wang wrote:

If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I wonder if 
RSASSA-PSS signature can always use legacy RSA keys) or EC? We don't have an 
option to specify ECCurve in keytool yet (a string -keysize).

--Max




I would rather get rid of the default completely.

+1

In addition to the usual problems with defaults, there is also the issue that 
the user doesn't specify how the key pair can be used. The current default 
produces a key that can only be used with signatures, but if we change the 
default, then the key may also be used for encryption (RSA) or key agreement 
(EC). I worry about the problems that can arise if we change the default in a 
way that increases the capability of the key pair that is produced.

Re: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue

[Sean Mullan]

On 10/12/18 10:33 AM, Langer, Christoph wrote:

Sean, what is your take on this?


Sorry, I haven't had time to look at this in more detail yet. But, let's 
take a step back first. Can you or Matthias explain in more detail why 
this fix is necessary? What are the use cases and motivation? The bug 
report doesn't go into any detail about that and there isn't anything 
in the initial RFR email that explains why this change is useful or 
necessary. As a general guideline or advice, RFEs should include this 
type of information so that Reviewers understand more of the context and 
motivation behind the change.


Thanks,
Sean

RE: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue

[Langer, Christoph]

Hi Matthias,

I generally support this enhancement of IOExceptions to include path 
information.

I also think that we should protect this with the java.security property 
"jdk.includeInExceptions" and agree that "path" would be a good choice since it 
is generic enough to be used in other places where Exceptions are thrown that 
might include path names. As for some comment from security-folks: Sean, what 
is your take on this?

As for the implementation: We should definitely get rid of the upcall into Java 
from JNU_ThrowIOExceptionWithLastErrorAndPath and build the exception message 
in that function only, just using the " jstring path" argument.

The reason for having the current implementation of ExceptionUtils. 
createExceptionTextWithPath, as you suggested in your webrev was that we were 
chasing a very specific customer issue where cwd and user.dir diverged (e.g. 
because of some 3rd party native library which changed the cwd). And this code 
is somehow still around.
So, user.dir should definitely not be part of the exception message. And 
whether the current cwd should be contained should be reviewed in detail again. 
Maybe at some places it is interesting but on other places it isn't at all.

Best regards
Christoph

> -Original Message-
> From: core-libs-dev  On Behalf
> Of Baesken, Matthias
> Sent: Freitag, 12. Oktober 2018 15:19
> To: Alan Bateman ; security-
> d...@openjdk.java.net; core-libs-...@openjdk.java.net
> Subject: [CAUTION] RE: RFR: 8211752:
> JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions
> with path causing the issue
> 
> Hi Alan, Goetz,
> 
> >There are several issues with this proposal. The security concern is the main
> one and I think we should wait for comment from security-dev.
>   .
> 
> >If this is required, I would choose a more generic tag
> 
> >so it can be reused in other places.
> 
> >I would just use "path".
> 
> >
> 
> >Best regards,
> 
> >  Goetz.
> 
> Thanks for  the comments .   Sure,  I can use path  for the category naming  
> as
> well, but would be good to hear the  opinions of  the security-dev guys on
> this .
> 
> > The second concern is that the patch is incomplete and inconsistent in that
> it changes the exception throw by two methods,
> >it ignores other file I/O methods that throw exceptions.
> 
> We  have these extended exceptions for quite some time in our JVM;   we
> decided to   enhance exceptions where we have a path already "at hand" ,
>   so it was easy to extend the exceptions .
> In case you think this can be done with some others , that's fine with me -  
> do
> you have some concrete examples ?
> 
> A lot of IO exceptions currently thrown that use
> JNU_ThrowIOExceptionWithLastError  do not have a path (at least not where
> the exception is thrown).
> 
> 
> Best regards ,
> Matthias
> 
> 
> 
> From: Alan Bateman 
> Sent: Freitag, 12. Oktober 2018 11:18
> To: Baesken, Matthias ; security-
> d...@openjdk.java.net; core-libs-...@openjdk.java.net
> Subject: Re: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath -
> enhance some IOExceptions with path causing the issue
> 
> On 12/10/2018 09:12, Baesken, Matthias wrote:
> 
> Ping ...  any reviews / comments ?
> 
> Should I add  a category  , for example"ioExceptionsWithPath" to the
> java.security - file  to control  the enabling/disabling of the  enhanced
> exception ?
> 
>   java.security
> 
> #
> # Enhanced exception message information
> ...
> #jdk.includeInExceptions=hostInfo,jar,ioExceptionsWithPath
> 
> There are several issues with this proposal. The security concern is the main
> one and I think we should wait for comment from security-dev. The second
> concern is that the patch is incomplete and inconsistent in that it changes 
> the
> exception throw by two methods, it ignores other file I/O methods that
> throw exceptions. Finally there is the concerns with the patch itself that 
> both
> Roger and I commented on.
> 
> -Alan

RE: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue

[Baesken, Matthias]

Hi Alan, Goetz,

>There are several issues with this proposal. The security concern is the main 
>one and I think we should wait for comment from security-dev.
  .

>If this is required, I would choose a more generic tag

>so it can be reused in other places.

>I would just use "path".

>

>Best regards,

>  Goetz.

Thanks for  the comments .   Sure,  I can use path  for the category naming  as 
well, but would be good to hear the  opinions of  the security-dev guys on this 
.

> The second concern is that the patch is incomplete and inconsistent in that 
> it changes the exception throw by two methods,
>it ignores other file I/O methods that throw exceptions.

We  have these extended exceptions for quite some time in our JVM;   we decided 
to   enhance exceptions where we have a path already "at hand" ,
  so it was easy to extend the exceptions .
In case you think this can be done with some others , that's fine with me -  do 
you have some concrete examples ?

A lot of IO exceptions currently thrown that use 
JNU_ThrowIOExceptionWithLastError  do not have a path (at least not where the 
exception is thrown).


Best regards ,
Matthias



From: Alan Bateman 
Sent: Freitag, 12. Oktober 2018 11:18
To: Baesken, Matthias ; 
security-dev@openjdk.java.net; core-libs-...@openjdk.java.net
Subject: Re: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance 
some IOExceptions with path causing the issue

On 12/10/2018 09:12, Baesken, Matthias wrote:

Ping ...  any reviews / comments ?

Should I add  a category  , for example"ioExceptionsWithPath" to the 
java.security - file  to control  the enabling/disabling of the  enhanced 
exception ?

  java.security

#
# Enhanced exception message information
...
#jdk.includeInExceptions=hostInfo,jar,ioExceptionsWithPath

There are several issues with this proposal. The security concern is the main 
one and I think we should wait for comment from security-dev. The second 
concern is that the patch is incomplete and inconsistent in that it changes the 
exception throw by two methods, it ignores other file I/O methods that throw 
exceptions. Finally there is the concerns with the patch itself that both Roger 
and I commented on.

-Alan

Re: DSA default algorithm for keytool -genkeypair. Bad choice?

[Weijun Wang]

At least, this single annoyance does not deserve a rewrite, the compatibility 
impact should be quite low.

So far, I've heard these requests related to keytool:

1. Make it GNU-style, say, "keytool -list -keystore cacerts" to "keytool list 
--keystore=cacerts".

2. Add more functions, say, -importprivatekey.

3. Make some functions as APIs, say, -genkeypair, -certreq.

but still need no rewrite.

--Max



> On Oct 12, 2018, at 12:06 AM, Michael StJohns  wrote:
> 
> Any thought to just deprecating keytool as such and adding a new tool with 
> more modern semantics?e.g. don't mess with what people are using (except 
> for including a deprecation message), but fork the keytool source tree and do 
> some developments to "ktts" - Key tool - the sequel.   A lot more freedom to 
> rethink the syntax and semantics of key pair and key store generation.
> 
> Mike
> 
> On 10/11/2018 11:44 AM, Sean Mullan wrote:
>> I think if we all really think we are better off in the long run not having 
>> defaults, we probably want to do this over 2 releases and give an advance 
>> warning that the change is coming. In JDK 12, we could emit a warning, ex:
>> 
>> $ keytool -genkeypair ...
>> Warning: the default keypair alg (DSA) is a legacy algorithm and is no 
>> longer recommended. In the next release of the JDK, defaults will be removed 
>> and the -keyalg option must be specified.
>> 
>> (that's a bit wordy, but you get the idea)
>> 
>> --Sean
>> 
>> On 10/11/18 9:30 AM, Adam Petcher wrote:
>>> On 10/10/2018 5:05 PM, Anthony Scarpino wrote:
>>> 
 On 10/10/2018 07:42 AM, Weijun Wang wrote:
> 
> If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I wonder 
> if RSASSA-PSS signature can always use legacy RSA keys) or EC? We don't 
> have an option to specify ECCurve in keytool yet (a string -keysize).
> 
> --Max
> 
> 
 
 
 I would rather get rid of the default completely.
>>> 
>>> +1
>>> 
>>> In addition to the usual problems with defaults, there is also the issue 
>>> that the user doesn't specify how the key pair can be used. The current 
>>> default produces a key that can only be used with signatures, but if we 
>>> change the default, then the key may also be used for encryption (RSA) or 
>>> key agreement (EC). I worry about the problems that can arise if we change 
>>> the default in a way that increases the capability of the key pair that is 
>>> produced.
>> 
> 

Re: DSA default algorithm for keytool -genkeypair. Bad choice?

[Weijun Wang]

Great, I file a CSR at https://bugs.openjdk.java.net/browse/JDK-8212111. Please 
take a review.

Thanks
Max

> On Oct 11, 2018, at 11:44 PM, Sean Mullan  wrote:
> 
> I think if we all really think we are better off in the long run not having 
> defaults, we probably want to do this over 2 releases and give an advance 
> warning that the change is coming. In JDK 12, we could emit a warning, ex:
> 
> $ keytool -genkeypair ...
> Warning: the default keypair alg (DSA) is a legacy algorithm and is no longer 
> recommended. In the next release of the JDK, defaults will be removed and the 
> -keyalg option must be specified.
> 
> (that's a bit wordy, but you get the idea)
> 
> --Sean
> 
> On 10/11/18 9:30 AM, Adam Petcher wrote:
>> On 10/10/2018 5:05 PM, Anthony Scarpino wrote:
>>> On 10/10/2018 07:42 AM, Weijun Wang wrote:
 
 If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I wonder 
 if RSASSA-PSS signature can always use legacy RSA keys) or EC? We don't 
 have an option to specify ECCurve in keytool yet (a string -keysize).
 
 --Max
 
 
>>> 
>>> 
>>> I would rather get rid of the default completely.
>> +1
>> In addition to the usual problems with defaults, there is also the issue 
>> that the user doesn't specify how the key pair can be used. The current 
>> default produces a key that can only be used with signatures, but if we 
>> change the default, then the key may also be used for encryption (RSA) or 
>> key agreement (EC). I worry about the problems that can arise if we change 
>> the default in a way that increases the capability of the key pair that is 
>> produced.
> 

RE: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue

[Lindenmaier, Goetz]

Hi,

If this is required, I would choose a more generic tag
so it can be reused in other places.
I would just use "path".

Best regards,
  Goetz.


> -Original Message-
> From: core-libs-dev  On Behalf
> Of Baesken, Matthias
> Sent: Freitag, 12. Oktober 2018 10:13
> To: security-dev@openjdk.java.net; core-libs-...@openjdk.java.net
> Subject: [CAUTION] RE: RFR: 8211752:
> JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions
> with path causing the issue
> 
> Ping ...  any reviews / comments ?
> 
> Should I add  a category  , for example"ioExceptionsWithPath" to the
> java.security - file  to control  the enabling/disabling of the  enhanced
> exception ?
> 
>   java.security
> 
> #
> # Enhanced exception message information
> ...
> #jdk.includeInExceptions=hostInfo,jar,ioExceptionsWithPath
> 
> 
> Thanks, Matthias
> 
> 
> From: Baesken, Matthias
> Sent: Dienstag, 9. Oktober 2018 14:12
> To: security-dev@openjdk.java.net; core-libs-...@openjdk.java.net
> Cc: Alan Bateman (alan.bate...@oracle.com) 
> Subject: FW: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath -
> enhance some IOExceptions with path causing the issue
> 
> Hello, Alan commented on it :
> 
> 
>   *   This proposal will require a security review as it leaks sensitive
> information into exceptions.
> 
> So I forward it to security-dev as well.
> 
> If needed,  we might  use something similar to  JDK-8207768  where a
> category  has been added  for  enhanced exception messages to the
> java.security file .
> 
> Best regards, Matthias
> 
> From: Baesken, Matthias
> Sent: Dienstag, 9. Oktober 2018 13:40
> To: core-libs-...@openjdk.java.net d...@openjdk.java.net>
> Cc: Langer, Christoph
> mailto:christoph.lan...@sap.com>>;
> Lindenmaier, Goetz
> mailto:goetz.lindenma...@sap.com>>
> Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath -
> enhance some IOExceptions with path causing the issue
> 
> 
> Hello, please review the following change .
> It enhances a number of JNU_ThrowIOExceptionWithLastError  calls with
> path and current working directory information.
> For this, a new function JNU_ThrowIOExceptionWithLastErrorAndPath is
> added.
> 
> bug and webrev :
> 
> https://bugs.openjdk.java.net/browse/JDK-8211752
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8211752.0/
> 
> Thanks, Matthias

Re: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue

[Alan Bateman]

On 12/10/2018 09:12, Baesken, Matthias wrote:


Ping …  any reviews / comments ?

Should I add  a category  , for example    “ioExceptionsWithPath” 
to the java.security – file  to control  the enabling/disabling of 
the  enhanced exception ?


  java.security

#

# Enhanced exception message information

…

#jdk.includeInExceptions=hostInfo,jar,ioExceptionsWithPath


There are several issues with this proposal. The security concern is the 
main one and I think we should wait for comment from security-dev. The 
second concern is that the patch is incomplete and inconsistent in that 
it changes the exception throw by two methods, it ignores other file I/O 
methods that throw exceptions. Finally there is the concerns with the 
patch itself that both Roger and I commented on.


-Alan

RE: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue

[Baesken, Matthias]

Ping ...  any reviews / comments ?

Should I add  a category  , for example"ioExceptionsWithPath" to the 
java.security - file  to control  the enabling/disabling of the  enhanced 
exception ?

  java.security

#
# Enhanced exception message information
...
#jdk.includeInExceptions=hostInfo,jar,ioExceptionsWithPath


Thanks, Matthias


From: Baesken, Matthias
Sent: Dienstag, 9. Oktober 2018 14:12
To: security-dev@openjdk.java.net; core-libs-...@openjdk.java.net
Cc: Alan Bateman (alan.bate...@oracle.com) 
Subject: FW: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance 
some IOExceptions with path causing the issue

Hello, Alan commented on it :


  *   This proposal will require a security review as it leaks sensitive 
information into exceptions.

So I forward it to security-dev as well.

If needed,  we might  use something similar to  JDK-8207768  where a category  
has been added  for  enhanced exception messages to the
java.security file .

Best regards, Matthias

From: Baesken, Matthias
Sent: Dienstag, 9. Oktober 2018 13:40
To: core-libs-...@openjdk.java.net
Cc: Langer, Christoph 
mailto:christoph.lan...@sap.com>>; Lindenmaier, Goetz 
mailto:goetz.lindenma...@sap.com>>
Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some 
IOExceptions with path causing the issue


Hello, please review the following change .
It enhances a number of JNU_ThrowIOExceptionWithLastError  calls with path and 
current working directory information.
For this, a new function JNU_ThrowIOExceptionWithLastErrorAndPath is added.

bug and webrev :

https://bugs.openjdk.java.net/browse/JDK-8211752

http://cr.openjdk.java.net/~mbaesken/webrevs/8211752.0/

Thanks, Matthias