Re: [9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations

For all: - If you can remember the old "securerandom.drbg.config" value to reset it in a finally clause, there is no need to othervm. - All DRBG mechanism names contain "_DRBG", therefore I'd rather change NON_DRBG.contains(mech) to !mech.contains("_DRBG"). The same technique can be applied ev

Bug JDK-8153924 "MSCAPI provider does not create unique alias names" should be fixed in 8u92, but...

... I still get the same alias for all of my 3 certificates, even though I use 8u92. Code: KeyStore keyStore = KeyStore.getInstance("Windows-MY", "SunMSCAPI"); keyStore.load(null, null); System.out.println(keyStore.getProvider()); List keyStoreAliases = Collections.list(keySto

Re: Code Review Request, 8154344 sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java fails on solaris

On 5/10/2016 2:37 PM, Wang Weijun wrote: > >> On May 10, 2016, at 7:58 AM, Xuelei Fan wrote: >> >> On 5/10/2016 12:16 AM, Michael StJohns wrote: >>> You're going to hate me, but shouldn't this be checking the Provider >>> rather than the OS when trying to determine which test to ignore? >>> >> It

Re: Bug JDK-8153924 "MSCAPI provider does not create unique alias names" should be fixed in 8u92, but...

Hello Dirk! On 10.05.2016 10:47, Henselin, Dirk (A-GDTO-B4) wrote: … I still get the same alias for all of my 3 certificates, even though I use 8u92. What is the build number of JDK in use? Could you please provide the output of `java -version`? If it's possible, could you also try the 8u102

Re: RFR: regex changes -- sun.security.util.Debug issue

On 10/05/2016 06:36, Xueming Shen wrote: Hi, While testing for the attached regex changes, a fatal vm init error was triggered for test case with -Djava.security.debug=xyz turned on, as showed in following stacktrace. It appears sun.security.util.Debug is being initialized even before the l

AW: Bug JDK-8153924 "MSCAPI provider does not create unique alias names" should be fixed in 8u92, but...

Hello Ivan, Thank you for your quick response! I didn't know, that there are different official builds. I only looked at the version number and used the primary download at http://www.oracle.com/technetwork/java/javase/downloads/index.html

Re: AW: Bug JDK-8153924 "MSCAPI provider does not create unique alias names" should be fixed in 8u92, but...

Thanks for the update! Please let us know, if you encounter any problem with later releases/builds of JDK, which should include the fix. With kind regards, Ivan On 10.05.2016 14:55, Henselin, Dirk (A-GDTO-B4) wrote: Hello Ivan, Thank you for your quick response! I didn’t know, that ther

RFR 8149521: automatic discovery of LDAP servers with Kerberos authentication

Hi All Please take a review at http://cr.openjdk.java.net/~weijun/8149521/webrev.00/ While the bug report [1] suggests we can fix com.sun.jndi.ldap.ServiceLocator to emit a trail-dot-less hostname, I am not sure if it's safe to do so. Anyway, the failure is on the Kerberos side and I belie

Re: RFR 8149521: automatic discovery of LDAP servers with Kerberos authentication

Looks fine to me Max. Thanks. > On 10 May 2016, at 14:34, Wang Weijun wrote: > > Hi All > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8149521/webrev.00/ > > While the bug report [1] suggests we can fix com.sun.jndi.ldap.ServiceLocator > to emit a trail-dot-less hostna

Rare memory leak in sun.security.pkcs11.SunPKCS11 poller thread

Hi, While working my way through Tomcat's memory leak protection / detection / fixing code, I have found an issue that remains unresolved in the latest JDK 9 source. The poller thread created by the SunPKCS11 class does not explicitly set the context class loader so it inherits the current contex

Re: RFR: 8155775: Re-examine naming of privileged methods to access System properties

On 5/9/16 11:44 PM, Wang Weijun wrote: I have a question related. There are some places in JDK that use doPrivileged to read "os.name" etc. This system property is in the default java.policy file On May 2, 2016, at 10:15 PM, Sean Mullan wrote: This is not an issue in your changes, but the

Re: Code Review Request, 8154344 sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java fails on solaris

On 5/10/2016 2:37 AM, Wang Weijun wrote: On May 10, 2016, at 7:58 AM, Xuelei Fan wrote: On 5/10/2016 12:16 AM, Michael StJohns wrote: You're going to hate me, but shouldn't this be checking the Provider rather than the OS when trying to determine which test to ignore? It's more accurate to c

AES-NI support

Hi, I have a short – but probably not easy – question to the sec-dev community, since we have a research project dealing with the performance impact and performance optimizations for TLS: What TLS cipher suites and ciphers, modes of operation, security providers, etc. in general benefit fro

Re: RFR: regex changes -- sun.security.util.Debug issue

On 5/10/16 1:30 AM, Alan Bateman wrote: On 10/05/2016 06:36, Xueming Shen wrote: Hi, While testing for the attached regex changes, a fatal vm init error was triggered for test case with -Djava.security.debug=xyz turned on, as showed in following stacktrace. It appears sun.security.util.Debug

Re: Review Request: 8150468: ClassCircularityError on error in security policy file

On 5/9/16 6:20 PM, Mandy Chung wrote: On May 6, 2016, at 11:43 AM, Sean Mullan wrote: Please review this fix for https://bugs.openjdk.java.net/browse/JDK-8150468: http://cr.openjdk.java.net/~mullan/webrevs/8150468/webrev.00/ The fix is to record bad policy files as they are parsed and ign

Re: RFR: regex changes -- sun.security.util.Debug issue

Sean, Given the "debug" is a private field and it is used only for debug != null in toString() -> seeAllp(), can the following change be a valid update? with the assumption that (1) the toString() is really not performance critical here, as we are changing from debug != null to

Re: [8u-dev] Request for Review + Request for Approval for Backport 8049171: Additional tests for jarsigner's warnings

Little remainder. On 06.05.2016 21:14, Svetlana Nikandrova wrote: Hello, I would be grateful if someone could find time to review this backport of tests enhancement. I received few off-line notes and decided to rework this backport a little. Here is my new webrev: http://cr.openjdk.java.net

Re: RFR: regex changes -- sun.security.util.Debug issue

webrev has been updated as suggested, now the lazily-init-class-holder is used to delay the Debug initialization. Tests all passed locally. A jprt job is out to confirm. Here is the updated webrev http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ Thanks! Sherman On 05/

Re: AES-NI support

If you look at the builtin support it is only AES/CBC with the SunJCE (the AES/GCM has still a long way to go). With external/platform specific providers (ucrypto on Solaris, libnss via PKCS11 and Windows Crypto API) you might get more hw support. Gruss Bernd -- http://bernd.eckenfels.net ---

RFR: JDK-8156584: Initialization race in sun.security.x509.AlgorithmId.get

https://bugs.openjdk.java.net/browse/JDK-8156584 http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/ I'm not a crypto engineer, so I'm hoping someone on security-dev adopts this fix. But current webrev is intended to be a complete fix for jdk8.

Re: AES-NI support

Hi, JEP 246 goes into some of these details but, particularly for AES-GCM for jdk9 with the GHASH intrinsics. Also jdk supports intrinsics for SHA1/2 and RSA. For jdk8, AES block ops use AES-NI and AES-CBC has been parallelized. http://openjdk.java.net/jeps/246 Tony On 05/10/2016 09:48 A

Re: RFR: regex changes -- sun.security.util.Debug issue

On 10/05/2016 19:57, Xueming Shen wrote: webrev has been updated as suggested, now the lazily-init-class-holder is used to delay the Debug initialization. Tests all passed locally. A jprt job is out to confirm. Here is the updated webrev http://cr.openjdk.java.net/~sherman/regexBackTrack.La

Re: RFR: regex changes -- sun.security.util.Debug issue

On 5/10/16 1:10 PM, Alan Bateman wrote: On 10/05/2016 19:57, Xueming Shen wrote: webrev has been updated as suggested, now the lazily-init-class-holder is used to delay the Debug initialization. Tests all passed locally. A jprt job is out to confirm. Here is the updated webrev http://cr.op

ISO10126PADDING, minor optimizations and random question

Hello, while looking at ISO10126Padding I noticed a few minor optimizations are possible: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/com/sun/crypto/provider/ISO10126Padding.java?av=f unpad() - there is already a int cast done to this value: 104int sta

Non constant time padding check in SunJCE PKCS5Padding

Hello, I had a look at the PKCS5Padding because I had the problem that AES/CBC/NOPADDING is much faster than AES/CBC/PKCS5PADDING (for larger single block with doFinal() encryptions). I havent found out the reason for that (I suspect it does a unecesary input copy). (opening another thread for thi

RFR 8156709: Cannot call setSeed on NativePRNG on Mac if EGD is /dev/urandom

Hi All Please review the fix at http://cr.openjdk.java.net/~weijun/8156709/webrev.00/ On *nix, we open EGD and write into it when setSeed() is called. We were aware of the device not openable and have been ignoring it (Note we still write to a mix random). Now it seems on a Mac is can be ope

Re: RFR 8156709: Cannot call setSeed on NativePRNG on Mac if EGD is /dev/urandom

What a stupid bug in MacOS. You can write to /dev/random, but not /dev/urandom. Yosemite: $ uname -a Darwin smarks 14.5.0 Darwin Kernel Version 14.5.0: Tue Sep 1 21:23:09 PDT 2015; root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64 (4:51:18 PM) $ ls -al /dev/*random crw-rw-rw- 1 root wheel 11,

Re: RFR 8156709: Cannot call setSeed on NativePRNG on Mac if EGD is /dev/urandom

> On May 11, 2016, at 7:55 AM, Bradford Wetmore > wrote: > > What a stupid bug in MacOS. You can write to /dev/random, but not > /dev/urandom. My understanding is that the entropy pool is on the /dev/random side, so you can write into it. On the /dev/urandom side, it seed from /dev/random a

Re: RFR: regex changes -- sun.security.util.Debug issue

Hi Xueming, It looks ok to me, but I'm curious if there may be other security classes that are initialized quite early and write to debug and may run into similar issues. Did you run all of the security regression tests in the jprt job? --Sean On 5/10/16 11:57 AM, Xueming Shen wrote: webre

Re: RFR: regex changes -- sun.security.util.Debug issue

> On May 10, 2016, at 1:44 PM, Xueming Shen wrote: > > On 5/10/16 1:10 PM, Alan Bateman wrote: >> >> >> On 10/05/2016 19:57, Xueming Shen wrote: >>> webrev has been updated as suggested, now the lazily-init-class-holder is >>> used >>> to delay the Debug initialization. Tests all passed local

Re: RFR 8154523: SHA1PRNG output should change after reset

OK, go ahead! Thanks, Xuelei On 5/9/2016 7:08 AM, Wang Weijun wrote: > >> On May 8, 2016, at 10:26 PM, Xuelei Fan wrote: >> >> On 5/8/2016 9:06 PM, Wang Weijun wrote: >>> Ping again. >>> On May 3, 2016, at 10:26 AM, Wang Weijun wrote: Hi All Please take a review at >>>

Re: Code Review Request, 8154344 sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java fails on solaris

On 5/10/2016 4:23 PM, Xuelei Fan wrote: > On 5/10/2016 2:37 PM, Wang Weijun wrote: >> >>> On May 10, 2016, at 7:58 AM, Xuelei Fan wrote: >>> >>> On 5/10/2016 12:16 AM, Michael StJohns wrote: You're going to hate me, but shouldn't this be checking the Provider rather than the OS when tryi

Re: [8u-dev] Request for Review + Request for Approval for Backport 8049171: Additional tests for jarsigner's warnings

Looks fine to me. Just curious, why choose BUFFER_SIZE = 1024 in Utils.java? In JDK 9, DEFAULT_BUFFER_SIZE = 8192. Thanks Max > On May 11, 2016, at 2:16 AM, Svetlana Nikandrova > wrote: > > Little remainder. > > On 06.05.2016 21:14, Svetlana Nikandrova wrote: >> Hello, >> >> I would be gra

Re: Code Review Request, 8154344 sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java fails on solaris

This looks good. You might need to add a noreg-self to the bug. Thanks Max > On May 11, 2016, at 12:31 PM, Xuelei Fan wrote: > > On 5/10/2016 4:23 PM, Xuelei Fan wrote: >> On 5/10/2016 2:37 PM, Wang Weijun wrote: >>> On May 10, 2016, at 7:58 AM, Xuelei Fan wrote: On 5/10/2016