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
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
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
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
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
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
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
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,
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:
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
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
...
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".
>
12 matches
Mail list logo
