Hi,
I'd like a review of this change to add session invalidation for
stateless resumption. It adds a cache that stateless resumes will check
against. The cache keeps track of only those sessions that are
invalidated, minimizing it's cost on the server. This is separate from
the existing se
On 4/3/20 4:13 PM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
Webrev: http://cr.openjdk.java.net/~xuelei/8242145/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8242141
CSR: https://bugs.openjdk.java.net/browse/JDK-8242145
Release-note: https://bugs.openjdk.java.
Hi,
I'd like a review of the following change. There wre inconsistencies
with SSLSession and session caching that needed to be fixed. They are:
- With stateless resumption, SSLSession.getSessionContext() would return
null.
- TLS 1.3 w/ session cache, the initial session was being added to the
On 4/4/20 6:11 PM, Xuelei Fan wrote:
Hi,
Could I have the following update reviewed?
http://cr.openjdk.java.net/~xuelei/8215711/webrev.00/
In the current TLS implementation, if one of "supported_groups"
extension and "key_share" extension is not present in the ClientHello
handshake mess
ithm will be thrown at getInstance() unlike other
asymmetric algorithms.
So to wrap all this up, it makes sense for consistency with prior
behavior that all 3 classes have an EDDSA entry. And the specific curve
usage is also consistent with what has already been integrated with XDH.
Tony
ype because of RFC 8410. We can
> define an AlgorithmParameters later if a future RFC defined anything.
>
> Thanks,
> Max
>
>> On Apr 2, 2020, at 10:45 AM, Anthony Scarpino
>> wrote:
>>
>>> On 4/1/20 6:44 PM, Weijun Wang wrote:
>>> Two comment
to 25519. I saw the
default today and I'm not sure I like it, I would rather the user
specify ED25519 and ED448. The generic way EDDSA is used sometimes in
this code I feel makes it more confusing.
--Max
On Apr 2, 2020, at 9:21 AM, Anthony Scarpino
wrote:
I understand what the sp
ccessfully generate
* them. Otherwise, {@code null} is returned.
I'm afraid we'll have to return something here, maybe a mixture of a curve name
and fields inside EdDSAParameterSpec.
--Max
On Mar 31, 2020, at 12:25 PM, Anthony Scarpino
wrote:
On 3/30/20 8:52 PM, Anthony Scarpino wro
On 3/30/20 8:52 PM, Anthony Scarpino wrote:
On 3/30/20 7:54 PM, Weijun Wang wrote:
On Mar 31, 2020, at 10:50 AM, Anthony Scarpino
wrote:
On 3/30/20 11:52 AM, Anthony Scarpino wrote:
On 3/30/20 6:21 AM, Weijun Wang wrote:
I was playing with keytool with your patch and noticed
On 3/30/20 7:54 PM, Weijun Wang wrote:
On Mar 31, 2020, at 10:50 AM, Anthony Scarpino
wrote:
On 3/30/20 11:52 AM, Anthony Scarpino wrote:
On 3/30/20 6:21 AM, Weijun Wang wrote:
I was playing with keytool with your patch and noticed
sun.security.util.KeyUtil.getKeySize(Key) does not
On 3/30/20 11:52 AM, Anthony Scarpino wrote:
On 3/30/20 6:21 AM, Weijun Wang wrote:
I was playing with keytool with your patch and noticed
sun.security.util.KeyUtil.getKeySize(Key) does not support an
EdECKey. While we use curve name instead of key size in EC to
describe the parameters, the
ed to 2020
from another changeset.
Thanks, Max
On Mar 24, 2020, at 2:53 AM, Anthony Scarpino
wrote:
On 2/25/20 12:49 PM, Anthony Scarpino wrote:
Hi I need a code review for the EdDSA support in JEP 339. The
code builds on the existing java implemented constant time
classes used for XDH an
e it looks good to me.
--Jamil
On 3/25/2020 4:44 PM, Anthony Scarpino wrote:
Please review the proposed release note for JDK-8237219, the change to
disable the native curves in SunEC.
https://bugs.openjdk.java.net/browse/JDK-8241386
Thanks
Tony
Please review the proposed release note for JDK-8237219, the change to
disable the native curves in SunEC.
https://bugs.openjdk.java.net/browse/JDK-8241386
Thanks
Tony
On 2/25/20 12:49 PM, Anthony Scarpino wrote:
Hi
I need a code review for the EdDSA support in JEP 339. The code builds
on the existing java implemented constant time classes used for XDH and
the NIST curves. The change also adds classes to the public API to
support EdDSA operations.
All
On 3/19/20 12:23 PM, Sean Mullan wrote:
On 3/12/20 2:23 AM, Anthony Scarpino wrote:
Another webrev update with Max's recent comments.
https://cr.openjdk.java.net/~ascarpino/8237219/webrev.03
Also I still need a reviewer for the CSR.
For the CSR, I think the Compatibility Kind shou
lease
Note from.
Thanks,
Max
On Mar 18, 2020, at 11:52 PM, Anthony Scarpino
wrote:
Max,
Are you satisfied with this last update?
Thanks
Tony
On Mar 11, 2020, at 11:23 PM, Anthony Scarpino
wrote:
Another webrev update with Max's recent comments.
https://cr.openjdk.java.net/
Max,
Are you satisfied with this last update?
Thanks
Tony
> On Mar 11, 2020, at 11:23 PM, Anthony Scarpino
> wrote:
>
> Another webrev update with Max's recent comments.
> https://cr.openjdk.java.net/~ascarpino/8237219/webrev.03
>
> Also I still need a reviewe
Another webrev update with Max's recent comments.
https://cr.openjdk.java.net/~ascarpino/8237219/webrev.03
Also I still need a reviewer for the CSR.
thanks
Tony
On 3/2/20 4:40 PM, Anthony Scarpino wrote:
Hi
I need a review of the CSR and webrev for disabling by default the
native
many native specific changes in the tests because those same changes
will be removed when the native library is removed.
Otherwise fine to me.
Thanks,
Max
On Mar 7, 2020, at 4:04 AM, Anthony Scarpino
wrote:
Webrev is updated and the CSR is updated with a comment if the property is
fals
Webrev is updated and the CSR is updated with a comment if the property
is false.
https://cr.openjdk.java.net/~ascarpino/8237219/webrev.02
thanks
Tony
On 3/2/20 4:40 PM, Anthony Scarpino wrote:
Hi
I need a review of the CSR and webrev for disabling by default the
native SunEC curves from
inal.
ok
--Sean
On 2/25/20 3:49 PM, Anthony Scarpino wrote:
Hi
I need a code review for the EdDSA support in JEP 339. The code
builds on the existing java implemented constant time classes used for
XDH and the NIST curves. The change also adds classes to the public
API to support EdDSA
On 3/4/20 10:59 PM, Weijun Wang wrote:
On Mar 5, 2020, at 11:14 AM, Anthony Scarpino
wrote:
On 3/3/20 6:57 PM, Weijun Wang wrote:
We have 3 places checking for an algorithm now:
1. If CurveDB does not know a curve, you won't be able to create parameters.
Currently the Curve
erty with the 3
NIST curves instead of all the curves in CurveDB that are disabled`.
Thanks,
Max
On Mar 4, 2020, at 3:42 AM, Anthony Scarpino
wrote:
On 3/3/20 11:18 AM, Sean Mullan wrote:
On 3/3/20 1:42 PM, Anthony Scarpino wrote:
On 3/3/20 8:34 AM, Sean Mullan wrote:
Wouldn't it b
I think you are right for key generation that some addition to the
supported curve method will needed. With changing some of the
exceptions types I'm realizing that the native library was being used
more than I thought.
Tony
On 3/3/20 10:42 AM, Anthony Scarpino wrote:
Yes, the excep
On 3/3/20 11:18 AM, Sean Mullan wrote:
On 3/3/20 1:42 PM, Anthony Scarpino wrote:
On 3/3/20 8:34 AM, Sean Mullan wrote:
Wouldn't it be better to throw an Exception when you call
Signature.initSign/Verify() and KeyAgreement.init() rather than
waiting until you sign/verify or generateS
ion detail is a proper place. I think this belongs in
release notes, and maybe the provider doc.
--Sean
On 3/2/20 7:40 PM, Anthony Scarpino wrote:
Hi
I need a review of the CSR and webrev for disabling by default the
native SunEC curves from the API. With the recent verification
changes
et the property value in the privileged block so that it
works if security manager enabled?
Sean?
Per line 60, native is disabled if the property is set to value other
than "false'. It would be nice to describe the behavior in the CSR.
ok
Xuelei
On 3/2/2020 4:40 PM, Anthony Scarpino
java
isSupported()?
SecurityTools.java:
If native is disabled, will many tests fail? Is it possible to modify the
tests? This is a helper method used by many tests and I'd rather it uses the
default setting.
Thanks,
Max
On Mar 3, 2020, at 8:40 AM, Anthony Scarpino
wrote:
Hi
I need a rev
Hi
I need a review of the CSR and webrev for disabling by default the
native SunEC curves from the API. With the recent verification changes
in JDK-8237218, SunJCE is long dependent on the native code for
verifying the constant-time curves. This disabling can be undone with
setting a syste
Looks good
Tony
> On Feb 27, 2020, at 1:36 PM, Xuelei Fan wrote:
>
> Hi,
>
> Could I get the following update reviewed:
>
> http://cr.openjdk.java.net/~xuelei/8240193/webrev.00/
>
> In the JDK-8239264 update, the 'osxsecurity' library loading line was removed
> by by accident. And thus c
Hi
I need a code review for the EdDSA support in JEP 339. The code builds
on the existing java implemented constant time classes used for XDH and
the NIST curves. The change also adds classes to the public API to
support EdDSA operations.
All information about the JEP is located at:
JEP 33
I'm ok with this update
Tony
On 2/19/20 5:35 AM, Weijun Wang wrote:
New webrev at
http://cr.openjdk.java.net/~weijun/8237218/webrev.04/
Only test change. For each signature, modify it a little and check if verify
fails.
Thanks,
Max
On Feb 18, 2020, at 2:09 AM, Anthony Scarpino
The change looks fine. I'm trusting that the existing Known Answer
Tests are proving your verifySignedDigest() is correct.
You may want to comment in the code that your test depends on these
method names. I was going to suggest simplifying the all the
verifySigned*() methods until I saw the
On 1/14/20 11:33 AM, Bradford Wetmore wrote:
A simple one character fix, the modulus n should have been listed, not q.
https://bugs.openjdk.java.net/browse/JDK-8236957
http://cr.openjdk.java.net/~wetmore/8236957/webrev.00/
Thanks,
Brad
Looks good.
Tony
I need a review of the release notes for adding named curves to the
disabledAlgorithms properties.
https://bugs.openjdk.java.net/browse/JDK-8236730
thanks
Tony
FYI, there is no test included because the JCK test already exists.
On 1/7/20 11:39 AM, Anthony Scarpino wrote:
Hi,
I need a code review for a JCK issue where the AlgorithmConstraints spec
says that permits() with a null or empty primitives throws an
IllegalArgumentsException. The code
Hi,
I need a code review for a JCK issue where the AlgorithmConstraints spec
says that permits() with a null or empty primitives throws an
IllegalArgumentsException. The code currently allows no primitive and
continues with the check. Additionally, there was a needed change to
JSSE SeverHel
On 12/16/19 12:02 PM, ra...@web.de wrote:
Dear all,
in Java 13 the new System properties
jdk.tls.client.enableSessionTicketExtension and
jdk.tls.server.enableSessionTicketExtension were introduced. In TLS 1.2 and
prior these properties support stateful session resumption according to RFC
Updated webrev:
Includes java.security updates
Max's addition
Sean's comments
http://cr.openjdk.java.net/~ascarpino/8233228/webrev.02/
Tony
hms. To include this list
in any
to:
+# in the jdk.[tls|certpath|jar].disabledAlgorithms properties. To
include this list in any
2. We don't support the brainpoolP160r1, brainpoolP192r1,
brainpoolP224r1 curves, so these don't need to be listed.
3. +# properities. See the property for details.
T
I need a CSR review for the change with policy and property addition for
8233228.
https://bugs.openjdk.java.net/browse/JDK-8235540
Tony
I've updated the webrev to address many of the comments. In particular
adding checks when keys given directly. Also, the changing from
legacyEC hardcoded list to a security property jdk.disabled.namedCurves.
https://cr.openjdk.java.net/~ascarpino/8233228/webrev.01/
Tony
ov 20, 2019, at 3:44 AM, Anthony Scarpino
wrote:
I need a review of a disabled algorithms code change that allows EC curve names
to be disabled for all the disabledAlgorithm properties.
https://cr.openjdk.java.net/~ascarpino/8233228/webrev/
Tony
f
On 11/19/19 6:59 PM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
http://cr.openjdk.java.net/~xuelei/8233954/webrev.00/
For better performance, since JDK 11, the SunJSSE provider only check
the EC availability for EC AlgorithmParameters algorithm for supported
named g
I need a review of a disabled algorithms code change that allows EC
curve names to be disabled for all the disabledAlgorithm properties.
https://cr.openjdk.java.net/~ascarpino/8233228/webrev/
Tony
sing the code name is a little bit safer if someone
really use the impl name. However, just a little bit. I’m open to
use the doc name if we could get an agreement.
Xuelei
On Nov 5, 2019, at 4:32 PM, Anthony Scarpino
wrote:
I understand the desire to change this, but are we sure the doc
I understand the desire to change this, but are we sure the doc should be
changed instead of the property? I would tend to believe users code to the doc
and don’t notice it wasn’t working. Not reading the source code and code to
that implemented name. Otherwise I’d assume someone would have
On 10/30/19 1:13 PM, Valerie Peng wrote:
Anyone has a minute to review this trivial fix? The supported key size
info for the PKCS#11 PSS mechanism should be in bits. The current code
treat them as in bytes. This does not cause any existing regression test
failure because NSS has a very low valu
The Boolean.parseBoolean, that's in JDK 13, should work here too.
-Jaikiran
On 18/07/19 11:19 PM, Anthony Scarpino wrote:
This is a changeset for preventing Stateless Resumption from being
turned off when JDK-8227551 is merged from 13 into the mainline repo.
This is the way the gatekeepers a
A mistaken file got added into my push of 8227551, which did not show up
in the webrev. I'm not sure why that happened. Nevertheless, I need a
review to have it removed
http://cr.openjdk.java.net/~ascarpino/8228399/webrev/
thanks
Tony
This is a changeset for preventing Stateless Resumption from being
turned off when JDK-8227551 is merged from 13 into the mainline repo.
This is the way the gatekeepers asked me to do it as oppose to
withholding 8227551 from the mainline merge.
http://cr.openjdk.java.net/~ascarpino/8228396/web
On 7/17/19 3:40 PM, Rajan Halade wrote:
Please review this problemList update to add earlier ignored manual
regression tests. These tests require special setup/hardware and few
have outdated JDK and need update.
webrev: http://cr.openjdk.java.net/~rhalade/8228337/webrev.00/
Thanks,
Rajan
L
y,
Just a minor comment.
242 if (st.compareToIgnoreCase("true") == 0) {
243 statelessSession = true;
244 }
Could it simply use the below statement?
statelessSession = st.equalsIgnoreCase("true");
Best regards,
John Jiang
On 2019/7/17 11:
Please review the change to set stateless session resumption off default
http://cr.openjdk.java.net/~ascarpino/8227551/webrev/
Thanks
Tony
433 public byte[] produce(PostHandshakeContext hc) ...
I did not get the point to use three methods here. Read more inlines,
please.
I had decided to separate them because I want multiple instanceOf
checks, but will merge them.
On 7/15/2019 4:04 PM, Anthony Scarpino wrote:
I've up
On 7/8/19 10:00 AM, Xuelei Fan wrote:
On 7/8/2019 9:06 AM, Anthony Scarpino wrote:
On 7/8/19 8:30 AM, Xuelei Fan wrote:
Hi,
A couple of comments.
In the release note, "For TLS 1.3, stateless tickets use the existing
PSK resumption extension in RFC 8446[2]. TLS 1.3 will revert t
after boundValues have changed.
There is no change to invalidate() as these is not enough time to
address that.
Tony
On 7/7/19 9:14 PM, Anthony Scarpino wrote:
On 7/4/19 10:14 PM, Xuelei Fan wrote:
SSLSessionImpl.java
---
526 boolean checkSessionTicket(HandshakeContext hc)
section to the
"Solution" section, as it is about the implementation details. Not a
big concern of mine. You can leave it as-is. I added myself as the
reviewer.
Thanks,
Xuelei
On 7/10/2019 7:57 AM, Anthony Scarpino wrote:
Hi
Can I have a CSR review of this very simple change t
Hi
Can I have a CSR review of this very simple change to turn stateless
session resumption off by default
https://bugs.openjdk.java.net/browse/JDK-8227530
Tony
On 7/8/19 10:00 AM, Xuelei Fan wrote:
On 7/8/2019 9:06 AM, Anthony Scarpino wrote:
On 7/8/19 8:30 AM, Xuelei Fan wrote:
Hi,
A couple of comments.
In the release note, "For TLS 1.3, stateless tickets use the existing
PSK resumption extension in RFC 8446[2]. TLS 1.3 will revert t
o say what the default values of the
2 properties are, just to make it clear how it is enabled by default.
Looks good otherwise.
--Sean
On 7/2/19 5:43 PM, Anthony Scarpino wrote:
Hi,
I needs a release note review of the Stateless Resumption work
https://bugs.openjdk.java.net/browse/JDK-8227105
thanks
Tony
Encryption failed", e);
I didn't noticed logger accepted exceptions.
On 7/2/2019 10:35 AM, Anthony Scarpino wrote:
Hi,
I need a code review on some updates to the stateless resumption.
1) Changing peerSupportedSignAlgs from a String[] to Collection[]
2) Additional items added to t
Hi,
I needs a release note review of the Stateless Resumption work
https://bugs.openjdk.java.net/browse/JDK-8227105
thanks
Tony
Hi,
I need a code review on some updates to the stateless resumption.
1) Changing peerSupportedSignAlgs from a String[] to Collection[]
2) Additional items added to the stateless ticket
3) Not provide a stateless ticket when the masterkey is not accessible
(FIPS) or when boundValues are used
On 7/1/19 7:23 PM, Jaikiran Pai wrote:
Hello Tony,
On 01/07/19 10:28 PM, Anthony Scarpino wrote:
Hi,
You are correct this behavior is a result of stateless resumption.
The stateless servers does not keep session state information and is
currently opt-out.
Thank you for looking into this and
Hi,
You are correct this behavior is a result of stateless resumption. The
stateless servers does not keep session state information and is
currently opt-out. The system property
'jdk.tls.server.enableSessionTicketExtension' set to false will return
the server to stateful. The client side
Hi
Session ids can change due to the way the way stateless operates in the RFCs,
particularly if a client doesn’t provide a session Id during resumption. I can
take a look at your test and let you know what I find.
Thanks
Tony
> On Jun 30, 2019, at 10:38 PM, Jaikiran Pai wrote:
>
> It loo
COPYING is the correct name for the file? The bug says COPY. I just wanted to
make sure. Otherwise it looks fine.
Tony
> On Jun 24, 2019, at 4:58 PM, Valerie Peng wrote:
>
> Hi,
>
> Anyone has a few minutes to spare for this review?
>
> Just some textual updates, no impact on behaviors.
On 6/24/19 6:50 AM, Sean Mullan wrote:
Please review this docs-only fix to link to the specific sections of the
standard algorithm names specification for the KeyManagerFactory and
TrustManagerFactory APIs:
webrev: http://cr.openjdk.java.net/~mullan/webrevs/8180005/webrev.00/
bug: https:
On 6/19/19 5:02 PM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
http://cr.openjdk.java.net/~xuelei/8225766/webrev.01/
For TLS 1.2 and prior versions, the public key of a EC cert MUST use a
curve and point format supported by the client. But in TLS 1.3,
signature algo
On 6/6/19 9:18 AM, Xuelei Fan wrote:
Continue for the SessionTicketExtension.java.
On 6/3/2019 5:42 PM, Anthony Scarpino wrote:
http://cr.openjdk.java.net/~ascarpino/stateless/webrev.02
SessionTicketExtension.java (continue):
---
368 if
On 6/5/19 9:58 AM, Xuelei Fan wrote:
Continue for the SessionTicketExtension.java.
On 6/3/2019 5:42 PM, Anthony Scarpino wrote:
http://cr.openjdk.java.net/~ascarpino/stateless/webrev.02
SessionTicketExtension.java (continue):
---
231
On 6/5/19 7:30 PM, Xuelei Fan wrote:
On 6/5/2019 7:21 PM, Anthony Scarpino wrote:
On Jun 5, 2019, at 5:37 PM, Xuelei Fan wrote:
On 6/5/2019 4:57 PM, Jamil Nimeh wrote:
I think what it's saying is that what was explicitly called out in
4507 (where there is both the extension_data l
> On Jun 5, 2019, at 5:37 PM, Xuelei Fan wrote:
>
>
>
>> On 6/5/2019 4:57 PM, Jamil Nimeh wrote:
>> I think what it's saying is that what was explicitly called out in 4507
>> (where there is both the extension_data length bytes AND the opaque vector
>> length) is not how deployed implement
, Anthony Scarpino wrote:
http://cr.openjdk.java.net/~ascarpino/stateless/webrev.02
SessionTicketExtension.java:
81 private static int currentKey = new SecureRandom().nextInt();
When I read the code, the first question came to me was: if a integer is
strong enough
On 6/4/19 10:02 AM, Xuelei Fan wrote:
On 6/4/2019 9:46 AM, Anthony Scarpino wrote:
125 if (secondSession.getCreationTime() > secondStartTime &&
126 !clientCache && !serverServerless) {
127 throw new RuntimeException("
On 6/4/19 10:02 AM, Xuelei Fan wrote:
On 6/4/2019 9:46 AM, Anthony Scarpino wrote:
125 if (secondSession.getCreationTime() > secondStartTime &&
126 !clientCache && !serverServerless) {
127 throw new RuntimeException("
eless mode sends no session id, as the spec
allows. So the session id has no more value.
Tony
Best regards,
John Jiang
On 2019/6/4 08:42, Anthony Scarpino wrote:
I believe I updated all comments in the latest webrev.
http://cr.openjdk.java.net/~ascarpino/stateless/webrev.02
Tony
On 5/16/1
I believe I updated all comments in the latest webrev.
http://cr.openjdk.java.net/~ascarpino/stateless/webrev.02
Tony
On 5/16/19 2:30 PM, Anthony Scarpino wrote:
I'm asking for a review of this rather large change to add support
stateless tickets in the TLS 1.3 5077 RFC.
An updated webrev has been added for the previous comments:
http://cr.openjdk.java.net/~ascarpino/stateless/webrev.01
Tony
On 5/16/19 2:30 PM, Anthony Scarpino wrote:
I'm asking for a review of this rather large change to add support
stateless tickets in the TLS 1.3 5077 RFC.
The CSR has been updated with what I believe address the mentioned issues.
Tony
On 5/21/19 4:24 PM, Anthony Scarpino wrote:
Hi All,
Please review the CSR for the stateless Server Side
https://bugs.openjdk.java.net/browse/JDK-8223922
thanks
Tony
tation of fundamental APIs.
>
> Xuelei
>
> On 5/24/2019 11:52 AM, Anthony Scarpino wrote:
>>> I would like to avoid to create thread in the fundamental API
>>> implementation if possible. As the thread (KeyState.run()) is for invalid
>>> key cleanup only, the
s discuss these issues firstly before we moving on with more code
review.
Hope it helps.
Thanks,
Xuelei
On 5/21/2019 5:35 PM, Anthony Scarpino wrote:
Hi all,
I’ve updated in-place some recent changes due to some additional testing
Tony
On May 16, 2019, at 2:30 PM, Anthony Scarpino
wrote:
on timeout. I don't feel that
is often enough.
-
Thanks,
Xuelei
On 5/21/2019 4:24 PM, Anthony Scarpino wrote:
Hi All,
Please review the CSR for the stateless Server Side
https://bugs.openjdk.java.net/browse/JDK-8223922
thanks
Tony
On 5/23/19 11:16 AM, Sean Mullan wrote:
On 5/21/19 7:24 PM, Anthony Scarpino wrote:
Hi All,
Please review the CSR for the stateless Server Side
https://bugs.openjdk.java.net/browse/JDK-8223922
Some initial comments/questions:
I think the scope should be "JDK" since you are addi
I stayed away from a boolean value in case some day another option came
around. "stateless" I don't see an often used option, but maybe someone
wants to keep no cache for memory reasons. I didn't want to eliminate
that options by using a boolean value.
As far as defaults. Today it would be
javax.net.ssl.sessionTicketExtension and javax.net.ssl.sessionCacheServer.
Best regards,
John Jiang
Ah.. thanks.. Apparently the rename by the IDE didn't rename
everything.. strange..
Tony
On 2019/5/22 08:35, Anthony Scarpino wrote:
Hi all,
I’ve updated in-place some recent changes due to
Hi all,
I’ve updated in-place some recent changes due to some additional testing
Tony
> On May 16, 2019, at 2:30 PM, Anthony Scarpino
> wrote:
>
> I'm asking for a review of this rather large change to add support stateless
> tickets in the TLS 1
Hi All,
Please review the CSR for the stateless Server Side
https://bugs.openjdk.java.net/browse/JDK-8223922
thanks
Tony
I'm asking for a review of this rather large change to add support
stateless tickets in the TLS 1.3 5077 RFC.
https://bugs.openjdk.java.net/browse/JDK-8211018
http://cr.openjdk.java.net/~ascarpino/stateless/webrev.00
thanks
Tony
Looks good
> On Mar 11, 2019, at 4:45 PM, Valerie Peng wrote:
>
> Can someone help reviewing this? Just a javadoc one-line fix.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8220258
>
> Webrev: http://cr.openjdk.java.net/~valeriep/8220258/webrev.00/
>
> Thanks,
>
> Valerie
>
This change looks fine.
Tony
On 3/7/19 4:58 PM, Valerie Peng wrote:
Anyone has time to help review this fix? According to the bug report,
some vendors require the keytype attribute to match the encryption
algorithm. So, the change is to match the key type based on the
algorithm specified. T
ew byte[inLen])
new webrev:
http://cr.openjdk.java.net/~ascarpino/8220165/webrev.01/
Thanks,
Valerie
On 3/6/2019 3:04 PM, Anthony Scarpino wrote:
Hi
Can I get a review of a simple fix to the previous GCM change that got
the lengths wrong on large data sizes. I thought I covered this in my
original testin
Hi
Can I get a review of a simple fix to the previous GCM change that got
the lengths wrong on large data sizes. I thought I covered this in my
original testing, but I guess not. So with this I created a test to
check larger data sizes and different byte lengths
http://cr.openjdk.java.net/
I understand. The change looks fine.
Tony
On 2/19/19 10:32 PM, Xuelei Fan wrote:
On Feb 19, 2019, at 10:06 PM, Anthony Scarpino
wrote:
On 2/19/19 9:38 PM, Xuelei Fan wrote:
Hi Tony or Jamil,
Would you please review the following update:
http://cr.openjdk.java.net/~xuelei/8219389
On 2/19/19 9:38 PM, Xuelei Fan wrote:
Hi Tony or Jamil,
Would you please review the following update:
http://cr.openjdk.java.net/~xuelei/8219389/webrev.00/
BufferUnderflowException might be thrown if the record format does not
confirm to the formal protocol syntax. The original bug was rep
Hi,
I need a review of this simple change that throws the wrong exception
http://cr.openjdk.java.net/~ascarpino/8215790/webrev/
Tony
On 2/7/19 2:09 PM, Valerie Peng wrote:
Hi,
Anyone can help review this fix? More detailed info on cause and fixes
can be found in the bug report and fix has been verified through mach5 run.
Bug: https://bugs.openjdk.java.net/browse/JDK-8216597
Webrev: http://cr.openjdk.java.net/~valeriep/821
d add ", otherwise, copy input data into ibuffer".
You'll probably need to add noreg-perf label.
Thanks,
Valerie
On 2/5/2019 3:52 PM, Anthony Scarpino wrote:
I need a review of this change which is to help the AES/GCM intrinsic
activate on large data sizes. It's not th
301 - 400 of 701 matches
Mail list logo
