Re: RFR 8156501: DRBG not synchronized at reseeding

Ping again, and webrev updated at http://cr.openjdk.java.net/~weijun/8156501/webrev.01/ Volatile keyword added to reseedCounter. Thanks Max > On May 9, 2016, at 11:51 AM, Wang Weijun <weijun.w...@oracle.com> wrote: > > Hi All > > Please review the fix at > >

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 <xuelei@oracle.com> wrote: > > On 5/10/2016 4:23 PM, Xuelei Fan wrote: >> On 5/10/2016 2:37 PM, Wang Weijun wrote: >>> >>>> On Ma

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

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

8 PM) $ ls -al /dev/*random > crw-rw-rw- 1 root wheel 11, 0 May 10 16:50 /dev/random > crw-rw-rw- 1 root wheel 11, 1 May 10 16:39 /dev/urandom > > Change looks good. > > Brad > > > > On 5/10/2016 4:23 PM, Wang Weijun wrote: >> Hi All >> >

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

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

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

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 current

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

> 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

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

Security-dev, If we can live with "engine=keystore" happily, why not just make the whole string lowercase and search for "permission=java.io.filepermission"? I don't think there are permission types or URL names that are only different in cases. Although file names are case-sensitive in Unix,

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

an wrote: >> I still want the rest part (public key checking) get executed and >> noticed. I will keep track of the evaluation of the underlying platform >> crypto lib. >> >> Thanks, >> Xuelei >> >>> On 5/7/2016 11:31 AM, Wang Weijun wrote: >

RFR 8156501: DRBG not synchronized at reseeding

Hi All Please review the fix at http://cr.openjdk.java.net/~weijun/8156501/webrev.00 Many thanks to Siba for discovering this problem. I have only benchmarked nextBytes() before. Some clarifications: 1. No need to synchronize configure anymore() because it's always called inside a

Re: SecureRandom serializable?? was: Re: RFR 8154523: SHA1PRNG output should change after reset

> On May 9, 2016, at 4:22 AM, Michael StJohns wrote: > > Does anyone else think there's something wrong with SecureRandom being > serializable? In general, the internal state of a random number generator > shouldn't be extract-able or even savable. You are right.

Re: RFR 8154523: SHA1PRNG output should change after reset

> On May 8, 2016, at 10:26 PM, Xuelei Fan <xuelei@oracle.com> wrote: > > On 5/8/2016 9:06 PM, Wang Weijun wrote: >> Ping again. >> >>> On May 3, 2016, at 10:26 AM, Wang Weijun <weijun.w...@oracle.com> wrote: >>> >&g

Re: RFR 8154523: SHA1PRNG output should change after reset

Ping again. > On May 3, 2016, at 10:26 AM, Wang Weijun <weijun.w...@oracle.com> wrote: > > Hi All > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8154523/webrev.00 > > Basically, a reset in SHA1PRNG should forget the internal state and cached > output. > > Thanks > Max >

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

Or can we put it into problem list for Solaris now? > 在 2016年5月7日，07:19，Xuelei Fan 写道： > > Yes. This is might be a platform crypto lib issue. I want to bring > back the testing at first, and open the test again after the issue get > fixed.

Re: RFR JDK-8000415: Add support for SHA-3

> On May 6, 2016, at 7:44 AM, Valerie Peng wrote: > > > Yes, I think it's better to deal with this before you call the methods in > ByteArrayAccess class. > Your code snippet looks good. > Valerie > Good. Then the only conflict between our changesets is we both

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

Hi Brad I did't expect I need a new updated version at http://cr.openjdk.java.net/~weijun/8051408/webrev.14/ Changes include: 1. The new wording you suggested below. 2. All health-test related codes (even if they were not called in webrev.13 at all) removed. 3. Revert the change in

Re: RFR JDK-8000415: Add support for SHA-3

> On May 5, 2016, at 11:06 AM, Wang Weijun <weijun.w...@oracle.com> wrote: > > So this assumes len % 4 == 0. > > If you follow this, you might need to add Unsafe.putInt for the last 4 bytes. > > On the other hand, if you think len % 8 == 0 should always be tr

Re: RFR JDK-8000415: Add support for SHA-3

Hi Valerie This is not exactly a code review. I noticed you've updated static void l2bBig(long[] in, int inOfs, byte[] out, int outOfs, int len) in ByteArrayAccess.java. I also updated it during the implementation of SHA-512/224 (a part of DRBG) because here len is 28 but the original

RFR 8154523: SHA1PRNG output should change after reset

Hi All Please take a review at http://cr.openjdk.java.net/~weijun/8154523/webrev.00 Basically, a reset in SHA1PRNG should forget the internal state and cached output. Thanks Max

Re: CFV: New Security Group Member: Jamil Nimeh

Vote: Yes. --Weijun > On Apr 29, 2016, at 10:40 PM, Sean Mullan wrote: > > I hereby nominate Jamil Nimeh to Membership in the Security Group.

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

> On Apr 29, 2016, at 2:46 AM, Bradford Wetmore > wrote: > > to completely fill the > buffer before returning from this method. This is more clear. I'll update but will not send out a new webrev. Thanks Max

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

http://cr.openjdk.java.net/~weijun/8051408/webrev.13 http://cr.openjdk.java.net/~weijun/8051408/webrev.13/spec http://cr.openjdk.java.net/~weijun/8051408/webrev.13/specdiff Another update. 1. Comment out health test for the moment. 2. Remove the following words in SecureRandom#nextBytes: -

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

> On Apr 28, 2016, at 8:50 AM, Bradford Wetmore > wrote: > > I won't have the cycles to do another full review, but just looked over > things I mentioned in my previous review, and things are looking good! I have > to jump back to my other projects. Thanks,

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

Webrev updated: http://cr.openjdk.java.net/~weijun/8051408/webrev.12 http://cr.openjdk.java.net/~weijun/8051408/webrev.12/spec http://cr.openjdk.java.net/~weijun/8051408/webrev.12/specdiff 1am now and I will reread the changes tomorrow. This is the result of 3 days' intense work and I hope I

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

> On Apr 27, 2016, at 3:27 AM, Bradford Wetmore <bradford.wetm...@oracle.com> > wrote: > > > > On 4/25/2016 11:25 PM, Wang Weijun wrote: >> >>> On Apr 26, 2016, at 8:48 AM, Bradford Wetmore <bradford.wetm...@oracle.com> >>> wrote: &

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

> On Apr 26, 2016, at 8:48 AM, Bradford Wetmore > wrote: > > but the runtime "Health Testing" I was talking about is in the diagram of > Section 7, and details in section 11.3: I haven't touched this area yet. If you think it's necessary, I would like to add the

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

>> http://cr.openjdk.java.net/~weijun/8051408/webrev.11/ >> http://cr.openjdk.java.net/~weijun/8051408/webrev.11/spec >> http://cr.openjdk.java.net/~weijun/8051408/webrev.11/specdiff Thanks for the review. I copied your DRBG.txt below with my comments. Most are accepted, some I mentioned my

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

> On Apr 21, 2016, at 9:44 PM, Xuelei Fan wrote: > >>> public MyCertStore extends CertStoreSpi { >>> >>> public MyCertStore() { >>> // whatever >>> // ;-) Don't ask me why this construct is necessary. >>> } >>> >>> public MyCertStore(XXX params) { >>>

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

Hi All Webrev updated again at http://cr.openjdk.java.net/~weijun/8051408/webrev.11/ http://cr.openjdk.java.net/~weijun/8051408/webrev.11/spec http://cr.openjdk.java.net/~weijun/8051408/webrev.11/specdiff Changes since webrev.10: - DRBG's generateSeed() will directly read from

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

> On Apr 20, 2016, at 9:35 AM, Xuelei Fan <xuelei@oracle.com> wrote: > > On 4/20/2016 9:17 AM, Wang Weijun wrote: >> >>> On Apr 20, 2016, at 7:41 AM, Xuelei Fan <xuelei@oracle.com> wrote: >>> >>> On 4/19/2016 11:41 PM, Wang Wei

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

> On Apr 21, 2016, at 8:07 AM, Xuelei Fan wrote: > >> I'll model after Authenticator. That would need some synchronization. >> > You have already make synchronization. You mean synchronized for instantiateIfNecessary? But this time I need to synchronize on cc which is

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

> On Apr 20, 2016, at 11:13 PM, Xuelei Fan wrote: > >> Really? You are worried about more than 2^64 instances of DRBG? >> > SSL/TLS considers record sequence number wrapping, too. The nonce > require at least half-strength randomness, I would like to follow this >

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

> On Apr 21, 2016, at 3:06 AM, Bradford Wetmore > wrote: > > >>> 175: Should we add DRBG:SUN as a backup for non-windows? >> >> If NativePRNGBlocking:SUN is not always available, yes we can. > > It should be available, unless someone decides to blow away

Re: RFR: 8154231: Simplify access to System properties from JDK code

This is quite convenient. We not cover the other modules? exports sun.security.action to java.desktop, java.security.jgss, jdk.crypto.pkcs11; Thanks Max > On Apr 20, 2016, at 10:44 PM, Claes Redestad > wrote: > > Hello, > > now that the

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

> On Apr 20, 2016, at 12:00 PM, Wang Weijun <weijun.w...@oracle.com> wrote: > >> src/java.base/share/classes/sun/security/provider/AbstractDrbg.java >> === >> line 66-68: My understanding is that ...

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

> On Apr 20, 2016, at 12:53 PM, Xuelei Fan <xuelei@oracle.com> wrote: > > On 4/20/2016 12:00 PM, Wang Weijun wrote: >> >>> On Apr 20, 2016, at 11:34 AM, Xuelei Fan <xuelei@oracle.com> wrote: >>> >>> On 4/19/2016 9:09

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

> On Apr 20, 2016, at 11:34 AM, Xuelei Fan wrote: > > On 4/19/2016 9:09 PM, Xuelei Fan wrote: >> On 4/15/2016 9: >>> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ > > src/java.base/share/classes/sun/security/provider/AbstractDrbg.java >

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

> On Apr 20, 2016, at 8:54 AM, Bradford Wetmore > wrote: > > > Webrev updated again at > > > > http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ > > http://cr.openjdk.java.net/~weijun/8051408/webrev.10/spec > >

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

> On Apr 20, 2016, at 7:41 AM, Xuelei Fan <xuelei@oracle.com> wrote: > > On 4/19/2016 11:41 PM, Wang Weijun wrote: >>>>>> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ >>>> >>>> Please update copyright dates. >>&

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

> On Apr 19, 2016, at 9:09 PM, Xuelei Fan wrote: > > On 4/15/2016 9: >> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ > > Please update copyright dates. > > src/java.base/share/classes/java/security/Provider.java >

Re: JGSS fails with KrbException: Message stream modified (41) on cross-realm intermediate/unexpected TGT

> On Apr 19, 2016, at 8:48 PM, Osipov, Michael > wrote: > >>> Are there any plans to add referral support? >> >> Not yet. >> >>> Can we log this issue in bugs.openjdk.java.net/browse/JDK? >> >> You can always do that, but such a feature should be covered by a

Re: JGSS fails with KrbException: Message stream modified (41) on cross-realm intermediate/unexpected TGT

> > Are there any plans to add referral support? Not yet. > Can we log this issue in bugs.openjdk.java.net/browse/JDK? You can always do that, but such a feature should be covered by a JEP. --Max

Re: JGSS fails with KrbException: Message stream modified (41) on cross-realm intermediate/unexpected TGT

If you are sure the exception is thrown from the code snippet you quoted, that is because Java's Kerberos 5 implementation requires that the service name in TGS_REP must match the one in the TGS_REQ. Otherwise it fails. MIT and SSPI support referral so the names can be different. The

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

> On Apr 19, 2016, at 5:41 PM, Xuelei Fan <xuelei@oracle.com> wrote: > > On 4/19/2016 4:05 PM, Wang Weijun wrote: >>>> 2. DrbgParameters.Instantiate >>>> Looks like this class would be better to an extendable individual class. >>>> Declare

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

know after compiled they will be different classes but putting the source code in one place makes me more comfortable. Thanks Max > > Otherwise, the spec looks fine to me. > > Xuelei > > On 4/15/2016 9:35 PM, Wang Weijun wrote: >> Hi All >> >> Webrev

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

know after compiled they will be different classes but putting the source code in one place makes me more comfortable. Thanks Max > > Otherwise, the spec looks fine to me. > > Xuelei > > On 4/15/2016 9:35 PM, Wang Weijun wrote: >> Hi All >> >> Webrev updated ag

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

rbg.reseed(); } } 3. More descriptive text in exception thrown. Thanks Max > On Apr 5, 2016, at 10:34 AM, Wang Weijun <weijun.w...@oracle.com> wrote: > > Updated webrev again at > > http://cr.openjdk.java.net/~weijun/8051408/webrev.09/ > http://cr.openjdk.java.

Re: RFR: [9]: 8151834: Test SmallPrimeExponentP.java times out intermittently

Looks good. Btw, since there is already the @requires tag, I think lines 52-56 are no longer needed. Thanks Max > 在 2016年4月15日，03:44，Rajan Halade 写道： > > Hi Max, > > Please review this patch to fix SmallPrimeExponentP test. It now uses fixed > seed value to

Re: RFR 8153545: sun/security/pkcs11/Provider/Login.sh fails on Linux

k.java.net/~amjiang/8153545/webrev.03/ > JPRT run is completed and all 3 tests has been passed in all platforms ( > except Login.sh is excluded from windows platform by other bug) > Thanks, > Amanda > > On 16/4/11 下午6:26, Wang Weijun wrote: >> Hi Amanda and Artem, >>

Re: RFR 8153545: sun/security/pkcs11/Provider/Login.sh fails on Linux

Hi Amanda and Artem, >>> http://cr.openjdk.java.net/~amjiang/8153545/webrev.02/ So, if "Clazz sm [policy]" is the preferred way to launch a test and we don't care about access controls outside the main(Provider) method, I'm OK with the fix. There is a KeyStore/Solaris.sh test using

Re: RFR 8153545: sun/security/pkcs11/Provider/Login.sh fails on Linux

hould be the correct argument. > I updated the test argument and PKCS11Test, please check the new webrev: > http://cr.openjdk.java.net/~amjiang/8153545/webrev.02/ > > Thanks, > Amanda > > On 16/4/8 上午12:28, Wang Weijun wrote: >> Hi Amanda >> >> I am not familia

Re: RFR 8153545: sun/security/pkcs11/Provider/Login.sh fails on Linux

Hi Amanda I am not familiar with the tests, but it looks like the 1st args argument should be "sm" [1] to enable the security manager, not "true". If PKCS11Test always uses args as command and optional argument(s), maybe you should throw an exception if the command is unknown. Thanks Max [1]

Re: [8u-dev] Request for Review + Request for Approval for Backport : 8048147: Privilege tests with JAAS Subject.doAs + 8076486 (test's fix)

The jdk8 changeset looks fine. Thanks, Max > On Apr 5, 2016, at 9:58 PM, Svetlana Nikandrova > wrote: > > Hello, > > please review and approve the backport of tests enhancement: > Original test from > https://bugs.openjdk.java.net/browse/JDK-8048147 > jdk 9

Re: [8u-dev] Request for Review + Request for Approval for Backport : 8048147: Privilege tests with JAAS Subject.doAs + 8076486 (test's fix)

The jdk8 changeset looks fine. Thanks, Max > On Apr 5, 2016, at 9:58 PM, Svetlana Nikandrova > wrote: > > Hello, > > please review and approve the backport of tests enhancement: > Original test from > https://bugs.openjdk.java.net/browse/JDK-8048147 > jdk 9

Re: RFR 8152205: jdk.security.provider.preferred is ambiguously documented

In my DRBG changeset, I use this style: {@code jdk.security.provider.preferred} {@linkplain Security#getProperty(String) security property} --Max > On Apr 7, 2016, at 8:23 AM, Bradford Wetmore > wrote: > > If I was doing this from scratch, I would probably

RFR: draft-ietf-kitten-rfc5653bis-03 JGSS-API

s-03.txt > has been successfully submitted by Wang Weijun and posted to the > IETF repository. > > Name: draft-ietf-kitten-rfc5653bis > Revision: 03 > Title:Generic Security Service API Version 2: Java Bindings > Update > Document date:2016-0

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

e 'part' string in this exception. > > +} else { > +throw new IllegalArgumentException("Unsupported params"); > +} > > can you print the type of params that were passed in ? > > +default: > + throw new Illega

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

and SecureRandomReseedParameters are removed and only a single SecureRandomParameters is added. There seems no reason to introduce 3 marker interfaces. Thanks Max > On Apr 1, 2016, at 7:34 PM, Wang Weijun <weijun.w...@oracle.com> wrote: > > Hi All > > Updated

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

Hi All Updated webrev at http://cr.openjdk.java.net/~weijun/8051408/webrev.08/ http://cr.openjdk.java.net/~weijun/8051408/webrev.08/spec http://cr.openjdk.java.net/~weijun/8051408/webrev.08/specdiff Spec changes: - More text in @implNote of DrbgParameters.java, which somehow matches

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

Oops. I suddenly realize something wrong about the drbg security property. Hash_DRBG can use SHA-512/224 and it includes a slash. --Max

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

throw IllegalArgumentExceptions if int params are less than > a certain value or if maxLength < minLength? Does it return a new byte array > each time it is invoked? Yes and yes, but I haven't checked/documented it since it's not a public API yet. Thanks Max > > --Sean > &g

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

Ping again. No comment? --Max > On Mar 21, 2016, at 1:15 PM, Wang Weijun <weijun.w...@oracle.com> wrote: > > Hi All > > Please take a review at the design and implementation of DRBG at: > > http://cr.openjdk.java.net/~weijun/8051408/webrev.07 > http://cr.op

Re: Code Review Request, 8152237 Support BigInteger.TWO

> On Mar 23, 2016, at 7:23 PM, Xuelei Fan <xuelei@oracle.com> wrote: > > On 3/23/2016 5:44 PM, Wang Weijun wrote: >> Then why not fix the 2 bugs in a single changeset? >> > Both need spec update approval. As they are completely different spec > update, b

Re: Code Review Request, 8152237 Support BigInteger.TWO

Then why not fix the 2 bugs in a single changeset? --Max > 在 2016年3月23日，17:06，Xuelei Fan <xuelei@oracle.com> 写道： > >> On 3/23/2016 3:34 PM, Wang Weijun wrote: >> >>> On Mar 23, 2016, at 12:48 PM, Xuelei Fan <xuelei@oracle.com> wrote: >>&g

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

> >> The SunPKCS11 compatibility line will be add in a sub-patch for jake. >> > > You can send me the jake’s delta patch once you push the change to jdk9/dev. I've been busy recently on DRBG and will be back working on this one. Now that jake/m3 is in jdk9/dev I assume I will just include the

Re: Code Review Request, 8152237 Support BigInteger.TWO

> On Mar 23, 2016, at 12:48 PM, Xuelei Fan <xuelei@oracle.com> wrote: > > On 3/23/2016 12:10 PM, Wang Weijun wrote: >> Only 3 files touched. Are you going to make the >> s/BigInteger.valueOf(2)/BigInteger.TWO/ changes in other files with another >> b

Re: Code Review Request, 8152237 Support BigInteger.TWO

Only 3 files touched. Are you going to make the s/BigInteger.valueOf(2)/BigInteger.TWO/ changes in other files with another bug fix? Thanks Max > On Mar 23, 2016, at 11:26 AM, Xuelei Fan wrote: > > Hi, > > Please review the update for the supporting of BigInteger.TWO:

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

> On Mar 21, 2016, at 1:23 PM, Wang Weijun <weijun.w...@oracle.com> wrote: > > >> On Mar 21, 2016, at 1:15 PM, Wang Weijun <weijun.w...@oracle.com> wrote: >> >>if (ins.getCapability() != NONE) { > > Ah, should be > > if (ins.getCap

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

> On Mar 21, 2016, at 1:15 PM, Wang Weijun <weijun.w...@oracle.com> wrote: > > if (ins.getCapability() != NONE) { Ah, should be if (ins.getCapability() != NONE && ins.getCapability() != PR_ONLY) { --Max

RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

Hi All Please take a review at the design and implementation of DRBG at: http://cr.openjdk.java.net/~weijun/8051408/webrev.07 http://cr.openjdk.java.net/~weijun/8051408/webrev.07/spec http://cr.openjdk.java.net/~weijun/8051408/webrev.07/specdiff/overview-summary.html An example: SecureRandom

Re: Code Review Request, 8152221 Use try-with-resource in test templates

Great, looks fine. Thanks Max > On Mar 19, 2016, at 10:16 PM, Xuelei Fan wrote: > > Hi, > > Please review this test update for JDK-8152221: > > http://cr.openjdk.java.net/~xuelei/8152221/webrev.00/ > > The templates for SSL/TLS implementation testing are updated to

Re: [9] RFR: 8151734: Mark Unreachable.java and MaxRetries.java as intermittently failing

The change looks fine. Thanks Max > On Mar 12, 2016, at 6:07 AM, Artem Smotrakov > wrote: > > Hello, > > The following krb5 tests have been observed to intermittently fail: > > sun/security/krb5/auto/Unreachable.java > sun/security/krb5/auto/MaxRetries.java > >

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

> On Feb 26, 2016, at 1:03 AM, Sean Mullan wrote: > > On 02/18/2016 03:10 AM, Weijun Wang wrote: >> There is another compatibility issue which is more important: >> >> Today, we tell users to load their own PKCS11 provider with >> >> -providerClass

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

AM, Wang Weijun <weijun.w...@oracle.com> wrote: > > >>> >>> You mean not supporting all pre-loaded providers in modules, but only one >>> or two popular ones? >>> >> >> I meant not support -providerClass for arbitrary providers

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

>> >> You mean not supporting all pre-loaded providers in modules, but only one or >> two popular ones? >> > > I meant not support -providerClass for arbitrary providers loaded via service > loader. The only exception is SunPKCS11. In other words, -providerClass can > only be used to load

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

>>> >>> 303 // A provider in module can also be use class name >>> 304 if (p.getClass().getName().equals(provClass)) { >>> >>> ProviderConfig::getProvider doesn’t compare the classname. I thought we >>> agree to discourage the use of -providerClass to load a provider and

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

feedback from you. Please respond. Thanks Max > On Feb 19, 2016, at 6:47 PM, Wang Weijun <weijun.w...@oracle.com> wrote: > > Updated at the same URL > > http://cr.openjdk.java.net/~weijun/8130302/webrev.01 > > The help looks like this now: > > -provide

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

> On Feb 20, 2016, at 4:01 AM, Mandy Chung <mandy.ch...@oracle.com> wrote: > > >> On Feb 19, 2016, at 2:47 AM, Wang Weijun <weijun.w...@oracle.com> wrote: >> >> Updated at the same URL >> >> http://cr.openjdk.java.net/~weijun/81

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

> On Feb 19, 2016, at 6:58 PM, Alan Bateman wrote: > > One other thing is whether we should add a section to JEP 261 on these tool > updates. I had originally assumed that the updates to these tools would > follow the module system into JDK 9 but you've turned up

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

classname [-providerArg ] configure argument for -providerclass --Max > On Feb 19, 2016, at 5:58 PM, Wang Weijun <weijun.w...@oracle.com> wrote: > > >> On Feb 19, 2016, at 5:36 PM, Alan Bateman <alan.bate...@oracle.com> wrote: >> >> &g

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

> On Feb 19, 2016, at 5:36 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > > On 19/02/2016 09:07, Wang Weijun wrote: >> : >> I don't want the line to be too long. Is the preferred terminal width still >> 80 now? I noticed the java help outpu

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

> On Feb 19, 2016, at 4:42 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 19/02/2016 08:22, Wang Weijun wrote: >> A new webrev at >> >>http://cr.openjdk.java.net/~weijun/8130302/webrev.01/ >> >> The options for keytool have >> &

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

A new webrev at http://cr.openjdk.java.net/~weijun/8130302/webrev.01/ The options for keytool have -provider [-providerArg ]add a provider by name -providerclass [-providerArg ] add a provider by classname (omit some words because line is too long) for jarsigner [-provider

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

> On Feb 18, 2016, at 9:21 AM, Mandy Chung <mandy.ch...@oracle.com> wrote: > >> >> On Feb 17, 2016, at 4:46 PM, Wang Weijun <weijun.w...@oracle.com> wrote: >> >> >>> On Feb 18, 2016, at 5:15 AM, Mandy Chung <mandy.ch...@oracle.com&g

Re: Code Review Request 8149417 Use final restricted flag

IMO a noreg-trivial is enough. --Max > 在 2016年2月18日，09:28，Xuelei Fan 写道： > > Hi, > > A new test case was added. Please review the update: > > http://cr.openjdk.java.net/~xuelei/8149417/webrev.01/ > > Thanks, > Xuelei > >> On 2/15/2016 9:07 PM, Sean Mullan wrote:

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

> On Feb 18, 2016, at 5:15 AM, Mandy Chung wrote: > > Can I say -providerClass -providerArg is equivalent to extending > java.security to add “security.provider.N=NAME ARG”? Yes. > > I suggest to keep -providerClass and -providerArg only for legacy security >

Re: RFR 8147772: Some KerberosTicket methods throw NPE after being destroyed

Webrev updated at http://cr.openjdk.java.net/~weijun/8147772/webrev.01/ with javadoc changes. Please review again. Thanks Max > On Jan 20, 2016, at 10:22 PM, Wang Weijun <weijun.w...@oracle.com> wrote: > > >> On Jan 20, 2016, at 10:18 PM, Sean Mullan <sean.

Re: RFR : 8038837:Add support to jarsigner for specifying timestamp hash algorithm

Why did you remove the JarSignerParameters class definition inside jarsigner/Main.java? Was it duplicated somewhere else? Thanks Max > On Jan 27, 2016, at 11:09 PM, Seán Coffey wrote: > > Hi, > > I'd like to backport this enhancement to JDK 8u. It's been approved via

Re: RFR : 8038837:Add support to jarsigner for specifying timestamp hash algorithm

into its own separate class. Oh, yes. > Shall I revert ? No. It's not a good practice putting 2 top level classes into one file. Was that the compiler is complaining about? Thanks Max > > Regards, > Sean. > > On 29/01/16 11:42, Wang Weijun wrote: >> Why did you re

RFR 8147400: Deprecate policytool

Hi All Please review the patch below. Every change after line 873 is adding "@SuppressWarnings("deprecation")" to a top-level class that references the PolicyTool class. I wish they were static inner classes. We also planned to add "Note: The policytool tool has been deprecated since JDK 9

Re: An issue with keytool and PKCS11

Can you add a -debug option and show me the full output? You can also add a -J-Djava.security.debug=all but I am not sure if the output is useful. --Max > On Jan 12, 2016, at 9:38 AM, Mark Joseph wrote: > > Hi, > >We are a PKCS#11 vendor and we are in the process of

Re: RFR 8147772: Some KerberosTicket methods throw NPE after being destroyed

You mean let them throw an ISE after destroyed? Not sure if it is backportable. The problem is reported by customers using an old JRE. --Max > On Jan 20, 2016, at 9:36 PM, Sean Mullan <sean.mul...@oracle.com> wrote: > > On 01/19/2016 10:32 PM, Wang Weijun wrote: >> http:

Re: RFR 8147772: Some KerberosTicket methods throw NPE after being destroyed

> On Jan 20, 2016, at 10:18 PM, Sean Mullan <sean.mul...@oracle.com> wrote: > > On 01/20/2016 09:13 AM, Wang Weijun wrote: >> >>> On Jan 20, 2016, at 10:14 PM, Sean Mullan <sean.mul...@oracle.com> wrote: >>> >>> On 01/20/2016 08:52 AM,

Re: RFR 8147772: Some KerberosTicket methods throw NPE after being destroyed

> On Jan 20, 2016, at 10:14 PM, Sean Mullan <sean.mul...@oracle.com> wrote: > > On 01/20/2016 08:52 AM, Wang Weijun wrote: >> You mean let them throw an ISE after destroyed? Not sure if it is >> backportable. > > No, I am just talking about

RFR 8147772: Some KerberosTicket methods throw NPE after being destroyed

http://cr.openjdk.java.net/~weijun/8147772/webrev.00/ No spec change, just safer return value. Thanks Max

Re: RFR 8058778: New APIs for creating certificates and certificate requests

> On Jan 13, 2016, at 9:51 PM, David M. Lloyd wrote: > >> The current behavior is that it will consume one BEGIN...END block >> (with optional text before the block) or one DER SEQUENCE, or undefined if >> no such data structure are found. However, I am not

Re: RFR 8058778: New APIs for creating certificates and certificate requests

Hi David > On Jan 13, 2016, at 8:08 PM, David M. Lloyd <david.ll...@redhat.com> wrote: > > On 01/12/2016 07:02 PM, Wang Weijun wrote: >> A new webrev at >> >> http://cr.openjdk.java.net/~weijun/8058778/webrev.09/ > > A couple of questions/comments

Re: Design review: JEP 273: DRBG-Based SecureRandom Implementations

nce at the moment. Thanks Max > On Nov 21, 2015, at 10:40 PM, Wang Weijun <weijun.w...@oracle.com> wrote: > > >> On Nov 20, 2015, at 8:23 AM, Wang Weijun <weijun.w...@oracle.com> wrote: >> >>>> 2. For each of these, if you have getInstance(alg, params), ther

Re: RFR 8058778: New APIs for creating certificates and certificate requests

ar with non-X.509 certs, but hopefully there is also the concept of self-signed cert else where. --Max > > On Tue, Jan 12, 2016 at 8:09 PM, Wang Weijun <weijun.w...@oracle.com> wrote: > Another thing. > > Many people only generates self-signed certificates. Sha

<    1   2   3   4   5   6   7   >