Hi Max,
On 2018/8/13 13:58, Weijun Wang wrote:
On Aug 13, 2018, at 1:46 PM, sha.ji...@oracle.com wrote:
On 2018/8/13 11:25, Weijun Wang wrote:
Can test.nss.lib.path contain multiple paths? For example, some systems might
have libsoftkn3.so and libnss3.so in different directories [1] and dep
> On Aug 13, 2018, at 3:36 PM, sha.ji...@oracle.com wrote:
>
> Hi Max,
>
> On 2018/8/13 13:58, Weijun Wang wrote:
>>
>>> On Aug 13, 2018, at 1:46 PM, sha.ji...@oracle.com wrote:
>>>
>>> On 2018/8/13 11:25, Weijun Wang wrote:
Can test.nss.lib.path contain multiple paths? For example, som
Sorry, more questions:
> On Aug 13, 2018, at 3:36 PM, sha.ji...@oracle.com wrote:
>
>> Is there an artifact server available on the open internet?
> It's transparent to me. @Artifact tool delegates the downloading.
Have you tried running the test outside Oracle?
Have you tried submitting the ch
Please take a review at
http://cr.openjdk.java.net/~weijun/8209416/webrev.00/
This is all about refactoring "AccessController.doPrivileged(new
GetPropertyAction(x))" into "GetPropertyAction.privilegedGetProperty(x)".
I've already introduced a new GetBooleanAction::privilegedGetProperty metho
Hi Max,
It might be useful to be a bit more consistent about putting the
property name on
the same line as the privilegedGetProperty.
It would help finding/grepping for the targets of privileged actions.
For example, Grep would not find the one in
sun/security/krb5/Config.java:824-825 or
sun/s
Looks fine to me.
Did you notice other places that might need similar update as well in
security components?
Thanks,
Xuelei
On 8/13/2018 3:24 AM, Weijun Wang wrote:
Please take a review at
http://cr.openjdk.java.net/~weijun/8209416/webrev.00/
This is all about refactoring "AccessContr
>As Chris and Alan mentioned, you should move the parsing of the property
>to a more general location so it can be used by other code that uses
>this property.
Hi Sean, Thanks for the input and comments .
Could we do the moving of the property parsingdo in a followup CR, I
would prefe
> On Aug 13, 2018, at 10:00 PM, Xue-Lei Fan wrote:
>
> Looks fine to me.
>
> Did you notice other places that might need similar update as well in
> security components?
One "new GetPropertyAction()" at
String property = AccessController.doPrivileged(
new GetPropertyAction(
And several AccessController.doPrivileged(new GetBooleanAction()) calls.
If you'd like me to fix them as well, I can change the bug synopsis a little.
Thanks
Max
> On Aug 13, 2018, at 11:33 PM, Weijun Wang wrote:
>
>
>
>> On Aug 13, 2018, at 10:00 PM, Xue-Lei Fan wrote:
>>
>> Looks fine t
One more update:
http://cr.openjdk.java.net/~xuelei/8207009/webrev.05/
It is desired to make a note in SSLSocket and SSLEngine specification,
so that users have a good sense that an application should close the
input and output stream always.
Updated for SSLEngine.java and SSLSocket.java on
Hi Xuelei,
* SSLSocket.java
o 134: Nit - You can remove the first "both" in this sentence
since you use it later with the input/output stream closure.
Looks good to me otherwise.
--Jamil
On 8/13/2018 11:31 AM, Xue-Lei Fan wrote:
One more update:
http://cr.openjdk.java.net/~xuel
Hi Jamil,
Thanks for review. One more step close to the integration.
On 8/13/2018 11:45 AM, Jamil Nimeh wrote:
Hi Xuelei,
* SSLSocket.java
o 134: Nit - You can remove the first "both" in this sentence
since you use it later with the input/output stream closure.
Let's use two
I think this should be an enhancement, and not a bug. Is this mainly for
a performance improvement?
Also, this change puts more of a dependency on sun.security.action which
I think we want to avoid, as it would be nice to eventually stop
exporting sun.security.action so as to minimize the expo
It's nice to fix them if you'd like to.
Thanks,
Xuelei
On 8/13/2018 8:36 AM, Weijun Wang wrote:
And several AccessController.doPrivileged(new GetBooleanAction()) calls.
If you'd like me to fix them as well, I can change the bug synopsis a little.
Thanks
Max
On Aug 13, 2018, at 11:33 PM, We
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, though? Ex:
SSLContext.setDefault(SSLContext.getIn
On 8/13/18 11:18 AM, Baesken, Matthias wrote:
As Chris and Alan mentioned, you should move the parsing of the property
to a more general location so it can be used by other code that uses
this property.
Hi Sean, Thanks for the input and comments .
Could we do the moving of the property parsi
An update.
1. OK vs. BUFFER_UNDERFLOW may still be an issue. It's not a big one,
but potentially confusing as to when you will get either.
2. I thought I saw this in the non-TLSv1.3 contexts also, but I think I
must have been reverted my test case back to "TLS", which uses the
TLS1.3 1/2
On 8/13/2018 2:12 PM, Bradford Wetmore wrote:
An update.
1. OK vs. BUFFER_UNDERFLOW may still be an issue. It's not a big one,
but potentially confusing as to when you will get either.
Did you figure out when OK is returned, and when BUFFER_UNDERFLOW is
returned? I think we have an improv
No, I haven't had the time to determine when OK vs BU.
Brad
On 8/13/2018 2:32 PM, Xue-Lei Fan wrote:
On 8/13/2018 2:12 PM, Bradford Wetmore wrote:
An update.
1. OK vs. BUFFER_UNDERFLOW may still be an issue. It's not a big
one, but potentially confusing as to when you will get either.
D
Hi Xuelei,
> Let's use two to emphasize the behaviors:
> 1. both input and output streams should be closed in each side, and
> 2. both client and server should perform #1.
SSLEngine.java
--
159: Both sides (i.e. the peer) may not be a SSLEngine:
both the client and server applicati
OK, I will check it. Thanks!
Xuelei
On 8/13/2018 3:15 PM, Bradford Wetmore wrote:
No, I haven't had the time to determine when OK vs BU.
Brad
On 8/13/2018 2:32 PM, Xue-Lei Fan wrote:
On 8/13/2018 2:12 PM, Bradford Wetmore wrote:
An update.
1. OK vs. BUFFER_UNDERFLOW may still be an issu
Good suggestion. I'll update my change.
Thanks
Max
> On Aug 13, 2018, at 9:53 PM, Roger Riggs wrote:
>
> Hi Max,
>
> It might be useful to be a bit more consistent about putting the property
> name on
> the same line as the privilegedGetProperty.
> It would help finding/grepping for the targe
Sorry for the late reply.
> On Aug 7, 2018, at 10:57 PM, Roger Riggs wrote:
>
> Hi Max,
>
> It may be useful to include in the descriptions a reminder that if no
> ObjectInputFilter
> is supplied the global filter is used. Details in ObjectInputStream.
The new getObject() methods with an Obj
> On Aug 14, 2018, at 3:11 AM, Sean Mullan wrote:
>
> I think this should be an enhancement, and not a bug. Is this mainly for a
> performance improvement?
Yes it's an enhancement.
Performance can be gained. Also, the privilegedGetProperty() method is already
called in a lot of places. Usi
Here is the change for both classes. I use "original object" so a caller would
know what the filter should expect.
diff --git a/src/java.base/share/classes/java/security/SignedObject.java
b/src/java.base/share/classes/java/security/SignedObject.java
--- a/src/java.base/share/classes/java/securit
Updated webrev at
http://cr.openjdk.java.net/~weijun/8209416/webrev.01/
You can look at [1] to see what has changed. Mostly it's a case in other
security libs. I also change the calling style to put property name in the same
line as the getProperty() call, and inline the name if it was define
26 matches
Mail list logo
