Hi Sean, do you think it would be good to check in a jtreg test that
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Is always in the lists returned by
ssf.getDefaultCipherSuites() and ssf.getSupportedCipherSuites() ?
Best regards, Matthias
> -Original Message-
> From: Sean Mullan
> Se
Actually a bug for this has just been filed by SAP:
https://bugs.openjdk.java.net/browse/JDK-8217579. Since it came in via
webbugs, it has been initially marked Confidential. We can probably just
use this bug. I'll copy in more details and open it up.
--Sean
On 1/22/19 4:46 PM, Sean Mullan wr
Hi Christoph,
Yes, this indeed looks like a bug. The jdk.tls.disabledAlgorithms
security property probably should not restrict suites that are not
negotiable like TLS_EMPTY_RENEGOTIATION_INFO_SCSV.
Please feel free to file a bug or else Sean Coffey or I can do that on
your behalf tomorrow. T
Hi security experts,
one of our customers is running into an issue with a Tomcat application after
JDK-8211883 [1]. It seems that because of adding NULL to
jdk.tls.disabledAlgorithms, the pseudo cipher suite
TLS_EMPTY_RENEGOTIATION_INFO_SCSV is disabled. Seems like, according to
CipherSuite.ja
Hi,
looks OK as a point fix for now, although we should consider if there
might be more robust ways that avoids hard-coding in flags. E.g, could
+AlwaysPreTouch have unfortunate side-effects on machines with extreme
amounts of RAM if you don't also limit maximum heap size (-Xmx)?
/Claes
On 2019
Claes,
Please review this very small change that adds the "+AlwaysPreTouch"
option to the crypto benchmarks to allow them to warm up in time. This
fix is in response to Eric's discovery (when reviewing the new
benchmarks for KeyAgreement and Cipher) that the crypto benchmarks were
not warming
Thank you for the test exception, Jaikiran! I just got to the office and
was about to do the same thing.
I didn't think It was a WildFly issue. WildFly was just where I first
noticed the warning.
Again, thank you, Sir.
--drg
On Tue, Jan 22, 2019 at 5:44 AM Jaikiran Pai
wrote:
> FWIW - I don't
FWIW - I don't think this is related to WildFly server. So I decided to
try and reproduce this in a trivial standalone program and I was able to
reproduce this. Here's the code to reproduce this issue:
import java.sql.*;
public class ConnectionCloseTest {
public static void main(final Strin
On 22/01/2019 4:48 am, Robert Marcano wrote:
:
So the question now is, why signed jars could affect the memory usage
of an application (we aren't doing JAR verification on our custom
launcher, yet), just by being on the java.class.path? IIRC the
initial application classpath JARs were never v
