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

> Still one TODO in X509Certificate.Builder subject(String name). Not an issue any more. With buildSelfSignedCertificate(kp), there is no need for buildCertificate(request, kp, name) anymore. Hurray! --Max

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

webrev.09 updated at the same URL. + Certificate.Builder#buildSelfSignedCertificate(KeyPair) - X509Certificate.Builder#buildCertificate(CertificateRequest, KeyPair, X500Principal) --Max > On Jan 13, 2016, at 9:02 AM, Wang Weijun <weijun.w...@oracle.com> wrote: > > A new webr

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

tificateRequest > > 125 * @return the encoded form of this certificate request > 126 */ > 127 public abstract byte[] getEncoded(); > > Should say that it returns a new byte array each time it is called. OK. Thanks Max > > --Sean > > On 01/11/2016

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

Another thing. Many people only generates self-signed certificates. Shall we make this simple? For example, using buildCertificate(null, KeyPair, null)? Thanks Max

Re: Code Review Request JDK-8146387, Test SSLSession/SessionCacheSizeTests socket accept timed out

Can you make sure every read to serverPorts is after serverReady = true? I hope so but cannot confirm it, especially in the constructor (on line 342 etc). Or shouldn't you always start the server at port 0 and then read it into serverPorts? You want to start a server on the same port on and on?

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

not the same level. I'd prefer to remove subject(String). It's just a short form and no more efficient than subject(X500Principal). Thanks Max > On Jan 9, 2016, at 8:57 AM, Wang Weijun <weijun.w...@oracle.com> wrote: > >> >> On Jan 9, 2016, at 4:40 AM, Sean Mullan <se

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

Another thing to discuss: Now SubjectKeyIdentifier and AuthorityKeyIdentifier are automatically added. Should they only be added when requested? Thanks Max > On Jan 11, 2016, at 3:59 PM, Wang Weijun <weijun.w...@oracle.com> wrote: > > Once again > > http://cr.openjdk.jav

Re: Code Review Request JDK-8146387, Test SSLSession/SessionCacheSizeTests socket accept timed out

>> >>> You want to start a server on the same port on and on? >>> >> Not actually. Different port are used for different server socket. The >> logic looks like: >> // define four slots for the ports >> int serverPorts[] = new int[]{0, 0, 0, 0}; >> >> // for each slot, create a server

Re: Code Review Request JDK-8146387, Test SSLSession/SessionCacheSizeTests socket accept timed out

> On Jan 11, 2016, at 7:02 PM, Xuelei Fan <xuelei@oracle.com> wrote: > > On 1/11/2016 5:43 PM, Wang Weijun wrote: >> >>>> >>>>> You want to start a server on the same port on and on? >>>>> >>>> Not actually. Diff

Re: Code Review Request JDK-8146725 Issues with SignatureAndHashAlgorithm.getSupportedAlgorithms

Looks fine. Thanks Max > On Jan 9, 2016, at 8:44 AM, Xuelei Fan wrote: > > Hi, > > Please review this simple fix for JDK-8146725. > > In the SignatureAndHashAlgorithm.getSupportedAlgorithms() method, there > is a synchronization block on a static final collection,

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

> On Jan 9, 2016, at 4:40 AM, Sean Mullan <sean.mul...@oracle.com> wrote: > > On 01/07/2016 10:38 PM, Wang Weijun wrote: >> >>> On Jan 8, 2016, at 6:06 AM, Sean Mullan <sean.mul...@oracle.com> >>> wrote: > >>> * CertificateFactor

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

s has the same problem. I consider this not a feature but a bug. Every public available Certificate and CertificateRequest objects should be encoded and signed and immutable. I'll remove that exception from getCertificationRequestInfo(). We need to make sure that unsigned and unencod

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

by not creating arrays it cannot create exceeding bytes. > > The default impl for the pos/len is to call fillEntropy(out, partial, 0, > out.length). It might not be needed however. These methods will prevent unnecessary System.arraycopy(). Will consider. Thanks Max > > Ber

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

> On Jan 6, 2016, at 5:53 PM, e...@zusammenkunft.net wrote: > > Hello, > > Wang Weijun <weijun.w...@oracle.com>: >>> On Jan 6, 2016, at 3:31 PM, e...@zusammenkunft.net wrote: >>> is the Intention of the default implementation of getFullEntropy to ex

Re: CallbackHandler updates?

> On Jan 6, 2016, at 1:35 AM, Richard Levenberg wrote: > > Is there any work planned for the javax.security.auth.callback.* package > and the provided com.sun.security.auth.callback.TextCallbackHandler? No. > > Specifically it would be nice if the readLine method were

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

eed} > 95 * methods was previously called. > > s/one of/the/ > s/methods/method/ > > 97 * A SecureRandom can be reseeded at any time by calling one of the > > s/one of the/the/ > s/methods/method/ > > 883 * {@code additionalInput} may contain entropy

Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

I have no more comment. --Max > On Jan 3, 2016, at 3:48 PM, Sibabrata Sahoo <sibabrata.sa...@oracle.com> > wrote: > > Updated the bug title and description. > > Thanks, > Siba > > -----Original Message- > From: Wang Weijun > Sent: Sunday, January

RFR 8146377: test/sun/security/tools/jarsigner/concise_jarsigner.sh failing

Hi Please review the fix of https://bugs.openjdk.java.net/browse/JDK-8146377. Some years have more days than 365 and the test fails. The fix is simply diff --git a/test/sun/security/tools/jarsigner/concise_jarsigner.sh b/test/sun/security/tools/jarsigner/concise_jarsigner.sh ---

Re: RFR 8146377: test/sun/security/tools/jarsigner/concise_jarsigner.sh failing

> On Jan 4, 2016, at 4:19 PM, Xuelei Fan <xuelei@oracle.com> wrote: > > An interesting bug. Looks fine to me. Yes, I could have closed it as "Not Reproducible" and wait for another 4 years to fix it. --Max > > Xuelei > > On 1/1/2016 1:26 AM, W

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

nicer to avoid exposing > that in the API. Have you considered defining this as an interface, with a > static method that returns an instance with an EntropyInput, ex: > > public interface SecureRandomParameters { > >EntropyInput getEntropyInput(); > >static Secur

Re: RFR [9] 8145544: Move sun.misc.VM to jdk.internal.misc

I am OK with the change for krb5 in both src and test. Thanks Max > On Jan 4, 2016, at 10:02 PM, Chris Hegarty wrote: > > sun.misc.VM provides a low-level interface for a small number > of specific operations with the VM. In preparation for JEP 260, > this class

Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

> Thanks, > Siba > > -Original Message- > From: Wang Weijun > Sent: Monday, December 21, 2015 7:20 AM > To: Sibabrata Sahoo > Cc: Mandy Chung; Valerie Peng; jigsaw-...@openjdk.java.net; > security-dev@openjdk.java.net > Subject: Re: [9] RFR:8130360: Add tes

Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

Then you don't need to include the "signed/unsigned" words in the bug description. --Max > On Jan 3, 2016, at 2:30 PM, Sibabrata Sahoo > wrote: > > Hi Max, > > The test is for verifying 3rd party security provider in > classpath/modulepath. I am using an empty

Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

Tests are good. Several comments: 1. Try run something like "hg mv -A" to let Mercurial knows that you are renaming files (SecurityUtils.java and those in login/modules/src) instead of removing some old and creating some new. The current webrev does not show this. 2. It's not a good practice

Re: RFR 8058778: New APIs for some keytool functions

sName(String host); ... static newSubjectAlternativeNameExtension(boolean isCritical, GenralName... names); class AccessDescription { String oidMethods, GeneralName location); static newAuthorityInformationAccessExtension(AccessDescription... accessDescriptions); I tried it but I don't l

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

Good. But the builder will not provide default values so you will see new DrbgParameters.Builder().build().getAlgorithm() == null which means the getters still return requested values. In this case, the algorithm will only be known after it is used for a specific DRBG, for example, SHA-256

Re: RFR 8058778: New APIs for some keytool functions

thanks to Mandy, Larry, and Sean for your comments. Mike, we will add more methods later when they are needed. --Max > On Dec 15, 2015, at 11:53 PM, Sean Mullan <sean.mul...@oracle.com> wrote: > > On 12/03/2015 09:07 PM, Wang Weijun wrote: >> Or if this is too muc

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

gt; wrote: > > On 12/15/2015 03:09 AM, Wang Weijun wrote: >> Good. >> >> But the builder will not provide default values so you will see >> >> new DrbgParameters.Builder().build().getAlgorithm() == null >> >> which means the getters still return requested

Re: Code Review Request, 8136410 AlgorithmDecomposer is not parsing padding correctly

The code change looks ok. You might want to rename the test from Decomposealgorithms to DecomposeAlgorithms. However, I am not sure if this is the ultimate solution. IMHO, it will be nice to provide several patterns, say, within etc and provide a supported list for each category (hash, kp,

Re: Code Review Request 8141593 Test RetryHttps timed out intermittently

Change looks fine. Best luck. Thanks Max > On Dec 7, 2015, at 10:52 AM, Xuelei Fan wrote: > > Hi Weijun, > > Are you available review this patch for JDK-8141593? > >http://cr.openjdk.java.net/~xuelei/8141593/webrev.00/ > > Test RetryHttps.java timed out

RFR 8138638: Security tests using jdk/test/sun/security/krb5/auto/KDC.java fail intermittently with OutOfMemoryError

Please review the fix at http://cr.openjdk.java.net/~weijun/8138638/webrev.00/ It looks like the TCP server should be accessed in the failed tests. Maybe a random process happens to connect to the server? This code change will ignore the unknown request. Thanks Max

Re: RFR 8138638: Security tests using jdk/test/sun/security/krb5/auto/KDC.java fail intermittently with OutOfMemoryError

Its caught 5 lines below and then ignored. --Max > 在 2015年12月7日，12:02，Xuelei Fan <xuelei@oracle.com> 写道： > >> On 12/7/2015 11:51 AM, Wang Weijun wrote: >> Please review the fix at >> >> http://cr.openjdk.java.net/~weijun/8138638/webrev.00/ >&g

Re: RFR 8058778: New APIs for some keytool functions

rry about it at the moment. we can add an overloaded method later) without looking at the content. If a real CA decides to use the API, it will need to call some other 3rd party tools to inspect the content. Thanks Max > > Mike > > > On 12/

Re: RFR 8058778: New APIs for some keytool functions

I tried. It's quite easy to move the new X509CertificateBuilder class into java.security.cert.X509Certificate as an inner class, but I still want to make Extension and CertificateRequest better. Extension - Turns out java.security.cert.Extension is already defined for X.509, and there

Re: RFR 8058778: New APIs for some keytool functions

() for the future. :-) --Max > On Dec 3, 2015, at 8:21 PM, larry mccay <larry.mc...@gmail.com> wrote: > > +1 :) > > On Thu, Dec 3, 2015 at 3:31 AM, Wang Weijun <weijun.w...@oracle.com> wrote: > I tried. > > It's quite easy to move

RFR 8058778: New APIs for some keytool functions

Hi All This enhancement creates a new jdk.security.cert.X509CertificateBuilder API that does what keytool -genkeypair/-certreq/-gencert can do. code changes: http://cr.openjdk.java.net/~weijun/8058778/webrev.04 http://cr.openjdk.java.net/~weijun/8058778/dev/webrev.01/ spec:

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

> On Dec 2, 2015, at 11:26 PM, Chris Hegarty <chris.hega...@oracle.com> wrote: > > Thanks Max, > > I'm ok with this version, if you are. I'll include it in the final push. Please. --Max > > -Chris. > > On 02/12/15 15:13, Wang Weijun wrote: >> >&

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

My fault to use an internal class. I should have simply used the hex encoding. Please wait a while and I'll send you a fix. Thanks Max > On Dec 2, 2015, at 10:15 PM, Chris Hegarty wrote: > > On 02/12/15 14:03, Alan Bateman wrote: >> >> On 02/12/2015 12:08, Chris

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

> On Dec 2, 2015, at 10:52 PM, Wang Weijun <weijun.w...@oracle.com> wrote: > > My fault to use an internal class. I should have simply used the hex > encoding. Please wait a while and I'll send you a fix. > > Thanks > Max S11N.java Description: Binary data

Re: RFR 8058778: New APIs for some keytool functions

ava.security.cert.Extension- > > Mandy > >> On Dec 2, 2015, at 6:36 AM, Wang Weijun <weijun.w...@oracle.com> wrote: >> >> Hi All >> >> This enhancement creates a new jdk.security.cert.X509CertificateBuilder API >> that does what

Re: RFR 8058778: New APIs for some keytool functions

ava.security.cert.X509Certificate.Builder? > > Mandy > > > On Dec 2, 2015, at 6:36 AM, Wang Weijun <weijun.w...@oracle.com> wrote: > > > > Hi All > > > > This enhancement creates a new jdk.security.cert.X509CertificateBuilder API > > that does what

Re: Code Review Request 8143298 Test ReadTimeout.java fails intermittently

Everything looks fine now. Thanks Max > On Dec 2, 2015, at 10:48 AM, Xuelei Fan <xuelei@oracle.com> wrote: > > On 12/2/2015 10:20 AM, Wang Weijun wrote: >> >>> On Dec 2, 2015, at 9:12 AM, Xuelei Fan <xuelei@oracle.com> wrote: >>>

Re: Code Review Request 8143298 Test ReadTimeout.java fails intermittently

Socket is a Closeable, so you can try (Socket sock = ) { ... } If you want more debug messages, why not e.printStackTrace()? Message is enough? Thanks Max > On Dec 2, 2015, at 8:55 AM, Xuelei Fan wrote: > > Hi, > > Please review the test fix for JDK-8143298: >

Re: S4U2Self and OpenJDK 8

> On Dec 2, 2015, at 1:59 AM, Marc Boorshtein > wrote: > > Max, > > Closing the loop on this. It turns out that there was an extra step > needed to get the user in freeipa setup as a delegate (the > documentation was written for S4U2Proxy, not S4U2Self).

Re: Code Review Request 8143298 Test ReadTimeout.java fails intermittently

> On Dec 2, 2015, at 9:12 AM, Xuelei Fan <xuelei@oracle.com> wrote: > > On 12/2/2015 9:05 AM, Wang Weijun wrote: >> Socket is a Closeable, so you can >> >> try (Socket sock = ) { ... } >> > Yes. Better coding. Updated in the same webrev

Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

Some comments: 1. Maybe use jdk/testlibrary/JDKToolLauncher.java to launch jarsigner? 2. You mentioned it's difficult to set a security provider in java.security file. Have you tried "-Djava.security.properties=="? It is described at the beginning of java.security. Thanks Max > On Nov 23,

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

() has no default implementation now (aka throws UnsupportedOperationException). Integration date is now Dec 4. Won't catch it. --Max > On Nov 23, 2015, at 3:03 PM, Wang Weijun <weijun.w...@oracle.com> wrote: > > spec: > http://cr.openjdk.java.net/~weijun/8051408/webrev.00/specdi

Re: RFR 8141457: keytool default cert fingerprint algorithm should be SHA-256

est files for some additional testing. > > --Sean > > On 11/23/2015 08:00 PM, Wang Weijun wrote: >> Hi All >> >> Please review a code change at >> >>http://cr.openjdk.java.net/~weijun/8141457/webrev.00/ >> >> SHA-256 is now th

Re: RFR 8141690: JDK-8133151 change to MakeJavaSecurity.java is not complete

> On Nov 25, 2015, at 11:04 PM, Sean Mullan wrote: > > The fix looks fine to me. For testing, can you create a test that uses a > custom java.security file with "#ifndef solaris-sparc" in it, and check > whether the property is used or not depending on what system is

RFR 8144107: jdk/security tests not included

Please review the fix at http://cr.openjdk.java.net/~weijun/8144107/webrev.00/ The recent JarSigner API changeset includes some tests in jdk/security but the directory is not included in any test group. This fix adds it into jdk_security3. Thanks Max

Re: RFR 8143377: Test PKCS8Test.java fails

Done. http://hg.openjdk.java.net/jdk9/dev/jdk/rev/33fd40487d6d Thanks Max > On Nov 25, 2015, at 7:42 AM, Rajan Halade wrote: > > Looks good to me, thanks for the updates! > > Please wait for one official reviewer before you commit. > > Thanks, > Rajan > On 11/24/15

RFR 8141457: keytool default cert fingerprint algorithm should be SHA-256

Hi All Please review a code change at http://cr.openjdk.java.net/~weijun/8141457/webrev.00/ SHA-256 is now the default fingerprint algorithm, and MD5 is removed in the full list. No new regression test, I consider the change trivial. If you think one is better, I'll add it. Thanks Max

Design and impl review: JEP 273: DRBG-Based SecureRandom Implementations

spec: http://cr.openjdk.java.net/~weijun/8051408/webrev.00/specdiff/java/security/package-summary.html impl: http://cr.openjdk.java.net/~weijun/8051408/webrev.00/ - No more configure(), it's getInstance(alg, SecureRandomParameters) now. - The *Spec class names are now *Parameters. - Overloaded

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

> 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), there is no >>> getInstance(alg). Obviously, for SecureRandom we need to have both. >> >> Right, this is

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

> On Nov 21, 2015, at 8:59 AM, Wang Weijun <weijun.w...@oracle.com> wrote: > > That said, I re-read SP 800-90A again and seems there is a feature I haven't > supported yet. The full generate function is > > Generate_function (state_handle,

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

> On Nov 20, 2015, at 1:11 AM, Sean Mullan wrote: >> >> However, I cannot get it working, and I found difficulties understanding the >> EngineDescription inner class inside Provider.java. >> >> 1. For each engine that can take an extra parameter (not provider) in >>

Re: RFR 8048357: PKCS basic tests

Looks fine, but there are TAB characters. Have you run jcheck? remote: test/sun/security/pkcs/pkcs10/PKCS10AttrEncoding.java:29: Tab character remote: test/sun/security/pkcs/pkcs10/PKCS10AttributeReader.java:52: Tab character remote: test/sun/security/pkcs/pkcs7/PKCS7VerifyTest.java:48: Tab

Re: RFR 8141690: JDK-8133151 change to MakeJavaSecurity.java is not complete

Ding dong. > On Nov 9, 2015, at 3:35 PM, Wang Weijun <weijun.w...@oracle.com> wrote: > > Hi All > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8141690/webrev.00/ > > JDK-8133151 added support for "#ifdef solaris-sp

Re: RFR 8048357: PKCS basic tests

Done at http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c071ebc7f3bf Thanks Max > On Nov 20, 2015, at 11:00 AM, Amanda Jiang wrote: > > Hi Max, > > Sorry for the formatting issue, I have removed all TAB characters and ran > jcheck on the changeset below, could you please

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

> On Nov 18, 2015, at 9:32 PM, Sean Mullan wrote: > > The getInstance methods can now take a SecureRandomParameterSpec object > (rather than an AlgorithmParameterSpec). They should throw > InvalidAlgorithmParameterException (not IllegalArgumentException) if the >

RFR 8130132: jarsigner should emit warning if weak algorithms or keysizes are used

Hi All Please take a look at http://cr.openjdk.java.net/~weijun/8130132/webrev.00/ These new warnings will be added to jarsigner: The signer's certificate is self-signed. This jar contains entries whose signer certificate is self-signed. The %1$s algorithm used as %2$s is considered

Re: RFR 8056174: New APIs for jar signing

Hi All An updated webrev is available at http://cr.openjdk.java.net/~weijun/8056174/webrev.06/ Compared with webrev.05, these changes are made: 1. In AlgorithmId.java, getDefaultSigAlgForKey() looks at the key size and returns signature algorithms with different digest part. Thanks, Mike!

Re: RFR 8056174: New APIs for jar signing

ed inside java.base but the spec is in jdk.jartool, although most likely we don't suggest users mixing modules from different releases. --Max > > --Sean > > On 11/18/2015 01:53 AM, Wang Weijun wrote: >> Hi All >> >> An updated webrev is available at >> &g

RFR 8143138: Move sun/security/pkcs11/Secmod/LoadKeystore.java to problem list

Hi All The test has failed a lot recently. Please review the change: diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -234,6 +234,7 @@ sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java generic-all # 8077138: Some

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

> On 2015年11月14日, at 上午1:56, Sean Mullan <sean.mul...@oracle.com> wrote: > > On 11/12/2015 07:58 PM, Wang Weijun wrote: >>> What happens if configure is called more than once, or >>> simultaneously by more than one thread? >> The state is reset. The

Re: JEP260 -- Impact on SunPKCS11?

> On Nov 16, 2015, at 11:46 PM, Sean Mullan wrote: > > Provider p = Security.getProvider("SunPKCS11"); > p.configure("/opt/bar/cfg/pkcs11.cfg"); p = p.configure("/opt/bar/cfg/pkcs11.cfg"); The spec for the method says: * Apply the supplied configuration argument

Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data

All tests look fine. I suppose Vincent already agreed with the src change. Right? For safety, I am running all related tests on windows-i586 and windows-x64 now. Thanks Max > On 2015年11月16日, at 上午7:27, Langer, Christoph wrote: > > Hi Max, > > thanks for that hint

Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data

> On Nov 16, 2015, at 3:19 PM, Vincent Ryan wrote: > > Yes the source changes look fine. > Last week I ran the tests using webrev.4 and all passed. FYI: webrev.6 also pass. --Max > > Thanks Christoph for the comprehensive fix.

Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data

It is my understanding that if you write multiple files for a single test, they should be put inside a sub-directory. But in this case you can combine them into a single class by putting the provider-related codes into static inner classes. --Max P. S. Sent from my iPhone so I haven't read

Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data

@sap.com> wrote: > > Hi Max, > > I followed your suggestion to use a sub-directory. I found no way to make the > dummy JCE provider work with inner classes. > > Please see this (hopefully final) webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8139436.5/ > >

Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data

Also there is a standard way to check if it's windows: http://openjdk.java.net/jtreg/tag-spec.html#requires_names os.family should be the one to use. --Max > >> I just updated the changeset with a >> testcase:http://cr.openjdk.java.net/~clanger/webrevs/8139436.3/ >>

Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data

> On Nov 13, 2015, at 7:12 AM, Langer, Christoph > wrote: > > Hi Vincent, > > I just updated the changeset with a > testcase:http://cr.openjdk.java.net/~clanger/webrevs/8139436.3/ > > The testcase would run through with or without my patch, unless you specify >

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

> On Nov 12, 2015, at 11:23 PM, Sean Mullan <sean.mul...@oracle.com> wrote: > > Hi Max, > > Still reviewing, but a couple of initial comments .. > > On 11/09/2015 09:54 AM, Wang Weijun wrote: >> Hi All >> >> The following is API/SPI to support NIS

Design review: JEP 273: DRBG-Based SecureRandom Implementations

Hi All The following is API/SPI to support NIST 800-90A DRBGs. The JEP is at https://bugs.openjdk.java.net/browse/JDK-8051408 Some notes before the text: 1. Mainly, new methods are added to SecureRandom to match DRBG functions: - configure: choosing the algorithms and parameters - reseed:

Re: dlsym(RTLD_DEFAULT, "getentropy") return non-NULL on Mac

will be a nice enhancement. BTW, I'll file separate bugs for EntropyInput implementations. These are non-goals for the DRBG feature itself. Thanks Max > > Mike > > > On 11/8/2015 6:18 AM, Dmitry Samersoff wrote: >> Wang Weijun, >> >> >>> The funct

Re: dlsym(RTLD_DEFAULT, "getentropy") return non-NULL on Mac

> On Nov 8, 2015, at 7:18 PM, Dmitry Samersoff <dmitry.samers...@oracle.com> > wrote: > > Wang Weijun, > >> The function is rather new in the latest Solaris beta [1] and it's >> preferred to reading from /dev/random. There are already people >> sugg

RFR 8141690: JDK-8133151 change to MakeJavaSecurity.java is not complete

Hi All Please review the code change at http://cr.openjdk.java.net/~weijun/8141690/webrev.00/ JDK-8133151 added support for "#ifdef solaris-sparc" but not "#ifndef solaris-spare". This is fixed and I also added "#else". How do I test the change? Thanks Max

Re: review request for CCC 8004078 [docs] Create Standard Names for SHA-3 algorithms.

Should the CCC include the description column for the new algorithm names? FIPS 202 also mentioned HMAC on the new algorithms. Shall we also add them? What is an extendable-output function (XOFs, SHAKE128/SHAKE256)? Are we going to support it? Does it need a new API? (Seems it looks like a hash

Re: dlsym(RTLD_DEFAULT, "getentropy") return non-NULL on Mac

> On Nov 8, 2015, at 4:29 AM, Dmitry Samersoff <dmitry.samers...@oracle.com> > wrote: > > Wang Weijun, > > 1. RTLD_DEFAUL call is expensive and dangerous because it cause symbol > search across all loaded images. So it can pick up something absolutely > irreleva

dlsym(RTLD_DEFAULT, "getentropy") return non-NULL on Mac

I find something strange. Background: a new method getentropy() is available on OpenBSD [1] and Solaris and people are also proposing it on other OSes. Therefore inside JDK I write a piece of native code to detect it, something like typedef int (*GETENTROPY_FN)(char* buffer, int len);

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

> On Oct 28, 2015, at 4:56 AM, Mark Sheppard wrote: > > dynamic update of host / ip mappings updates are accommodated as seen per the > tests >

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

I see a lot of krb5 tests modified. Basically, the NameServiceDescriptor inside KDC.java maps everything to localhost except for one (I guess Artem invented the 2nd feature). Can we expand the grammar a little bit to support this? For example: not.existing.host UnknownHostException *

Re: [9] RFR:8078813:Test JAAS with modules

Looks fine, and very interesting. Just some questions: 1. expectedResult is PASS in all test runs. Do you think it would be something else? Maybe compiler error and jar creation error? Could that happen? 2. Are the .class files always the same? If so, is it possible to compile them once, and

RFR 8085904: Test timeout on Mac

Please review the fix at http://cr.openjdk.java.net/~weijun/8085904/webrev.00/ I just s/home/tmp/g. /home is an autofs mount point and resolving it slows everything down. Hopefully FQDN look up is not the problem here. Thanks Max

Re: [9] RFR 8136600: sun/security/krb5/auto/tools/KinitConfPlusProps.java test intermittently fails because PortUnreachableException is missing

Looks fine. Is it Mac or Windows? Is it a SocketTimeoutException? Thanks Max > On 2015年9月29日, at 下午10:01, Artem Smotrakov wrote: > > Hello, > > Please review this small test fix for > https://bugs.openjdk.java.net/browse/JDK-8136600 > > The test runs kinit, and

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Can you describe if there is any effect on signed jars? Including: 1. Will jarsigner be able to sign such a jar? Are all items inside signed? If you sign a jar using jarsigner from different versions of JDK, will there be any difference? 2. Will jarsigner be able to verify such a jar? Will it

Re: RFR 8056174: New APIs for jar signing

> On 2015年9月30日, at 上午2:36, Mike StJohns wrote: > > The first and probably most important is that you can't/shouldn't pick the > default signature algorithm solely based on the key type, but instead on the > key type and strength. Great. I'll pick up your suggested

Re: RFR 8050461: Tests for syntax checking of JAAS configuration file

Great. Everything looks fine now. Thanks Max > 在 2015年9月21日，12:54，Amanda Jiang 写道： > > Hi Max, > > Thanks for reviewing this webrev. I have updated test cases by your comments > and simplify codes, please check latest webrev below and let me know if there > are any

Re: 8136436: jarsigner tests include both a warnings.sh and a warnings subdir

Ping again. > On Sep 14, 2015, at 12:08 PM, Wang Weijun <weijun.w...@oracle.com> wrote: > > I’ve filed the bug at https://bugs.openjdk.java.net/browse/JDK-8136436. > > jtreg first creates the "warnings" directory to store jtr files of tests in > warnings subd

8136436: jarsigner tests include both a warnings.sh and a warnings subdir

I’ve filed the bug at https://bugs.openjdk.java.net/browse/JDK-8136436. jtreg first creates the "warnings" directory to store jtr files of tests in warnings subdir, and then clean it up and store retained files for warnings.sh there. The jtr files are now lost. No webrev to look at, I just cd

RFR 8136425: KeystoreImpl.m using wrong type for cert format

Please take a look at http://cr.openjdk.java.net/~weijun/8136425/webrev.00/ It looks like a wrong type is used, kSecFormatX509Cert and kSecFormatWrappedPKCS8 are of SecExternalFormat and the SecKeychainItemImport function also uses

Re: [9] RFR: 8075299: Additional tests for 6857795

Everything is fine. Some answers inline: > On Aug 6, 2015, at 9:42 PM, Artem Smotrakov > wrote: > > By the way, as far as I know, currently it is not possible to specify a port > number in "java.security.krb5.kdc”. Yep. > > What do you think? I have thought

Re: [9] RFR: 8075299: Additional tests for 6857795

Everything is fine now. Thanks Max > http://cr.openjdk.java.net/~asmotrak/8075299/webrev.03/

Re: [9] RFR: 8075297: Tests for RFEs 4515853 and 4745056

I think it it enough to add a max_retries = 1 to [libdefaults] of krb5.conf, and left default timeout value for the test. Please take a look at updated webrev: http://cr.openjdk.java.net/~asmotrak/8075297/webrev.02/ Can you also add the same line to the krb5.conf for the other test?

Re: [9] RFR: 7145757: CertificateExtensions uses non-consistent key names

On Mar 28, 2015, at 05:19, Jason Uh jason...@oracle.com wrote: On 03/27/2015 03:53 AM, Wang Weijun wrote: On Mar 27, 2015, at 06:37, Jason Uh jason...@oracle.com wrote: Please review this revision: http://cr.openjdk.java.net/~juh/7145757/01/ * a global nameCache is maintained

Re: [9] RFR: 7145757: CertificateExtensions uses non-consistent key names

On Mar 27, 2015, at 06:37, Jason Uh jason...@oracle.com wrote: Please review this revision: http://cr.openjdk.java.net/~juh/7145757/01/ * a global nameCache is maintained in OIDMap as suggested Can you just use the existing OIDMap.getId() method? It looks like your getCachedOid(name) is

Re: RFR 8056174: New APIs for jar signing

On Mar 27, 2015, at 04:41, Sean Mullan sean.mul...@oracle.com wrote: On 03/24/2015 05:47 AM, Wang Weijun wrote: Hi All Please review the code change at http://cr.openjdk.java.net/~weijun/8056174/webrev.00/ It provides a new jdk.Exported API JarSigner to perform jar signing

Re: RFR 8047789: auth.login.LoginContext needs to be updated to work with modules

On Mar 21, 2015, at 18:54, Alan Bateman alan.bate...@oracle.com wrote: On the compatibility issue then someone creating a JAAS configuration file that lists a LoginModule that is not a LoginModule will cause CCE but this pops out as a LoginException with the CCE as cause now - right? This

RFR 8056174: New APIs for jar signing

Hi All Please review the code change at http://cr.openjdk.java.net/~weijun/8056174/webrev.00/ It provides a new jdk.Exported API JarSigner to perform jar signing. The class contains popular functions of the jarsigner tool. The jarsigner tool is unchanged and currently independent of the

Re: [JDK-9] RFR: 8048618 Tests for PKCS12 write operations

://cr.openjdk.java.net/~zailiu/8048618/webrev01/test/java/security/KeyStore/PKCS12/WriteP12Test.java.html Thanks again. Kevin 在 2015/3/18 14:23, Wang Weijun 写道: 33 * WriteP12CertChainBad: same as WriteP12CertChain but chains order is 34 * user-ca-lead, the order is wrong so expects to fail

<    1   2   3   4   5   6   7   >