Hi Valerie
Since you are specifically fixing a bug inside the SunRsaSign provider, is it
enough to just use the KeyPairGenerator from this provider?
The src fix is fine.
Thanks
Max
> On Nov 2, 2018, at 10:14 AM, Valerie Peng wrote:
>
> Hi,
>
> Anyone can help review this trivial fix?
>
>
Hi,
Anyone can help review this trivial fix?
Bug: https://bugs.openjdk.java.net/browse/JDK-8211049
Webrev: http://cr.openjdk.java.net/~valeriep/8211049/webrev.00/
Mach5 result with the new regression test is clean.
Thanks,
Valerie
On 11/1/2018 11:24 AM, Sean Mullan wrote:
On 10/31/18 11:52 AM, Chris Hegarty wrote:
Xuelei,
On 30/10/18 20:55, Xuelei Fan wrote:
Hi,
For the current HttpsURLConnection, there is not much security
parameters exposed in the public APIs. An application may need
richer information for the
On 11/1/18 12:39 PM, Sean Mullan wrote:
I also replaced getCallerPD with the faster getProtectionDomain and
removed a stale comment about impliesCreateAccessControlContext being
called by the VM. It should be safe to remove now, but I left it in
to minimize changes.
I would just remove it,
On 11/1/18 2:34 PM, dean.l...@oracle.com wrote:
@Hidden is internal and no CSR is needed.
FYI. JDK-8212620 is the RFE to consider providing a standard
mechanism to hide frames from stack trace.
OK, I already filed JDK-8213234 but I think I should just close it as
a duplicate of
On 11/1/18 1:45 PM, Mandy Chung wrote:
On 11/1/18 1:18 AM, Vladimir Ivanov wrote:
I think it's a good idea, but I believe it would require a CSR
request. Do you mind if I file a separate issue for
jdk.internal.vm.annotation.Hidden?
Sure.
Most of the annotations in
On 11/1/18 1:18 AM, Vladimir Ivanov wrote:
I think it's a good idea, but I believe it would require a CSR
request. Do you mind if I file a separate issue for
jdk.internal.vm.annotation.Hidden?
Sure.
Most of the annotations in jdk.internal.vm.annotation were originally
located in
On 11/1/18 3:21 PM, dean.l...@oracle.com wrote:
On 11/1/18 9:48 AM, Sean Mullan wrote:
On 11/1/18 1:29 AM, dean.l...@oracle.com wrote:
On 10/31/18 9:39 PM, Bernd Eckenfels wrote:
On 11/1/18 9:48 AM, Sean Mullan wrote:
On 11/1/18 1:29 AM, dean.l...@oracle.com wrote:
On 10/31/18 9:39 PM, Bernd Eckenfels wrote:
http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html
In checkContext should the
On 11/1/18 10:01 AM, Sean Mullan wrote:
Some of the copyrights need to be updated to 2018.
Fixed.
All else looks good to me as I had reviewed an earlier version of this
before. We have talked about doing this for a while now, so I am
finally glad we and are able to pretty much eliminate
Hi Daniel thanks for bringing this up, this sounds like
https://bugs.openjdk.java.net/browse/JDK-8212885. I'm very close to a
fix on this one, just working out a few issues in testing.
--Jamil
On 10/8/2018 2:34 PM, Daniel Christensen wrote:
I have a custom HostnameVerifier that attempts to
On 10/31/18 11:52 AM, Chris Hegarty wrote:
Xuelei,
On 30/10/18 20:55, Xuelei Fan wrote:
Hi,
For the current HttpsURLConnection, there is not much security
parameters exposed in the public APIs. An application may need richer
information for the underlying TLS connections, for example the
On 10/31/18 5:13 PM, dean.l...@oracle.com wrote:
On 10/31/18 4:06 PM, David Holmes wrote:
Hi Dean,
Looking only at the hotspot changes. The removal of the DoPrivileged
and related privileged_stack code seems okay. I have a few related
comments:
Dean,
src/java.base/share/classes/java/security/AccessController.java:
+/**
+ * Internal marker for hidden implementation frames.
+ */
+/*non-public*/
+@Target(ElementType.METHOD)
+@Retention(RetentionPolicy.RUNTIME)
+@interface Hidden {
+}
You declare @Hidden,
I think it's a good idea, but I believe it would require a CSR request.
Do you mind if I file a separate issue for
jdk.internal.vm.annotation.Hidden?
Sure.
Most of the annotations in jdk.internal.vm.annotation were originally
located in java.lang.invoke. Not sure CSR will be required in
I have a custom HostnameVerifier that attempts to examine the certificate chain
using SSLSession#getPeerCertificates(). After upgrading to Java 11, where it
seems that TLSv1.3 is used by default, I am seeing that getPeerCertificates()
throws an SSLPeerUnverifiedException after an HTTP redirect
On 10/31/18 9:15 PM, Peter wrote:
Hello Dean & David,
Interesting reading. Is DomainCombiner still being considered for
deprecation?
There are no immediate plans to deprecate DomainCombiner, but we are
looking at the SecurityManager (SM) and all of its related APIs and
evaluating
Hi Peter. Thanks for the input. I don't know about DomainCombiner, but
perhaps someone else on this list does.
dl
On 10/31/18 6:15 PM, Peter wrote:
Hello Dean & David,
Interesting reading. Is DomainCombiner still being considered for
deprecation?
Our code makes heavy use of
Some of the copyrights need to be updated to 2018.
All else looks good to me as I had reviewed an earlier version of this
before. We have talked about doing this for a while now, so I am finally
glad we and are able to pretty much eliminate one of the more common
SecurityManager related
On 11/1/18 1:29 AM, dean.l...@oracle.com wrote:
On 10/31/18 9:39 PM, Bernd Eckenfels wrote:
http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html
In checkContext should the security manager be null checked first
instead
I removed the deprecation parts in the update. Here is the new webrev:
http://cr.openjdk.java.net/~xuelei/8212261/webrev.01/
And the CSR was updated accordingly.
https://bugs.openjdk.java.net/browse/JDK-8213161
Thanks,
Xuelei
On 11/1/2018 4:57 AM, Chris Hegarty wrote:
On 31 Oct 2018,
Okay. Looks fine to me.
Thanks,
Xuelei
On 11/1/2018 8:47 AM, Sean Mullan wrote:
On 11/1/18 11:27 AM, Xuelei Fan wrote:
What do you think if adding a note that the default value may be
different for each provider, and may be changed from time to time with
the development of crypto analysis?
On 11/1/18 11:27 AM, Xuelei Fan wrote:
What do you think if adding a note that the default value may be
different for each provider, and may be changed from time to time with
the development of crypto analysis?
I didn't want to get too wordy, just to make a concise point that
defaults can be
Hi Andrew,
Thanks for having a look at this.
Webrev.02 without "All rights reserved" and "affiliates" parts:
* http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.02/
* http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.02.zip
Are you okay to go?
Kind regards,
What do you think if adding a note that the default value may be
different for each provider, and may be changed from time to time with
the development of crypto analysis?
Xuelei
On 11/1/2018 7:57 AM, Sean Mullan wrote:
Please review this javadoc-only change to the Cipher class. An @apiNote
Please review this javadoc-only change to the Cipher class. An @apiNote
has been added to each of the getInstance methods to recommend that the
full transformation be specified when creating a Cipher and to avoid
relying on the defaults. Also a link to the defaults used by the JDK
providers
On 11/1/18 4:19 AM, Weijun Wang wrote:
On Nov 1, 2018, at 5:25 AM, Nico Williams wrote:
Otherwise looks fine. You will need to add a noreg label if you can't write a
test.
Yes.
Not sure what that means.
https://openjdk.java.net/guide/changePlanning.html#noreg.
I'll add a noreg-hard
> On 31 Oct 2018, at 20:03, Xuelei Fan wrote:
>> ...
> Yes. I had the same concern about the optional operation. However, I came
> to a different conclusion if I'm from viewpoint of these users that need to
> use this new operation.
>
> If an application have to use this new operation, for
On Tue, 30 Oct 2018 at 18:00, Martin Balao wrote:
>
> Hi,
>
> You're right, this is not relevant for a test.
>
> * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.01
> * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.01.zip
>
> Thanks,
> Martin.-
>
> On Tue,
> On Oct 30, 2018, at 2:22 AM, Michael StJohns wrote:
>
> On 10/25/2018 11:09 PM, Weijun Wang wrote:
>> Hi Mike
>>
>> Thanks for the feedback.
>>
>> I understand the current SunMSCAPI implementation recognizes RSA keys only
>> and it's certainly incorrect to put something like getModulus()
> On Nov 1, 2018, at 5:25 AM, Nico Williams wrote:
>
>>> Otherwise looks fine. You will need to add a noreg label if you can't write
>>> a test.
>>
>> Yes.
>
> Not sure what that means.
https://openjdk.java.net/guide/changePlanning.html#noreg.
I'll add a noreg-hard due to complex setup.
31 matches
Mail list logo
