Hello, please review the following change.
I noticed that we miss at some places (for example in case of early returns)
where GetByteArrayElements is used, the corresponding ReleaseByteArrayElements
call.
In VirtualMachineImpl.c I also removed a check for isCopy (is the returned
byte array a
ping ...
On 12/10/2018 1:14 PM, Xue-Lei Fan wrote:
Hi,
Please review the TLS 1.3 half-close issue in JDK.
http://cr.openjdk.java.net/~xuelei/8209333/webrev.00/
While trying to duplex close a TLS connection upon the half-close
policy, there might be pending receiving data in the closing
So is what I see something that should be fixed in general ?
Like I said it does not matter if its TLSv1.3 or earlier.
Bye
Norman
> On 12. Dec 2018, at 15:42, Norman Maurer wrote:
>
> Hi Jamil,
>
> This was just noticed during a test which uses TLS1.2.
>
>> On 12. Dec 2018, at 15:35, Jamil
Hi Xuelei, just a couple questions:
* SSLSocketImpl
o 611: Are you sure conContext.inputRecord should go into a
try-with-resources? As far as I can tell, the inheritence chain
is SSLSocketInputRecord->InputRecord and that directly or by
extension implements the SSLReco
On 12/17/2018 11:28 AM, Jamil Nimeh wrote:
Hi Xuelei, just a couple questions:
* SSLSocketImpl
o 611: Are you sure conContext.inputRecord should go into a
try-with-resources? As far as I can tell, the inheritence chain
is SSLSocketInputRecord->InputRecord and that direct
In a related matter, are the existing tests reliable to detect the Situation
(at least for the Default runtime/compiler behavior). i.e. are the testcases
covering stack Evaluation in a compiled context where EA would elimiiminate it?
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: dean.l...@ora
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.
On 12/14/18 1:57 PM, Nico Williams wrote:
On Fri, Dec 14, 2018 at 02:09:50PM +, Bernd Eckenfels wrote:
Maybe a comment should point to the description of this pattern (if it
applies):
https://www.oracle.com/technetwork/java/seccodeguide-139067.html#4-5
+1
Do document what initialized/chec
Hi Xuelei, comments in-line.
On 12/17/2018 12:11 PM, Xue-Lei Fan wrote:
On 12/17/2018 11:28 AM, Jamil Nimeh wrote:
Hi Xuelei, just a couple questions:
* SSLSocketImpl
o 611: Are you sure conContext.inputRecord should go into a
try-with-resources? As far as I can tell, the inhe
Yes, I think so. I'm not sure if we're going to make a separate issue
for this specifically or handle it as part of a larger session
management improvement we're working on.
--Jamil
On 12/17/2018 11:13 AM, Norman Maurer wrote:
So is what I see something that should be fixed in general ?
Lik
Hi Matthias,
On 17/12/2018 6:59 pm, Baesken, Matthias wrote:
Hello, please review the following change.
I noticed that we miss at some places (for example in case of early returns)
where GetByteArrayElements is used, the corresponding ReleaseByteArrayElements
call.
In VirtualMachineImpl.c I
https://bugs.openjdk.java.net/browse/JDK-8214329
http://cr.openjdk.java.net/~dlong/8214329/webrev/
In "8212605: Pure-Java implementation of AccessController.doPrivileged",
the stackwalk in JVM_GetStackAccessControlContext was changed from using
a vframeStream to using a javaVFrame, so that it c
This looks okay to me.
Mandy
On 12/14/18 4:59 PM, dean.l...@oracle.com wrote:
https://bugs.openjdk.java.net/browse/JDK-8214583
http://cr.openjdk.java.net/~dlong/8214583/webrev
This change includes two new regression test that demonstrate the
problem, and a fix that allows the tests
to pass.
Thanks Mandy.
dl
On 12/17/18 2:55 PM, Mandy Chung wrote:
This looks okay to me.
Mandy
On 12/14/18 4:59 PM, dean.l...@oracle.com wrote:
https://bugs.openjdk.java.net/browse/JDK-8214583
http://cr.openjdk.java.net/~dlong/8214583/webrev
This change includes two new regression test that demonstr
Correction ...
On 18/12/2018 8:25 am, David Holmes wrote:
Hi Matthias,
On 17/12/2018 6:59 pm, Baesken, Matthias wrote:
Hello, please review the following change.
I noticed that we miss at some places (for example in case of early
returns)
where GetByteArrayElements is used, the corresponding
Any one has time to review this straightforward fix? Details on cause
and fix is elaborated in the link below:
Bug: https://bugs.openjdk.java.net/browse/JDK-8214096
Webrev can be found at
http://cr.openjdk.java.net/~valeriep/8214096/webrev.00/
Regards,
Valerie
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 exception and have the
calling method throw the exception? As is, the
Hi Valerie,
Please put lines 87 and 100 into the if-not-null block. Otherwise fine.
Do you think we can enhance the Signature::setParameter method and claim a null
parameter is not meaningful at all and should not have any effect on the
internal state of the signature object? Otherwise an appli
This looks okay to me
(cc'ing security-dev as that is where the smart card I/O API is maintained)
On 18/12/2018 05:23, Priya Lakshmi Muthuswamy wrote:
Hi,
Kindly review the changes for
https://bugs.openjdk.java.net/browse/JDK-8214570
webrev : http://cr.openjdk.java.net/~pmuthuswamy/8214570/
19 matches
Mail list logo
