On Fri, Dec 07, 2018 at 10:45:02AM +0800, Weijun Wang wrote:
> Your detailed analysis is very valuable and I've included the whole text into
> https://bugs.openjdk.java.net/browse/JDK-8214988. I knew GSSName was
> complicated at the beginning and I remember I've especially asked you to look
> at it
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 su
Hi Sean,
Thanks for your review, I have removed the stale comment from the
VerificationProvider.
As for your concern on race condition, legacyChanged and the
String/String legacy mapping are still synchronized on the provider
object. Only the service mapping is managed by the ConcurrentHashM
> On Dec 7, 2018, at 10:52 AM, Valerie Peng wrote:
>
> Hi, Max,
>
> In my first prototype, I got rid of the Entries classes (for both SUN and
> SunRsaSign provider) and adds the Services inside the Provider. Later, when I
> saw VerificationProvider class and its dependency on the Entries c
Right, thanks for catching this. Will fix it in next webrev.
Valerie
On 12/5/2018 7:28 PM, Weijun Wang wrote:
Hi Valerie
-map.put("CertPathBuilder.PKIX ValidationAlgorithm",
-"RFC5280");
-map.put("CertPathValidator.PKIX ValidationAlgorithm",
-"RFC5280");
Hi, Max,
In my first prototype, I got rid of the Entries classes (for both SUN
and SunRsaSign provider) and adds the Services inside the Provider.
Later, when I saw VerificationProvider class and its dependency on the
Entries class, I have to revert back to the original approach of having
th
Hi Nico,
Your detailed analysis is very valuable and I've included the whole text into
https://bugs.openjdk.java.net/browse/JDK-8214988. I knew GSSName was
complicated at the beginning and I remember I've especially asked you to look
at it in my initial code review request. I think I have a bet
Hi Martin,
I suppose the changes in this update is just the system property
renaming? I looked at the relevant files and they look fine. If you made
more changes than this, please let me know and I will take a closer look
at them.
Don't forget to add a release note subtask for JDK-6913047 as
Hi Adam, comments/questions below (mostly simple stuff, nothing major):
* IntegerPolynomial.java
o The comment block for multByInt should reflect your changes you
made, namely the removal of "r" from the signature.
o 88: In the case of multiplying two very large long values woul
I filed https://bugs.openjdk.java.net/browse/JDK-8214988.
Thanks,
Max
> On Dec 7, 2018, at 5:33 AM, Nico Williams wrote:
>
> Looking at how to fix the incorrect isMN() implementation... The lowest cost
> route to fixing that would start with this sort of change:
>
>diff --git
> a/src/jav
Hi Valerie,
I'll fix it in my local repo, run some test, and push the changeset.
Thanks,
Max
> On Dec 7, 2018, at 6:58 AM, Valerie Peng wrote:
>
> Hi, Max,
>
> CSignature.java: one last nit, line 98 and 102 can be replaced by just one
> line outside the if-block.
>
> Thanks,
>
> Valerie
>
Hi, Max,
CSignature.java: one last nit, line 98 and 102 can be replaced by just
one line outside the if-block.
Thanks,
Valerie
On 12/6/2018 6:33 AM, Weijun Wang wrote:
Webrev updated at
https://cr.openjdk.java.net/~weijun/8213009/webrev.03
I reset messageDigest/messageDigestAlgorithm/
Hi Smita,
Great, the numbers look better. I'll run the regression tests and push
it if all goes well.
Tony
On 12/6/18 11:19 AM, Kamath, Smita wrote:
Hi Tony,
I have updated my code to address the performance regression in smaller data
sizes.
Please find the updated webrev and JBS link atta
Looks fine to me.
Thanks,
Xuelei
On 12/6/2018 1:09 PM, Jamil Nimeh wrote:
Hello everyone,
Updates from Xuelei's comments have been folded into an updated webrev:
http://cr.openjdk.java.net/~jnimeh/reviews/8214129/webrev.02/
Thank you,
--Jamil
On 12/5/18 3:59 PM, Jamil Nimeh wrote:
Hello a
Looking at how to fix the incorrect isMN() implementation... The lowest cost
route to fixing that would start with this sort of change:
diff --git
a/src/java.security.jgss/share/classes/sun/security/jgss/GSSNameImpl.java
b/src/java.security.jgss/share/classes/sun/security/jgss/GSSNameImpl.j
Hello everyone,
Updates from Xuelei's comments have been folded into an updated webrev:
http://cr.openjdk.java.net/~jnimeh/reviews/8214129/webrev.02/
Thank you,
--Jamil
On 12/5/18 3:59 PM, Jamil Nimeh wrote:
Hello all,
This fix covers an issue where large numbers of TLS 1.2 session
resumpt
Webrev: http://cr.openjdk.java.net/~apetcher/8214688/webrev.00/
JBS: https://bugs.openjdk.java.net/browse/JDK-8214688
The last session resumption bug fix[1] I made introduced a new issue
when the server sends a HelloRetryRequest message. The proposed fix is
pretty simple: when the client select
On Mon, Dec 03, 2018 at 05:10:26PM +, Seán Coffey wrote:
> I made further edits to update the DNSName comment code to reference RFC
> 5280 rather than the obsoleted RFC 2459. I also updated the test case with a
> few extra tests per suggestion from Chris and others. Moved the dataprovider
> int
On Wed, Dec 05, 2018 at 11:41:44AM +0800, Weijun Wang wrote:
> Java's GSSName::isMN always returns true, therefore to my observation, the
> GSS-API canonicalize_name() is not called if GSSName::canonicalize is called.
That *would* be a valid design choice (per RFCs 2743 and 2744), but it requires
Webrev updated at
https://cr.openjdk.java.net/~weijun/8213009/webrev.03
I reset messageDigest/messageDigestAlgorithm/needsReset and check for "key
instanceof RSAPublicKey" in RSA::engineInitVerify.
Thanks
Max
> On Nov 27, 2018, at 10:13 PM, Weijun Wang wrote:
>
>
>
>> On Nov 27, 201
Hi All
Currently, I have 4 code changes out for review and I wish they can make JDK 12
(RDP1 is 12/13)
8076190: Customizing the generation of a PKCS12 keystore
https://cr.openjdk.java.net/~weijun/8076190/webrev.05/
6722928: Support SSPI as a native GSS-API provider
https://cr.openjdk.ja
I will change those additional spots in the code. Glad you caught
those. I think also your suggestion about a comment on those locations
in the code makes sense.
--Jamil
On 12/5/2018 8:20 PM, Xue-Lei Fan wrote:
Hi Jamil,
For a defense in depth fix, as you are already there, I may suggest
22 matches
Mail list logo
