Looks fine
Tony
On 1/2/19 12:42 PM, Sean Mullan wrote:
Please review this change to the Java Security Standard Algorithm Names
specification [1] to clarify that standard names that are defined in
later versions of SE are also supported in prior versions, as long as
the applicable Security
On 12/17/18 5:26 PM, Xue-Lei Fan wrote:
On 12/17/2018 1:17 PM, Anthony Scarpino wrote:
It looks like in TransportContext.java:68, you had a mistype that
added "fa" to the end of a comment.
Oops, I will update it.
Also in fatal():267, did you plan to return the exceptio
It looks like in TransportContext.java:68, you had a mistype that added
"fa" to the end of a comment.
Also in fatal():267, did you plan to return the exception and have the
calling method throw the exception? As is, the exception is never
return and fatal() continues to throw the exceptions.
Just the complete the thread. Says "fatal() throws exception" is fine.
If this all only trying to make the compiler happy, you could just have
one "return null" at the bottom of the method. It is not necessary to
put a return after each fatal(). I will admit it could be less readable.
Or
Other than my nit about the “make the compiler happy”, this all looks fine.
For KeyUpdate, shouldn’t it never be null given the suite and protocol are
already known good? I have not problem with the check to be cautious even if
it should never happen.
Tony
> On Dec 14, 2018, at 9:00 AM,
://cr.openjdk.java.net/~svkamath/ghash/webrev02/
Thank you very much for your time and assistance. Please let me know if you
have any questions.
Regards,
Smita
-Original Message-
From: Anthony Scarpino [mailto:anthony.scarp...@oracle.com]
Sent: Wednesday, December 5, 2018 10:56 AM
To: Kamath
On 11/30/18 12:01 PM, Adam Petcher wrote:
JBS: https://bugs.openjdk.java.net/browse/JDK-8208698
webrev: http://cr.openjdk.java.net/~apetcher/8208698/webrev.00/
This is a re-implementation of ECDH and ECDSA that is designed to be
resilient against side-channel attacks. The implementation only
attached.
JBS link: https://bugs.openjdk.java.net/browse/JDK-8214074
Webrev link: http://cr.openjdk.java.net/~svkamath/ghash/webrev02/
Thank you very much for your time and assistance. Please let me know if you
have any questions.
Regards,
Smita
-Original Message-
From: Anthony Scarpino
it
is roughly equal. At 16k is the best performance increase from 60k
ops/sec to 130 ops/sec
Are the AVX instructions slower to setup and therefore affect smaller
data sizes? Or maybe the larger array allocation in GHASH.java?
Tony
On 11/29/18 12:08 PM, Anthony Scarpino wrote:
[removed core
Hi,
I need a code review for the TLS 1.2 check being backwards for
HandshakeHash, which showed up with a clonable MessageDigest object.
Since TLS 1.3 does not use the same scheme as 1.2, I removed the
unnecessary code.
http://cr.openjdk.java.net/~ascarpino/8214098/webrev/
Tony
of curiosity
how do the times look like when you switch NI off?
Greetings
Bernd
--
http://bernd.eckenfels.net
*Von: *Anthony Scarpino <mailto:anthony.scarp...@oracle.com>
*Gesendet: *Montag, 3. Dezember 2018 21:13
*An: *Kasper Janssens <mailto:kasper.janss...@wdc.com>;
Hi,
That is how I read it, but when I've done the test it's closer to 55%.
But openssl speed and jmh are not comparable. Openssl is only running
through it's algorithm, while jmh is running through the VM and java
byte code. jmh has to do more work outside of pure crypto ops than openssl.
.
Bug link: https://bugs.openjdk.java.net/browse/JDK-8214074
Webrev link: http://cr.openjdk.java.net/~svkamath/ghash/webrev01/
Thanks and Regards,
Smita
-Original Message-
From: Anthony Scarpino [mailto:anthony.scarp...@oracle.com]
Sent: Tuesday, November 20, 2018 2:05 PM
To: Kamath, Smita
On 11/26/18 4:14 PM, Xue-Lei Fan wrote:
Hi,
Please review this code cleanup in SSLCipher.java:
http://cr.openjdk.java.net/~xuelei/8214321/webrev.00/
The code should be fine as readCipherGenerators.length and
writeCipherGenerators.length are the same value in the implementation.
However,
I agree with Adam that this is more of a tuning issue and not a problem
with the crypto. Sending multiple updates is a hack.
I've been aware of this bug for a while and I do not understand why this
is a significant problem. The stackoverflow comments say it takes 50
seconds to trigger the
Hi,
I'd like to get a code review of this simple change. It's a simple
check to make sure the hostname variable is not null and throw a proper
exception.
http://cr.openjdk.java.net/~ascarpino/8211339/webrev.00/
Tony
Looks good to me
Tony
On 10/29/2018 10:41 AM, Xuelei Fan wrote:
Hi,
Please review the update:
http://cr.openjdk.java.net/~xuelei/8212738/webrev.00/
The signature algorithm name should be ""ecdsa_secp521r1_sha512",
instead of "ecdsa_secp512r1_sha512".
No new regression test. Trivial
I’d like a review of this fix for when DSA is the only key available. It’s
debatable how realistic this situation is, but it is a regression and key tool
uses dsa by default.
The fix is to remove tls1.3 from the default protocols. The placement of the
code change is to minimize the keymanager
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
don't know what benefit it brings to a user to remove the default. Except
from forcing DSA users to add a -keyalg option, RSA and EC users will not gain
anything.
--Max
On Oct 11, 2018, at 5:05 AM, Anthony Scarpino
wrote:
On 10/10/2018 07:42 AM, Weijun Wang wrote:
On Oct 10, 2018, at 7:59 PM
On 10/10/2018 07:42 AM, Weijun Wang wrote:
On Oct 10, 2018, at 7:59 PM, Sean Mullan wrote:
There is really no other reason other than DSA keys have been the default
keypairs generated by keytool for a long time, so there are some compatibility
issues we would have to think through before
On 10/01/2018 06: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 :
Thanks.. I updated the copyright..
Tony
On 08/29/2018 07:02 AM, Xuelei Fan wrote:
Looks fine to me. Please update the copyright years as well.
Thanks,
Xuelei
On 8/28/2018 9:47 PM, Anthony Scarpino wrote:
I need a review of this fix. Simple change to throw an
UnsupportedOperationException
Adam,
I tend to agree with Mike that disallowing import/export of keys using
BigInteger is not the value of a branchless implementation. As you point out
in the JEP the provider is greatly hindered by this design choice. I feel it
would be better to implementing the BigInteger parts and have
Looks fine
> On Sep 5, 2018, at 11:01 AM, Xuelei Fan wrote:
>
> Hi,
>
> Please review:
>http://cr.openjdk.java.net/~xuelei/8210334/webrev.00/
>
> Simple update, no new regression test.
>
> Thanks,
> Xuelei
ded to wait and check for the supported_versions extension if it
> presents. As may make the workaround a lot complicated. I would prefer to a
> simple change for now.
>
> Thanks,
> Xuelei
>
>> On 8/26/2018 2:35 PM, Anthony Scarpino wrote:
>> The change looks fine but I h
The change looks fine but I have a question about restricting it.
This sounds like a problem with servers using 1.2 or before, does it make sense
to throw an error for 1.3? I don’t like allowing buggy implementation to
continue because we will never be able to undo this workaround. It would
On 08/20/2018 01:33 PM, Bradford Wetmore wrote:
Hi Xuelei,
Please review this P1 bug blocking JDK11 RC:
https://bugs.openjdk.java.net/browse/JDK-8207317
http://cr.openjdk.java.net/~wetmore/8207317/webrev.00/
Proposed putback comment is inlined in the webrev.
Bug analysis/fix
Looks fine.
Tony
> On Aug 17, 2018, at 8:45 AM, Jamil Nimeh wrote:
>
> Hello all,
>
> This is a simple doc-only one-liner that fixes the sample code in SSLEngine
> to use the correct ByteBuffer in the capacity size check.
>
> webrev:
On 08/14/2018 11:27 AM, Sean Mullan wrote:
On 8/14/18 1:56 PM, Anthony Scarpino wrote:
On 08/13/2018 12:42 PM, Sean Mullan wrote:
On 8/10/18 3:49 PM, Anthony Scarpino wrote:
On 8/9/2018 4:25 AM, Sean Mullan wrote:
On 8/8/18 5:29 PM, Xuelei Fan wrote:
The "Default" algorit
On 08/13/2018 12:42 PM, Sean Mullan wrote:
On 8/10/18 3:49 PM, Anthony Scarpino wrote:
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,
out where SSL[Server]SocketFactory.getDefault()
uses a ssl.SocketFactory.provider property set to SunJSSE? If so, can
see that as a code review comment, but it seems very obscure for the CSR.
Xuelei
--Sean
Xuelei
On 8/8/2018 1:28 PM, Sean Mullan wrote:
On 8/8/18 1:58 PM, Anthony Scarpino wrote:
I don't se
should be Java API since we are changing the
behavior of an implementation of a standard API. I asked Joe Darcy this
question yesterday, and he agreed.
I thought about API, but since it was a behavior change, API didn't
sound completely correct. But that's fine if that's what he wants.
--Sea
this
scenario is not supported.
I think the Interface Kind should be Java API since we are changing the
behavior of an implementation of a standard API. I asked Joe Darcy this
question yesterday, and he agreed.
--Sean
Thanks,
Xuelei
On 8/7/2018 4:14 PM, Anthony Scarpino wrote:
Hi Xuelei,
n Solution section, "Throwing a UnsupportedOperationException when
getting a socket from the SSLServerSocketFactory or SSLSocketFactory for
DTLS." I guess you meant, throwing a UOE when calling
SSLContext.getServerSocketFactory() and SSLContext.getSocketFactory()?
Thanks,
Xuelei
On 8/7/20
I need a review of a CSR for SSLSocket should throw an exception when
configuring DTLS. We are targeting this for 12 right now.
https://bugs.openjdk.java.net/browse/JDK-8209031
thanks
Tony
maintenance also.
>
> webrev updated. Hope we're nearly ready to push now.
>
> http://cr.openjdk.java.net/~coffeys/webrev.8207775.v4/webrev/
>
> regards,
> Sean.
>
>> On 01/08/2018 18:41, Anthony Scarpino wrote:
>> That looks fine to me.
>>
>> Tony
&
) 0x00);
}
return copy;
==
Any other reviews/comments from folks before I submit final build/test &
webrev ?
Regards,
Sean.
On 01/08/18 15:55, Anthony Scarpino wrote:
My only comment is if it makes sense to have the change at 676 to also
only null
My only comment is if it makes sense to have the change at 676 to also
only null out on decrypt?
Otherwise I'm fine with the changes
Tony
On 07/31/2018 02:04 AM, Seán Coffey wrote:
Thanks for review Tony. Comments inline..
On 27/07/18 21:02, Anthony Scarpino wrote:
If we are going
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.
.
On 26/07/18 17:42, Anthony Scarpino wrote:
On 07/26/2018 07:36 AM, Seán Coffey wrote:
https://bugs.openjdk.java.net/browse/JDK-8207775
Simple enough fix to null out some internal buffers once they're no
longer required.
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8207775/webrev
On 07/26/2018 07:36 AM, Seán Coffey wrote:
https://bugs.openjdk.java.net/browse/JDK-8207775
Simple enough fix to null out some internal buffers once they're no
longer required.
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8207775/webrev/
regards,
Sean.
that looks fine..
Tony
Below is a simple fix that the test intermittently fails on.
The problem is believed to be that the read thread sees a close_notify
which cause the read thread to do a write operation. That write
operation conflicts with the on-going write thread usage of the Cipher
object doing the
I need a review of some integer check cleanups.
http://cr.openjdk.java.net/~ascarpino/int/webrev/
thanks
Tony
/9/2018 3:14 PM, Anthony Scarpino wrote:
On 07/03/2018 02:03 PM, Valerie Peng wrote:
Hi Tony,
Would you have time to review this? Instead of doing the bounds check
per block, the changes move the bounds check up one level.
Bug: https://bugs.openjdk.java.net/browse/JDK-8179098
Webrev: http
On 07/03/2018 02:03 PM, Valerie Peng wrote:
Hi Tony,
Would you have time to review this? Instead of doing the bounds check
per block, the changes move the bounds check up one level.
Bug: https://bugs.openjdk.java.net/browse/JDK-8179098
Webrev:
The change looks fine to me
Tony
On 06/25/2018 05:49 AM, Adam Petcher wrote:
It would be nice to get this X25519/X448 enhancement into JDK 11. If
anyone has some time to review this in the next day or so, I would
appreciate it.
On 5/15/2018 2:42 PM, Adam Petcher wrote:
Webrev:
Read side key limit change at:
http://hg.openjdk.java.net/jdk/sandbox/rev/6210466cf1ac
Tony
On 06/15/2018 06:53 AM, Xuelei Fan wrote:
SSLCipher.java
--
In the implementation, the key usage impacts the write side only. I
think the read side should also limit the key usage.
I remember it being discussed many many months ago we at first planned
to do the read side, but
DTLSRecord.java & SSLRecord.java
The two variables below not used. They weren't used before the code
restructuring either.
maxDataSizeMinusOneByteRecord
maxAlertRecordSize
Tony
On 06/13/2018 02:21 PM, Anthony Scarpino wrote:
I found some commented out code that I will re
I found some commented out code that I will remove in
CertificateMessage, lines 1300-1319 on my next push unless this should
be uncommented.
In SupportedVersionsExtension.java, HRRSupportedVersionsProducer and
HRRSupportedVersionReproducer could be merged with a boolean in the
constructor to
On 06/08/2018 07:55 PM, Bradford Wetmore wrote:
[...]
TransportContext.java
-
90: Any chance of combining these 3 constructors into 1? Almost
identical duplicate code here.
I have some code to change this already.
Tony
On 06/06/2018 02:16 PM, Valerie Peng wrote:
Hi Tony,
Can you please help reviewing this fix? The original impl uses buffering
for both input and output and is broken in several places. I ended up
re-writing most of them. The buffering is done only on input. The new
regression test covers all
Xuelei,
I'll push updates if you're are ok with the changes.
Tony
---
ServerHandshakeContext.java
ServerHello.java
- spelling nits only
HandshakeContext.java
- Could getActiveCipherSuites() compile a list of cipher suites once per
ProtocolVersion instead doing it for each instance of
I can make the below changes if they are accepted.
Tony
--
InputRecord.java
- Optimize Imports
- fragmentSize appears not to be used. It is constructed,
it can be set by changeFragmentSize. MaxFragExtension even calls these
methods, but no where can I find that uses the fragmentSize. It
On 06/04/2018 08:50 AM, Xuelei Fan wrote:
On 6/4/2018 8:36 AM, Anthony Scarpino wrote:
Here are questions I have about the code before I or someone makes a
change:
ChangeCipherSpec.java
- 69 & 200: Given this is legacy data on older version of TLS, is the
exception better wo
Here are questions I have about the code before I or someone makes a change:
ChangeCipherSpec.java
- 69 & 200: Given this is legacy data on older version of TLS, is the
exception better worded "Not supported"? "yet" implies future additions.
- ChangeCipherSpec is removed in 1.3, why is there
Xuelei,
From looking at your code change at 151 and 219 when a single
KeyUpdate handshake is sent, it appears you are changing all 4 keys,
both send and receive from the client and send and receive from the server.
It was my interpretation of the spec that only the send and receive keys
The property can get loaded very early and it can be hard to get ahead of it.
The only suggestion I can think of is your option 1 isn't doing what you
expect. To append to the existing java.security properties, you use one equals,
“=“. To override you use 2, “==‘. So you may want something
I'm fine with 1 or 2. Maybe leaning more toward 2 given what Xuelei
said about the RFCs.
Tony
On 04/27/2018 04:41 PM, Valerie Peng wrote:
I'd also strongly prefer to pick one as standard name for RSA PSS
signature and use it consistently.
Here are the possible choices for RSA PSS
On 02/15/2018 04:40 PM, Valerie Peng wrote:
Anyone can help review this trivial fix? It'll just take a minute or so.
Essentially, the fix is to re-throw with InvalidKeyException when the
casting failed.
Bug: https://bugs.openjdk.java.net/browse/JDK-8197441
Webrev:
On 12/05/2017 06:27 AM, Seán Coffey wrote:
Looking to improve the stacktrace output made when debug mode is enabled
for java.security and sun.security classes. In the past, some of these
have led to confusion for end users. Best to add some context when we're
printing stacktrace for
On 11/27/2017 11:16 AM, Jamil Nimeh wrote:
I thought that we had ditched setParameter in favor of putting these
parameters in getInstance. IIRC we were headed toward an algorithm
naming convention of /, plus APS in the getInstance (which may
be null (and might be for most KDFs that we start
On 08/31/2017 02:19 PM, Ivan Gerasimov wrote:
On 8/31/17 1:44 PM, Anthony Scarpino wrote:
On 08/31/2017 01:10 PM, Ivan Gerasimov wrote:
Hello!
Currently, when reading the pkcs11 config file, the default encoding
is assumed.
This causes errors when the encoding is set to UTF-16.
Would
On 08/31/2017 01:10 PM, Ivan Gerasimov wrote:
Hello!
Currently, when reading the pkcs11 config file, the default encoding is
assumed.
This causes errors when the encoding is set to UTF-16.
Would you please help review the trivial fix?
Bug: https://bugs.openjdk.java.net/browse/JDK-8187023
> On Jul 14, 2017, at 12:01 PM, Langer, Christoph <christoph.lan...@sap.com>
> wrote:
>
> Hi,
>
>> From: Anthony Scarpino [mailto:anthony.scarp...@oracle.com]
>
>> I'm working on a test so we avoid this in the future.
>
> OK, so, shall I submit the f
On 7/14/17 12:56 PM, Anthony Scarpino wrote:
On 07/14/2017 08:37 AM, Langer, Christoph wrote:
Hi,
after the discussion in thread
http://mail.openjdk.java.net/pipermail/security-dev/2017-July/016068.html,
please review my proposed change:
Bug: https://bugs.openjdk.java.net/browse/JDK-8184673
On 07/14/2017 08:37 AM, Langer, Christoph wrote:
Hi,
after the discussion in thread
http://mail.openjdk.java.net/pipermail/security-dev/2017-July/016068.html,
please review my proposed change:
Bug: https://bugs.openjdk.java.net/browse/JDK-8184673
Change:
*diff -r 76fca9438ee9 -r
On 07/12/2017 07:45 AM, Sean Mullan wrote:
On 7/11/17 3:10 PM, Langer, Christoph wrote:
In any case, from what you are saying, I take that I can safely patch
our JDK distribution with this change without doing a bad thing to
security in general, wouldn't you agree?
Yes, I agree.
Also,
On 07/13/2017 11:26 AM, Anthony Scarpino wrote:
On 07/12/2017 11:59 PM, Langer, Christoph wrote:
I then suggest to also revert JDK10 and 9 to use
X509CertImpl.getSigAlgName() forthe time being until some better
check to go for the encoded AlgorithmId. Would you be fine with
that
Looking back
On 07/12/2017 11:59 PM, Langer, Christoph wrote:
Hi Sean,
So, I guess I would be fine if this could at least be changed for JDKs <= 8 for
compatibility reasons. I can understand if for JDK >= 9 we say this is a new
release and the standard algorithm names shall be enforced. Wouldn't that
be a
On 06/06/2017 04:04 PM, Xuelei Fan wrote:
New webrev:
http://cr.openjdk.java.net/~xuelei/8178728/webrev.01/
On 6/6/2017 1:45 PM, Anthony Scarpino wrote:
On 06/05/2017 02:15 PM, Xuelei Fan wrote:
Hi,
Please review the JDK 10 update:
http://cr.openjdk.java.net/~xuelei/8178728/webrev.00
I think your code looks good.
You should check the CertPathValidator tests, I think one of them might
fail after this change.
Tony
On 05/10/2017 04:36 PM, Weijun Wang wrote:
Ping again.
On 04/12/2017 11:52 PM, Weijun Wang wrote:
Please take a review at
I need a review for adding the verbose option to debugging so that the
output is not overwhelmed with unnecessary info.
http://cr.openjdk.java.net/~ascarpino/8176457/webrev/
Tony
On 04/10/2017 12:18 PM, Sean Mullan wrote:
On 4/6/17 4:39 PM, Anthony Scarpino wrote:
I'd like to get a review for this performance change to use the existing
CounterMode parallelized intrinsic instead of GCTR's own version. The
two classes were nearly identical except for the doFinal() method
On 04/10/2017 10:27 AM, Paul Sandoz wrote:
On 7 Apr 2017, at 12:47, Anthony Scarpino <anthony.scarp...@oracle.com> wrote:
On 04/07/2017 06:58 AM, Chris Hegarty wrote:
On 06/04/17 21:39, Anthony Scarpino wrote:
I'd like to get a review for this performance change to use the ex
On 04/07/2017 06:58 AM, Chris Hegarty wrote:
On 06/04/17 21:39, Anthony Scarpino wrote:
I'd like to get a review for this performance change to use the existing
CounterMode parallelized intrinsic instead of GCTR's own version. The
two classes were nearly identical except for the doFinal
I'd like to get a review for this performance change to use the existing
CounterMode parallelized intrinsic instead of GCTR's own version. The
two classes were nearly identical except for the doFinal() method which
doesn't belong in CounterMode.java.
I could have been more aggressive with
On 03/30/2017 07:41 AM, John Jiang wrote:
Hi,
This patch includes a set of new test cases for JEP 288.
The cases just focus on the usage constraints TLSSever and TLSClient
with TLS communication.
Issue: https://bugs.openjdk.java.net/browse/JDK-8165367
Webrev:
I'd agree with Sean, "weak" implies anything risk, the weakness isn't
necessarily key length related.
Tony
On 03/24/2017 11:56 AM, Sean Mullan wrote:
On 3/24/17 7:01 AM, Weijun Wang wrote:
I'll use "short key".
I prefer the term "weak" which implies it is a risk. We already use that
term
Hi Sean,
I updated the webrev with your recent change. One you ok this, I'll
request approval for backport.
http://cr.openjdk.java.net/~ascarpino/8176536/webrev.01/
thanks
Tony
On 03/17/2017 01:25 PM, Anthony Scarpino wrote:
Oh yeah. I had forgot to resync to get your change. Thanks
backport:
> https://bugs.openjdk.java.net/browse/JDK-8176503
>
> --Sean
>
>> On 3/16/17 1:04 AM, Anthony Scarpino wrote:
>> Hi,
>>
>> I need a review of this large backport of the weak algorithm checking
>> code to jdk8.
>>
>> In mosts cases the
Hi,
I need a review of this large backport of the weak algorithm checking
code to jdk8.
In mosts cases the changes are either identical or 95% of what is in
jdk9, the below two files deviate the most from jdk9 because of other
jdk9 features:
dumping the log when the usage is not allowed?
Xuelei
On 3/8/2017 1:15 PM, Anthony Scarpino wrote:
Hi,
I need a code review of this small change.. The PKIX path for usage
checking didn't pass the variant to the checkers because of a previous
needed check for plugins.
http://cr.openjdk.java.net
Hi,
I need a code review of this small change.. The PKIX path for usage
checking didn't pass the variant to the checkers because of a previous
needed check for plugins.
http://cr.openjdk.java.net/~ascarpino/8176350/webrev/
thanks
Tony
Hi,
I need a review of this small change that wasn't caught in normal
testing of manifest entries.
http://cr.openjdk.java.net/~ascarpino/8175250/webrev/
thanks
Tony
Hi,
I need a quick review on a simple certpath config change.
http://cr.openjdk.java.net/~ascarpino/8174849/webrev/
thanks
Tony
(!permits(primitives, key.getAlgorithm(), null)) {
-return false;
-}
This block cannot be removed as the standard permits() (seel line 130)
still need to this check.
Otherwise, looks fine to me.
Xuelei
On 1/23/2017 3:27 PM, Anthony Scarpino wrote:
Hi,
I need a c
more than a timestamp.
--Sean
On 1/30/17 6:57 PM, Anthony Scarpino wrote:
On 01/23/2017 03:27 PM, Anthony Scarpino wrote:
Hi,
I need a code review of this change that brings more detail constraints
checking and control to certpath and jar disabled algorithm Security
properties.
http://
formating consistent.
Why did you move the RMI Registry Serial Filter? Offhand, this seems
gratuitous, and will make ift more difficult for folks trying to
maintain a single or slightly modified java.security across release
families.
Looks good otherwise.
Brad
On 2/6/2017 11:26 AM, Anthony
Please review this change for Solaris SPARC configurations to add an
optional configuration line.
There are a few minor changes which didn't change any content. Changing
some "#"'s for a bit more consistency and readability across the file.
Also moving an RMI entry to the end that was merged
that will
certainly benefit logging.
regards,
Sean.
On 30/01/2017 18:21, Anthony Scarpino wrote:
Hi Sean,
Actually Sean M and I were talking about that offline on thursday.
That file is changing a lot.
The three sections you mention have changed a lot, but the general
idea is the disabled alg
On 01/23/2017 03:27 PM, Anthony Scarpino wrote:
Hi,
I need a code review of this change that brings more detail constraints
checking and control to certpath and jar disabled algorithm Security
properties.
http://cr.openjdk.java.net/~ascarpino/8160655/webrev/
thanks
Tony
Updated review
() instead
* SignatureFileVerifier.java
294 Timestamp[] timestamp = new Timestamp[newSigners.length];
"timestamps" would be more clear as a variable name
299 System.out.println("Timestamp[" + (i - 1) + "] = " +
debug.println
--Sean
On 1/23
On 01/24/2017 11:24 AM, Xuelei Fan wrote:
Hi,
Please review this spec documentation update:
http://cr.openjdk.java.net/~xuelei/8172869/webrev.00/
In the java.security.AlgorithmParameterGenerator specification, 4096
bits DH parameter generator is specified as a required feature.
However,
On 01/19/2017 11:50 AM, Mandy Chung wrote:
On Jan 19, 2017, at 11:39 AM, Anthony Scarpino <anthony.scarp...@oracle.com>
wrote:
Hi,
I need a review to rename the jdk.crypto.token to jdk.crypto.cryptoki. This is to change
what 8171202 had done to the original jdk.crypto.pkcs11
Hi,
I need a review to rename the jdk.crypto.token to jdk.crypto.cryptoki.
This is to change what 8171202 had done to the original
jdk.crypto.pkcs11 module. For those not familiar with discussions
elsewhere, the term "token" is confusing and unclear as it can mean many
things
Looks good.
Tony
On 12/09/2016 12:54 PM, Xuelei Fan wrote:
Hi,
Please review this typo issue introduced in JDK-8170329.
$ hg diff test/sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java
@Override
-protected boolean isCustomizeClientConnection() {
+protected boolean
On 12/07/2016 03:21 PM, Valerie Peng wrote:
Anyone can help reviewing this?
The fix is straight forward, just renamed the DEBUG to J2UC_DEBUG to
address the E_MACRO_REDEFINED warning.
In addition, I also updated the nativeCrypto.h to remove the workaround
for a Solaris12-specific issue which
disabled
> via the jdk.tls.disabledAlgorithms or the jdk.certpath.disabledAlgorithms
> property. Please take another look and let me know if you are ok with it:
>
> http://cr.openjdk.java.net/~mullan/webrevs/8170131/webrev.01/
>
> Thanks,
> Sean
>
>> On 11/22/16 11:00 AM, Antho
401 - 500 of 653 matches
Mail list logo
