Thanks for review Tony. Comments inline..
On 27/07/18 21:02, Anthony Scarpino wrote:
If we are going to add more, here are two more ton consider:
- It looks like there is another Arrays.copyOf() on doFinal() line 851
Good point.
- doFinal()
at line 897 there might be something that should be
Hi,
On Mon, Jul 30, 2018 at 8:08 PM Xuelei Fan wrote:
> Would you mind look at the code I posted in the following thread:
> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html
JDK 11+21:
1. client.closeOutbound() then goes into NEED_WRAP.
2. Client wraps 24 bytes, result is
Hi,
On Tue, Jul 31, 2018 at 11:39 AM Simone Bordet wrote:
>
> Hi,
> On Mon, Jul 30, 2018 at 8:08 PM Xuelei Fan wrote:
> > Would you mind look at the code I posted in the following thread:
> > http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html
>
> JDK 11+21:
> 1. client.clo
Hi Simone,
Thanks for the quick feedback. Read more in-lines, please.
On 7/31/2018 3:10 AM, Simone Bordet wrote:
Hi,
On Tue, Jul 31, 2018 at 11:39 AM Simone Bordet wrote:
Hi,
On Mon, Jul 30, 2018 at 8:08 PM Xuelei Fan wrote:
Would you mind look at the code I posted in the following threa
The Status.CLOSED specification is defined as "The operation just closed
this side of the SSLEngine, or the operation could not be completed
because it was already closed.". My reading of the spec, the CLOSED
status means half-close. If wrap() status is CLOSED, it means write
side close; an
Hi,
On Tue, Jul 31, 2018 at 3:43 PM Xuelei Fan wrote:
> > 1. client.closeOutbound() then goes into NEED_WRAP.
> > 2. Client wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING.
> It might be a problem for application to make a right decision if using
> CLOSED status and NOT_HANDSHAKI
Hi,
On Tue, Jul 31, 2018 at 4:13 PM Xuelei Fan wrote:
>
> The Status.CLOSED specification is defined as "The operation just closed
> this side of the SSLEngine, or the operation could not be completed
> because it was already closed.". My reading of the spec, the CLOSED
> status means half-close
Hi,
Looks like we are on the same page now. For the data transportation
(wrap/unwrap), I agree we'd better use OK so that applications can make
the right decision.
Thanks,
Xuelei
On 7/31/2018 7:23 AM, Simone Bordet wrote:
Hi,
On Tue, Jul 31, 2018 at 4:13 PM Xuelei Fan wrote:
The Status.
Hi,
On 7/31/2018 6:43 AM, Xuelei Fan wrote:
Current jdk11 tip with your patch:
1. client.closeOutbound() then goes into NEED_WRAP.
2. Client wraps 24 bytes, result is CLOSED, then goes into NEED_UNWRAP.
3. Server unwraps 24 bytes, result is CLOSED, then goes into NEED_WRAP.
4. Server wraps 0 byt
I hereby nominate Adam Petcher to Membership in the Security Group.
Adam is a member of the Security Libraries Team at Oracle and has a
strong background in cryptography. He has been working on security for
the JDK since December 2016. Adam is also the lead of 2 significant
crypto related JEPs
Vote: yes
--Sean
Vote: yes
On 07/31/2018 08:58 AM, Sean Mullan wrote:
I hereby nominate Adam Petcher to Membership in the Security Group.
Adam is a member of the Security Libraries Team at Oracle and has a
strong background in cryptography. He has been working on security for
the JDK since December 2016. Ada
Vote: yes
--weijun
> On Jul 31, 2018, at 11:58 PM, Sean Mullan wrote:
>
> I hereby nominate Adam Petcher to Membership in the Security Group.
Vote: Yes
On 7/31/2018 8:58 AM, Sean Mullan wrote:
I hereby nominate Adam Petcher to Membership in the Security Group.
Adam is a member of the Security Libraries Team at Oracle and has a
strong background in cryptography. He has been working on security for
the JDK since December 2016. Adam i
Vote: Yes
On 07/31/2018 08:58 AM, Sean Mullan wrote:
I hereby nominate Adam Petcher to Membership in the Security Group.
Adam is a member of the Security Libraries Team at Oracle and has a
strong background in cryptography. He has been working on security for
the JDK since December 2016. Adam
Looking to improve management of internal buffers in KeyStore. The
com.sun.crypto.provider.KeyProtector class uses the PBEKey class to
protect some keys. Buffers can be freed up earlier if the caller takes
responsibility for lifecycle of PBEKey object. (hence no reliance on
Cleaner). Some other
Hi,
On Tue, Jul 31, 2018 at 5:10 PM Xuelei Fan wrote:
>
> Hi,
>
> On 7/31/2018 6:43 AM, Xuelei Fan wrote:
> > Current jdk11 tip with your patch:
> > 1. client.closeOutbound() then goes into NEED_WRAP.
> > 2. Client wraps 24 bytes, result is CLOSED, then goes into NEED_UNWRAP.
> > 3. Server unwrap
On 7/31/2018 12:13 PM, Simone Bordet wrote:
Hi,
On Tue, Jul 31, 2018 at 5:10 PM Xuelei Fan wrote:
Hi,
On 7/31/2018 6:43 AM, Xuelei Fan wrote:
Current jdk11 tip with your patch:
1. client.closeOutbound() then goes into NEED_WRAP.
2. Client wraps 24 bytes, result is CLOSED, then goes into NEE
On 7/24/18 9:38 PM, Weijun Wang wrote:
Something related.
Cipher has a similar init(..,params) and getParameters() structure and the spec
is also similar.
* The returned parameters may be the same that were used to initialize
* this cipher, or may contain a combination of default and random
*
Vote: Yes.
Brad
On 7/31/2018 8:58 AM, Sean Mullan wrote:
I hereby nominate Adam Petcher to Membership in the Security Group.
Adam is a member of the Security Libraries Team at Oracle and has a
strong background in cryptography. He has been working on security for
the JDK since December 201
Hi Martin,
Here are the review comments for the remaining files:
- Always check non-null result for JNIEnv FindClass(...) calls, e.g.
line 530 and 802
- Sometimes the check is there but is after the return value has been
used. These checks should be moved up, i.e. right after the
FindClas
I sent this email a bit prematurely. I still need to review TestTLS12.java.
All else is done.
Valerie
On 7/31/2018 4:26 PM, Valerie Peng wrote:
Hi Martin,
Here are the review comments for the remaining files:
- Always check non-null result for JNIEnv FindClass(...) calls, e.g.
line 530
Please take a review at
http://cr.openjdk.java.net/~weijun/8208602/webrev.00/
https://tools.ietf.org/html/rfc7468#section-3 explicitly allows WSP after the
header/footer:
textualmsg = preeb *WSP eol
*eolWSP
base64text
posteb *WSP [eol]
pre
Looks fine to me.
Xuelei
On 7/31/2018 7:34 PM, Weijun Wang wrote:
Please take a review at
http://cr.openjdk.java.net/~weijun/8208602/webrev.00/
https://tools.ietf.org/html/rfc7468#section-3 explicitly allows WSP after the
header/footer:
textualmsg = preeb *WSP eol
*eo
24 matches
Mail list logo
