Thank you, Tim! Please feel free to submit bugs and comments.
Xuelei
On 8/9/2018 4:23 PM, Tim Brooks wrote:
Hi Xuelei,
My test passed using that patch. I’ll continue to explore over the next
few days. But that patch resolves the main issues that I had encountered.
Thanks,
- Tim
On Aug 7
Hi Xuelei,
My test passed using that patch. I’ll continue to explore over the next few
days. But that patch resolves the main issues that I had encountered.
Thanks,
- Tim
> On Aug 7, 2018, at 8:54 AM, Xuelei Fan wrote:
>
> Xuelei
On 8/7/18 11:53 PM, Weijun Wang wrote:
On Aug 8, 2018, at 12:58 AM, Sean Mullan wrote:
On 8/6/18 8:20 PM, Weijun Wang wrote:
I'm not seeing how this would be a behavior change if it is a new option, can
you add more details on that? If I specify -providerName, intuitively I would
expect i
Hi Alan,
On 8/6/2018 11:12 PM, Alan Bateman wrote:
On 06/08/2018 20:11, joe darcy wrote:
Hello,
Various interfaces in the JDK extend Serializable and declare
serialVersionUID fields. Such fields are ineffectual and
@SuppressWarnings("serial") should be applied to such fields to
suppress f
On 8/9/2018 1:17 PM, Sean Mullan wrote:
A few (mostly minor) comments on the Solution section. I'll continue
my review of the rest of the CSR later.
First sentence, "from the existing API ECDSA ..." should that be "API
for ECDSA"?
// example: use KeyFactory to contruct a public key
typo: c
A few (mostly minor) comments on the Solution section. I'll continue my
review of the rest of the CSR later.
First sentence, "from the existing API ECDSA ..." should that be "API
for ECDSA"?
// example: use KeyFactory to contruct a public key
typo: construct
"This API does not standardize "
I'm waiting for the CSR approval for JDK 11:
https://bugs.openjdk.java.net/browse/JDK-8208526
Thanks,
Xuelei
On 8/9/2018 6:50 AM, Norman Maurer wrote:
I there any idea when the patch will be merged and a release will be cut so we
can enable testing with JDK11 again for netty ?
On 31. Jul 20
I there any idea when the patch will be merged and a release will be cut so we
can enable testing with JDK11 again for netty ?
> On 31. Jul 2018, at 07:19, Norman Maurer wrote:
>
> After digging more this morning I noticed the test code did made some wrong
> assumptions which just worked out
On 8/9/2018 4:25 AM, Sean Mullan wrote:
On 8/8/18 5:29 PM, Xuelei Fan wrote:
The "Default" algorithm defined in the SunJSSE provider is for TLS
protocols.
What if I set DTLS to be the default, though? Ex:
SSLContext.setDefault(SSLContext.getInstance("DTLS"));
Good point! Maybe, we also
On 8/8/18 5:29 PM, Xuelei Fan wrote:
The "Default" algorithm defined in the SunJSSE provider is for TLS
protocols.
What if I set DTLS to be the default, though? Ex:
SSLContext.setDefault(SSLContext.getInstance("DTLS"));
--Sean
Xuelei
On 8/8/2018 1:28 PM, Sean Mullan wrote:
On 8/8/18
Adding RFR to title..
On 09/08/2018 11:37, Seán Coffey wrote:
I've been looking further at how private/temporary buffers are used in
cipher/keystore management and identified some more areas that could
benefit with a more aggressive nulling out of contents.
I've been testing through use of st
I've been looking further at how private/temporary buffers are used in
cipher/keystore management and identified some more areas that could
benefit with a more aggressive nulling out of contents.
I've been testing through use of stepping through debugging sessions
while setting/getting keys an
Webrev updated at
http://cr.openjdk.java.net/~weijun/8076190/webrev.02
The only change is in keytool/Main and the test. keytool will not prompt for
store password if it detects a password-less keystore.
This is 3) below.
Thanks
Max
> On Jul 24, 2018, at 6:49 PM, Weijun Wang wrote:
>
> Pl
Matthias,
> On 9 Aug 2018, at 08:07, Baesken, Matthias wrote:
>
>> Did we get to a conclusion on whether to have central infrastructure to
>> read/parse the security property? As I recall, this one was originally
>> proposed before the generalization of the networking solution. There are
>> deta
Ok, thanks. Looks like the “Default” case is not-an-issue.
-Chris.
> On 8 Aug 2018, at 22:29, Xuelei Fan wrote:
>
> The "Default" algorithm defined in the SunJSSE provider is for TLS protocols.
>
> Xuelei
>
> On 8/8/2018 1:28 PM, Sean Mullan wrote:
>> On 8/8/18 1:58 PM, Anthony Scarpino wrote
> Did we get to a conclusion on whether to have central infrastructure to
> read/parse the security property? As I recall, this one was originally
> proposed before the generalization of the networking solution. There are
> details related to trimming that would be better not to duplicate if
> poss
16 matches
Mail list logo
