On Fri, 23 Jul 2021 17:16:26 GMT, Sean Mullan wrote:
> Please review this fix to change the internal `X509CertImpl.getFingerprint`
> method to not return "" as a fingerprint if there is an error generating that
> fingerprint. Instead, `null` is now returned, and "" is no longer cached as a
> v
I think it's worth noting that there isn't a way to securely run code
with malicious intent now, so I'm surprised that at this late stage you
were still providing support for sand boxing (whack a mole).
It's just for us many assumptions have been made on a Java platform with
SM, using POLP (no
On Fri, 23 Jul 2021 17:08:11 GMT, Clive Verghese wrote:
>> src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 972:
>>
>>> 970: boolean found = false;
>>> 971: CipherSuite cs;
>>> 972: if ((cs = cipherSuiteNames.get(name)) != null &&
>>> !cs.su
> ### Benchmark results
>
> I have benchmarked 3 cases.
>
> 1. The current situation.
>
> Benchmark
> (cipherSuite) Mode CntScore Error Units
> CipherSuiteBench.benchmarkCipherSuite
> TLS_AES_256_GCM_SHA384 av
On Fri, 23 Jul 2021 17:11:30 GMT, Clive Verghese wrote:
>> ### Benchmark results
>>
>> I have benchmarked 3 cases.
>>
>> 1. The current situation.
>>
>> Benchmark
>> (cipherSuite) Mode CntScore Error Units
>> CipherSuiteBench.b
Please review this fix to change the internal `X509CertImpl.getFingerprint`
method to not return "" as a fingerprint if there is an error generating that
fingerprint. Instead, `null` is now returned, and "" is no longer cached as a
valid fingerprint. Although errors generating fingerprints shoul
On Fri, 23 Jul 2021 17:05:58 GMT, Xue-Lei Andrew Fan wrote:
>> Clive Verghese has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove for loop from validValuesOf
>
> src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 972:
On Fri, 23 Jul 2021 16:52:38 GMT, Clive Verghese wrote:
>> ### Benchmark results
>>
>> I have benchmarked 3 cases.
>>
>> 1. The current situation.
>>
>> Benchmark
>> (cipherSuite) Mode CntScore Error Units
>> CipherSuiteBench.b
> ### Benchmark results
>
> I have benchmarked 3 cases.
>
> 1. The current situation.
>
> Benchmark
> (cipherSuite) Mode CntScore Error Units
> CipherSuiteBench.benchmarkCipherSuite
> TLS_AES_256_GCM_SHA384 av
On Fri, 18 Jun 2021 18:28:26 GMT, Sean Mullan wrote:
>> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to
>> use `ArrayList` if a thread-safe implementation is not needed. In
>> post-BiasedLocking times, this is gets worse, as every access is
>> synchronized.
>> I ch
> ### Benchmark results
>
> I have benchmarked 3 cases.
>
> 1. The current situation.
>
> Benchmark
> (cipherSuite) Mode CntScore Error Units
> CipherSuiteBench.benchmarkCipherSuite
> TLS_AES_256_GCM_SHA384 av
On Fri, 23 Jul 2021 05:52:25 GMT, djelinski
wrote:
>> Clive Verghese has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add blank space before and after the for loop
>
> src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 97
On Fri, 18 Jun 2021 18:28:26 GMT, Sean Mullan wrote:
>> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to
>> use `ArrayList` if a thread-safe implementation is not needed. In
>> post-BiasedLocking times, this is gets worse, as every access is
>> synchronized.
>> I ch
On Thu, 22 Jul 2021 17:29:32 GMT, Rajan Halade wrote:
> I have updated revoked test certificate but this test may again fail in Sept
> as test certificate expire leading to OCSP error.
>
> CA is not willing to issue test certificates with more than 90 day validity
> so this test will fail ever
On Fri, 23 Jul 2021 15:00:44 GMT, Sean Mullan wrote:
> But you could cache the OCSPResponse now while the certificate is not
> expired, and use that in the test by calling
> `PKIXRevocationChecker.setOcspResponses()`. For CRLs, you could also do
> something similar by caching the CRL and stori
On Thu, 22 Jul 2021 17:29:32 GMT, Rajan Halade wrote:
> I have updated revoked test certificate but this test may again fail in Sept
> as test certificate expire leading to OCSP error.
>
> CA is not willing to issue test certificates with more than 90 day validity
> so this test will fail ever
On Fri, 23 Jul 2021 13:18:16 GMT, Sean Mullan wrote:
> Have you thought about using a cached OCSPResponse to avoid the expiration
> issues? You would not be testing a live OCSP network request/response, but it
> might be an acceptable workaround for cases like this.
For OCSP, it is possible to
On Thu, 22 Jul 2021 18:07:42 GMT, Rajan Halade wrote:
> Test certificates are updated for now. I am re-thinking the CA certification
> testing approach to may be try a TLS connection with test websites. This will
> ensure that test will pass as long as CA keeps test website updated.
This pull
On Thu, 22 Jul 2021 17:29:32 GMT, Rajan Halade wrote:
> I have updated revoked test certificate but this test may again fail in Sept
> as test certificate expire leading to OCSP error.
>
> CA is not willing to issue test certificates with more than 90 day validity
> so this test will fail ever
On Thu, 22 Jul 2021 18:07:42 GMT, Rajan Halade wrote:
> Test certificates are updated for now. I am re-thinking the CA certification
> testing approach to may be try a TLS connection with test websites. This will
> ensure that test will pass as long as CA keeps test website updated.
Marked as
Trusted code only, but it's intended to be run in a locked down
principle of least privilege environment, while we perform static
analysis and targeted review, we don't have the resources required to
perform thorough trusted code audits, so have been reliant on the
principle of least privilege.
On 23/07/2021 11:48, Peter Firmstone wrote:
Perhaps the solution is to replace the entire class, instead of
instrumenting one method?
Compile a patched copy of the JVM, with modified class files, then
replace the existing classes in the JVM with the modified classes?
Kinda like maintaining
Hello,
Could you please review the small patch for the issue described in JDK-8271199:
Mutual TLS handshake fails signing client certificate with custom sensitive
PKCS11 key
I suggest updating the RSAPSSSignature.isValid() method to verify if provided
key components can be applied to SunRSASig
Perhaps the solution is to replace the entire class, instead of
instrumenting one method?
Compile a patched copy of the JVM, with modified class files, then
replace the existing classes in the JVM with the modified classes?
Kinda like maintaining a fork, but using Agents to instrument the
or
Post JEP 411, we need to write Agents to replace the current permission
checks performed within the JVM by instrumenting it, following advice by
OpenJDK developers, however for us this goes against all our previous
development practices, no part of our codebase accesses any JDK
implementation c
25 matches
Mail list logo
