Re: RFR 8242260: Remove customizable ContentSigner from jarsigner

st because > the ContentSigner APIs are still there doesn't mean you have to use it in > jarsigner (unless I am missing something). > > --Sean > >> —Max >>>> 在 2020年4月9日，21:27，Sean Mullan 写道： >>> >>> On 4/9/20 3:13 AM, Wang Weijun wrote: >

Re: RFR 8242184: CRL generation error with RSASSA-PSS

Valerie in another reply suggested that the default parameters of the default sigAlg depends on either the size of the key (if RSA) of the params of the key (if RSASSA-PSS). I'll address all of these in another bug. Thanks, Max > 在 2020年4月9日，03:47，Sean Mullan 写道： > > On 4/6/20 11:11 PM,

Re: RFR 8242260: Remove customizable ContentSigner from jarsigner

Oh, I'll then need to add new fields to it to support RSASSA-PSS and EdDSA. Sigh. --Max > 在 2020年4月9日，01:58，Sean Mullan 写道： > > We never actually deprecated the com.sun.jarsigner package with a > forRemoval=true flag, so while it may be very low-risk to remove these APIs, > I feel that we

Re: JGSS Enhancements (contribution by Two Sigma Open Source)

Yes, I am on vacation now. When I’m back, I’ll post your changes to cr.openjdk.java.net first. Thanks Max > 在 2018年10月4日，06:13，Valerie Peng 写道： > > Hi Nico, > > Thanks for submitting the patches, Max is off on Chinese holidays til 7th and > I am going to be on vacation til 19th. > > I

Re: RFR 8210786 : Typo s/overriden/overridden/ in several places

This makes sense. No other comment. Thanks Max > 在 2018年9月16日，05:10，Ivan Gerasimov 写道： > > Hi Max! > > >> On 9/15/18 6:28 AM, Weijun Wang wrote: >> In the bug description you listed some in jdk/internal/org/objectweb/asm, >> but they are not included in the fix. Is it because those are not

Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

Thinking about this again. Looks like the absolute path is not necessary. Even if there are multiple files using the same name, they will be in different directories, no matter absolute or relative. Suppose the jarPath info is used for debugging purpose mostly like the developer can find out

Re: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized

> 在 2018年7月20日，05:18，Valerie Peng 写道： > > Hi Sean, > > Thanks for the suggestion, I like it. Me too. > > Max, any objection or concern before I update the webrev and CSR? No. Thanks Max > > Valerie > > >> On 7/19/2018 7:28 AM, Sean Mullan wrote: >> Hi Valerie, Max - >> >> I took a

Re: RFR 8200101: sun/security/krb5/auto/Renewal.java fails intermittently

The change looks fine. Thanks Max > 在 2018年4月19日，19:32，bhanu.prakash.gopula...@oracle.com 写道： > > Hi All, > > Please review fix for following issue: > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8200101 > > Webrev: http://cr.openjdk.java.net/~bgopularam/8200101/webrev.00/ > > It was

Re: RFR 8191137: keytool fails to format resource strings for keys for some languages after JDK-8171319

> 在 2017年11月14日，18:02，Severin Gehwolf 写道： > > This looks fine, but I wonder if a regression test would be in order. > E.g. test/sun/security/tools/keytool/WeakAlg.java with > -Duser.language=fr or some such. But my change has not really fixed anything. It’s just a hint on

Re: Patch for JDK-6695402: Jarsigner with multi-byte characters in class names

Some more suggestions on the test: 1. You can use readAllBytes() to ... err ... read all bytes. 2. I normally don’t remove intermediate files. Jtreg will do an automatic cleanup, and it can be configured to retain those files when the test fails. They will be very helpful in debugging.

RFR 8174909: Doc error in SecureRandom

Please review this doc bug diff --git a/src/java.base/share/classes/java/security/DrbgParameters.java b/src/java.base/share/classes/java/security/DrbgParameters.java --- a/src/java.base/share/classes/java/security/DrbgParameters.java +++

RFR: release note for JDK-7004967 SecureRandom should be more explicit about threading

https://bugs.openjdk.java.net/browse/JDK-8165115 Thanks Max

Re: Code Review Request JDK-8172217, Need debug log for the intermittent failure of AnonCipherWithWantClientAuth

Sorry, I didn't notice it. --Max On 1/4/2017 7:59 AM, Xuelei Fan wrote: On 1/3/2017 3:54 PM, Wang Weijun wrote: This looks good. On the other hand, it might be better to add exception stack trace or links to failures to the bug report. Maybe you think they are too useless

Re: Code Review Request JDK-8172217, Need debug log for the intermittent failure of AnonCipherWithWantClientAuth

This looks good. On the other hand, it might be better to add exception stack trace or links to failures to the bug report. Maybe you think they are too useless? Thanks Max > On Jan 4, 2017, at 7:23 AM, Xuelei Fan wrote: > > Hi, > > The intermittent test failure of >

Re: RFR 8157389: Release Note: New default -sigalg for jarsigner and keytool

Ping again. Please review https://bugs.openjdk.java.net/browse/JDK-8157389. JDK-8171190 was already resolved. Thanks Max > On Dec 14, 2016, at 10:04 AM, Wang Weijun <weijun.w...@oracle.com> wrote: > > I copied the exact @implNote from JarSigner into the release note. > >

Re: RFR 8170732: GssKrb5Client sends non-zero buffer size when qop is "auth"

Ping again. On 12/22/2016 9:52 AM, Wang Weijun wrote: Please take a review at http://cr.openjdk.java.net/~weijun/8170732/webrev.00/ According to https://tools.ietf.org/html/rfc4752#section-3.1: The client then constructs data, with the first octet containing the bit-mask specifying

Re: RFR 8172017: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and rcache_usemd5.sh fail on Solaris (Additional pre-authentication required)

Ping again. On 12/27/2016 3:25 AM, Wang Weijun wrote: Please take a review at http://cr.openjdk.java.net/~weijun/8172017/webrev.00 On Solaris when launched by root, the rcache directory is a little different. I've manually tested this on a Solaris machine, and seen rcache files created

RFR 8172017: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and rcache_usemd5.sh fail on Solaris (Additional pre-authentication required)

Please take a review at http://cr.openjdk.java.net/~weijun/8172017/webrev.00 On Solaris when launched by root, the rcache directory is a little different. I've manually tested this on a Solaris machine, and seen rcache files created at different directories when the test was launched by

RFR 8170732: GssKrb5Client sends non-zero buffer size when qop is "auth"

Please take a review at http://cr.openjdk.java.net/~weijun/8170732/webrev.00/ According to https://tools.ietf.org/html/rfc4752#section-3.1: The client then constructs data, with the first octet containing the bit-mask specifying the selected security layer, the second through fourth

Re: Code Review Request, 6972386 issues with String.toLowerCase/toUpperCase

Change looks fine. Thanks for taking care of CtrDrbg.java. I've make quite some changes like this and it's a shame I missed it in my own code. --Max > On Dec 22, 2016, at 4:05 AM, Xuelei Fan wrote: > > Hi, > > Please review the fix: > >

Re: RFR 8170900: Issue with FilePermission::implies for wildcard flag(-)

this means "/-" implies "/foo" but not "foo".". Good advice. Thanks Max > > Use the one you like, I'm OK with the either. > > Xuelei > > On 12/21/2016 3:58 PM, Wang Weijun wrote: >> >>> On Dec 22, 2016, at 4:39 AM, Xuelei Fan <

Re: RFR 8170900: Issue with FilePermission::implies for wildcard flag(-)

Ping again. > On Dec 14, 2016, at 1:53 PM, Wang Weijun <weijun.w...@oracle.com> wrote: > > An clarification is added to FilePermission::implies: > > * @implNote > > * a simple {@code npath} is recursively inside a wildcard {@code npath} >

Re: RFR 8075618: Create tests to check jarsigner work with multi-version jar

Hi Amanda Everything is fine. I have no other comment. Thanks Max > On Dec 19, 2016, at 2:43 PM, Amanda Jiang <amanda.ji...@oracle.com> wrote: > > > > On 12/18/16 10:23 PM, Wang Weijun wrote: >>> Please see updated webrev : >>> http://cr.openjdk.jav

Re: RFR 8075618: Create tests to check jarsigner work with multi-version jar

/file/ab164f8b8569/test/java/util/jar/JarFile/mrjar/MultiReleaseJarSecurity.java > > Thanks > Amanda > On 12/12/16 6:31 PM, Wang Weijun wrote: >> Hi Amanda >> >> Can you also test the new JarSigner API? >> >>http://hg.openjdk.java.net/jdk9

RFR 8171353: New home for SecurityTools.java test utility

Hi Artem I hope you are OK with this change: diff --git a/test/lib/security/SecurityTools.java b/test/lib/testlibrary/jdk/testlibrary/SecurityTools.java rename from test/lib/security/SecurityTools.java rename to test/lib/testlibrary/jdk/testlibrary/SecurityTools.java ---

RFR 8171340: HttpNegotiateServer/java test should not use system proxy on Mac

Please take a review at http://cr.openjdk.java.net/~weijun/8171340/webrev.00/ All "openConnection()" modified to "openConnection(Proxy.NO_PROXY)". Everything else is whitespace change. Thanks Max

Re: RFR 8171190: Bump reference of NIST 800-57 Part 1 Rev 3 to Rev 4 in JarSigner API spec

7680 itself is 192 bits, and for any bitLength greater than 7680 I treat it as in a "higher" level. --Max > On Dec 14, 2016, at 5:19 PM, Bernd Eckenfels wrote: > > Hello, > > I noticed in the existing code: Is the comment "256 bits" referring to the > 'comparable

Re: RFR 8168979: @implNote for invalid FilePermission

> On Dec 14, 2016, at 10:11 AM, Xuelei Fan <xuelei@oracle.com> wrote: > > On 12/13/2016 5:45 PM, Wang Weijun wrote: >> A major behavior change is that <> now implies an invalid >> permission, I hope this is good to minimize incompatibility. > L

RFR 8171190: Bump reference of NIST 800-57 Part 1 Rev 3 to Rev 4 in JarSigner API spec

NIST 800-57 Part 1 has a new revision. The lines below are newly introduced in jdk9. diff --git a/src/java.base/share/classes/sun/security/x509/AlgorithmId.java b/src/java.base/share/classes/sun/security/x509/AlgorithmId.java --- a/src/java.base/share/classes/sun/security/x509/AlgorithmId.java

Re: RFR 8157389: Release Note: New default -sigalg for jarsigner and keytool

14, 2016, at 5:09 AM, Sean Mullan <sean.mul...@oracle.com> wrote: > > Hi Max, > > Could you include more information that shows what signature algorithm is > used based on the key size range and algorithm? > > --Sean > > On 12/11/16 9:53 PM, Wang Weijun wrote: &g

Re: RFR 8168979: @implNote for invalid FilePermission

n if two {@code FilePermission} are created with the same >invalid path, one does *not* imply the other. > > best regards, > > -- daniel > > On 12/12/16 09:01, Wang Weijun wrote: >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/816

Re: On 8171135: Include javadoc on JarSigner API in security doc

quot;official" place > for exported, non-SE javadocs; otherwise it seems ok to me. > > --Sean > > On 12/12/16 9:50 PM, Wang Weijun wrote: >> Hi All >> >> I've create a new bug to include the javadoc of the non-Java SE JarSigner >> API into securit

On 8171135: Include javadoc on JarSigner API in security doc

Hi All I've create a new bug to include the javadoc of the non-Java SE JarSigner API into security doc: https://bugs.openjdk.java.net/browse/JDK-8171135 If you think this is OK, I'll move the bug to doc. Thanks Max

Re: [PATCH] 8165751: NPE in Signature with java.security.debug=provider

Hi Adam The only behavior change is with the debug output, right? Is this a new pattern that internal optional fields should be defined as an Optional? And, when there is no provider the string form "from: " looks strange, I would rather make it "from nowhere". I would also move the space

Re: RFR 8168979: @implNote for invalid FilePermission

o {@code FilePermission} > 542 * are created with the same invalid path, one does imply the other. > > should this be: > >Even if two {@code FilePermission} are created with the same >invalid path, one does *not* imply the other. Ah, yes. Thanks Max > > best reg

RFR 8157389: Release Note: New default -sigalg for jarsigner and keytool

Please take a review at the release note at https://bugs.openjdk.java.net/browse/JDK-8157389 Thanks Max

Re: [9] RFR 8170247: java/security/SecureRandom/ApiTest fails when run with unlimited policy.

Change looks fine. One nit: the extra space at the beginning of line 24 looks strange. Thanks Max On 11/30/2016 5:27 PM, Sibabrata Sahoo wrote: Hi, Please review the patch for, JBS: https://bugs.openjdk.java.net/browse/JDK-8170247 Webrev:

Re: [8u-dev] RFR 8170278 : ticket renewal won't happen with debugging turned on

+1 --Max > On Nov 29, 2016, at 5:16 PM, Seán Coffey wrote: > > Looks good. > > regards, > Sean. > > > On 29/11/2016 09:08, Ivan Gerasimov wrote: >> Hello! >> >> It was reported that there's broken behavior exposed when the debug mode is >> turned on, which is due

Re: RFR(s): JDK-8169866: [TESTBUG] com/sun/security/ tests have undeclared modules dependencies

Hi Sergei Looks good to me. Thanks Max On 11/28/2016 9:17 PM, Sergei Kovalev wrote: R-sending request for review 17.11.16 15:43, Sergei Kovalev wrote: Hello team, Please review a small fix for security tests. BugID: https://bugs.openjdk.java.net/browse/JDK-8169866 Web review:

Re: RFR 8170364: FilePermission path modified during merge

Hi Alan Updated webrev at http://cr.openjdk.java.net/~weijun/8170364/webrev.01 Changes since webrev.00: - a private constructor that can clones 4 fields and modifies 5 others - using lambda - test enhancement Thanks Max

Re: RFR 8170364: FilePermission path modified during merge

> On Nov 27, 2016, at 7:13 PM, Wang Weijun <weijun.w...@oracle.com> wrote: > >> >> On Nov 27, 2016, at 6:12 PM, Alan Bateman <alan.bate...@oracle.com> wrote: >> >> On 26/11/2016 08:54, Wang Weijun wrote: >> >>> Please take a review

RFR 8170364: FilePermission path modified during merge

Please take a review at http://cr.openjdk.java.net/~weijun/8170364/webrev.00/ The compatibility layer introduced in the new FilePermission implementation requires one FilePermission to imply another with either a relative path or an absolute path. This is solved with a private field npath2

Re: RFR 8169911: Enhanced tests for jarsigner -verbose -verify after JDK-8163304

Hi Amanda - There are many duplicates in signWithAlias() and sign(). I think it's better to make one based on the other. Maybe signWithAliasAndTsa() and sign(). - checkWeak2() is about combinations of weak/strong algs in a single signer. I'd rather it be an individual test case, and not as a

Re: RFR: 8169335: Add a crypto.policy fallback in case Security Property 'crypto.policy' does not exist

> On Nov 17, 2016, at 9:33 AM, Bradford Wetmore > wrote: > >try (PrintWriter out = new PrintWriter(FILENAME)) { >Files.lines(path) >.filter(x -> !x.trim().startsWith("crypto.policy")) >

Re: RFR: 8169335: Add a crypto.policy fallback in case Security Property 'crypto.policy' does not exist

that before! We have NOT been consistent in whether we >>> use: >>> >>>System.out.println() >>> or >>>debug.println() >>> >>> I knew SeanC wants to rework the JCA/JCE/Security debugging output in >>> another project

Re: RFR 8043252: Debug of access control is obfuscated - NullPointerException in ProtectionDomain

> On Nov 16, 2016, at 12:40 PM, Jamil Nimeh <jamil.j.ni...@oracle.com> wrote: > > Oops, good catch. I'll fix that. I assume you don't need a third review for > that? No. Just push your change. --Max > > > > --Jamil > > ---- Original message --

Re: RFR 8043252: Debug of access control is obfuscated - NullPointerException in ProtectionDomain

; > > On 11/15/2016 06:18 PM, Wang Weijun wrote: >> 41 System.setSecurityManager(new SecurityManager()); >> >> This is strange. I suppose you only want to trigger a permission check? >> >> If so, just change it to Policy.getPolicy(), and you can clean up th

Re: RFR 8169751: sun/security/krb5/auto/rcache_usemd5.sh fails on solaris

ly (still using jtreg) with various test.* properties. Having 2 run tags double the time and not what I wanted. --Max > > Xuelei > > On 11/16/2016 11:23 AM, Wang Weijun wrote: >> Sorry, the webrev here http://cr.openjdk.java.net/~weijun/8169751/webrev.00/ >> >> --Max >>

Re: RFR 8169751: sun/security/krb5/auto/rcache_usemd5.sh fails on solaris

Sorry, the webrev here http://cr.openjdk.java.net/~weijun/8169751/webrev.00/ --Max > On Nov 16, 2016, at 10:40 AM, Wang Weijun <weijun.w...@oracle.com> wrote: > > Please take a review at > > 8169751: sun/security/krb5/auto/rcache_usemd5.sh fails on solaris > &

Re: RFR 7004967: SecureRandom should be more explicit about threading

reRandom.AlgName ThreadSafe", "true"); or putService(new Service(this, "SecureRandom", "AlgName", className, null, Map.of("ThreadSafe", "true"))); {@code SecureRandom} will then call the applicable engine methods without any synchron

RFR 8169751: sun/security/krb5/auto/rcache_usemd5.sh fails on solaris

Please take a review at 8169751: sun/security/krb5/auto/rcache_usemd5.sh fails on solaris Different service names are used in the 2 tests (rcache_usemd5.sh and ReplayCacheTestProc.java) now. Thanks Max

Re: RFR 8043252: Debug of access control is obfuscated - NullPointerException in ProtectionDomain

41 System.setSecurityManager(new SecurityManager()); This is strange. I suppose you only want to trigger a permission check? If so, just change it to Policy.getPolicy(), and you can clean up the policy file a little. Thanks Max > On Nov 16, 2016, at 8:36 AM, Jamil Nimeh

Re: RFR: 8169335: Add a crypto.policy fallback in case Security Property 'crypto.policy' does not exist

You create a debug field with a prefix string and then check both debug != null and Debug.isOn("policy") and then use System.out.println to print the message. Something must be useless. --Max > On Nov 16, 2016, at 3:31 AM, Bradford Wetmore > wrote: > > Simple

Re: RFR 7004967: SecureRandom should be more explicit about threading

> On Nov 9, 2016, at 5:06 AM, Sean Mullan wrote: > >> In fact, can we >> deprecate the getSeed() method? It's not unsafe so we don't need to give >> it a forRemoval value. > > Sounds reasonable. I would file a bug, but I don't think it is critical for 9 > - we can do

Re: [9] RFR: 8168882: keytool doesn't print certificate info if disabled algorithm was used for signing a jar

Everything looks fine now. --Max > On Nov 8, 2016, at 11:09 AM, Artem Smotrakov > wrote: > > Here is final version (I hope) > > http://cr.openjdk.java.net/~asmotrak/8168882/webrev.04/ > > Artem

Re: RFR 7004967: SecureRandom should be more explicit about threading

reRandom.AlgName ThreadSafe", "true"); or putService(new Service(this, "SecureRandom", "AlgName", className, null, Map.of("ThreadSafe", "true"))); {@code SecureRandom} will then call the applicable engine methods without any synchron

Re: Windows LSA cache and Kerberos delegation

> On Oct 13, 2016, at 3:38 AM, Venkat Iyer (veniyer) wrote: > > Do you know if the problem of obtaining TGT session key on Windows from LSA > credential cache is resolved (see snippet below)? I am not sure. Sometimes you just cannot get the session key. One way to check

Re: [9] RFR: 8168882: keytool doesn't print certificate info if disabled algorithm was used for signing a jar

Everything is fine now. Thanks Max On 11/3/2016 9:38 AM, Artem Smotrakov wrote: My bad, I missed that. http://cr.openjdk.java.net/~asmotrak/8168882/webrev.02/ Artem On 11/02/2016 06:30 PM, Wang Weijun wrote: On 11/01/2016 11:59 PM, Wang Weijun wrote: >> Main.java: >> &g

Re: [9] RFR: 8168882: keytool doesn't print certificate info if disabled algorithm was used for signing a jar

> On Nov 3, 2016, at 8:27 AM, Artem Smotrakov <artem.smotra...@oracle.com> > wrote: > > Hi Max, > > Please see inline. > > > On 11/01/2016 11:59 PM, Wang Weijun wrote: >> Main.java: >> >> The warning (and the subsequent empty lin

Re: RFR 7004967: SecureRandom should be more explicit about threading

> 在 2016年11月2日，21:50，Xuelei Fan 写道： > > I may change "the service provider attribute" to "the service attribute". I didn't invent that name, I remember it's named exactly like this in one of the security guides. Will check tomorrow, not near a big screen now. Thanks

Re: RFR 7004967: SecureRandom should be more explicit about threading

> On Nov 2, 2016, at 9:18 PM, Xuelei Fan <xuelei@oracle.com> wrote: > > On 11/2/2016 8:47 PM, Wang Weijun wrote: >> >>> On Nov 2, 2016, at 5:34 PM, Xuelei Fan <xuelei@oracle.com> wrote: >>> >>> 1. More specific &g

Re: RFR 7004967: SecureRandom should be more explicit about threading

same > as set to "false" per your current implementation. > >"Otherwise, this class will ... " OK. > > May need to update the implementation accordingly if you accept the comments. Why update the implementation? Thanks Max > > Xuelei > > > On

Re: RFR 7004967: SecureRandom should be more explicit about threading

Ping again. There is an updated version at http://cr.openjdk.java.net/~weijun/7004967/webrev.01/ with doc-only changes. Thanks Max > On Aug 25, 2016, at 10:00 AM, Weijun Wang wrote: > > Please review the enhancement at > >

Re: [9] RFR: 8168882: keytool doesn't print certificate info if disabled algorithm was used for signing a jar

Main.java: The warning (and the subsequent empty line) should be printed into System.err. Resources.java: "This tool accepts any algorithm" is a little confusing (sorry that I originally suggested it). Maybe "This tool does not attempt to verify a signed jar file, please run \"jarsigner

Re: RFR 8168518: rcache interop with krb5-1.15

Webrev updated at http://cr.openjdk.java.net/~weijun/8168518/webrev.02/ The only change in src/ is the system property name from "jdk.krb5.rcache.usemd5" to "jdk.krb5.rcache.useMD5". Test enhanced, now I can launch the test like jtreg -javacoption:-XDignore.symbol.file \

Re: Code review request, JDK-8168822, Document that algorithm restrictions do not apply to trusted certs

One question: I thought for TLS, you check twice. First using jdk.tls.disabledAlgorithms on cipher suites etc, and second using jdk.certpath.disabledAlgorithms on certificates. Why is jdk.tls.disabledAlgorithms applied to cert at all? Thanks Max On 10/27/2016 8:30 AM, Wang Weijun wrote: I

Re: Code review request, JDK-8168822, Document that algorithm restrictions do not apply to trusted certs

I don't think this applies to jdk.jar.disabledAlgorithms. While the private key algorithm and key size are determined by the certificate, I think they are always checked even if the end-entity cert is trusted (For example, a trusted self-signed cert). Thanks Max On 10/27/2016 8:04 AM, Xuelei

Re: RFR 8168518: rcache interop with krb5-1.15

the same file? Newly added entries will be SHA-256 and the old ones remains. Still interoperable but just ignored. Thanks Max > > Thanks, > Xuelei > > On 10/25/2016 3:36 PM, Wang Weijun wrote: >> Hi Xuelei >> >> I rethink about it. Here is the updated

Re: RFR 8168518: rcache interop with krb5-1.15

. No more free setting. 3. Test fixed. I forgot to pass the system property to child process. Please also review the release note at https://bugs.openjdk.java.net/browse/JDK-8168635. Thanks Max > On Oct 25, 2016, at 1:46 PM, Wang Weijun <weijun.w...@oracle.com> wrote: > > > &g

Re: RFR 8168518: rcache interop with krb5-1.15

information. OK, I'll change the message. Otherwise, looks fine to me. Xuelei On 10/25/2016 12:18 PM, Wang Weijun wrote: http://cr.openjdk.java.net/~weijun/8168518/webrev.00/ Please read https://bugs.openjdk.java.net/browse/JDK-8168518 for the reason. This code change includes: 1. Add a hashAlg

RFR 8168518: rcache interop with krb5-1.15

http://cr.openjdk.java.net/~weijun/8168518/webrev.00/ Please read https://bugs.openjdk.java.net/browse/JDK-8168518 for the reason. This code change includes: 1. Add a hashAlg field in AuthTimeWithHash.java. 2. Add AuthTimeWithHash.DEFAULT_HASH_ALG so we can change it later. 3. The fix of the

Re: [8u-dev] Request for Review & Approval - 8163304: jarsigner -verbose -verify should print the algorithms used to sign the jar

On Oct 21, 2016, at 10:31 AM, Rob McKenna wrote:Hi folks,Looking for a codereview and push approval for the following:bug: https://bugs.openjdk.java.net/browse/JDK-81633049 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a25dbe45e618 webrev:

RFR 8167646: Better invalid FilePermission

Please review the code change at http://cr.openjdk.java.net/~weijun/8167646/webrev.00/ A new flag invalid is added so invalid FilePermissions (invalid Path) do not equal or imply or is implied by anything else except for itself. Thanks Max

RFR 8168374: TsacertOptionTest.java fails on all platforms

Please review this test change: diff --git a/test/sun/security/tools/jarsigner/TsacertOptionTest.java b/test/sun/security/tools/jarsigner/TsacertOptionTest.java --- a/test/sun/security/tools/jarsigner/TsacertOptionTest.java +++ b/test/sun/security/tools/jarsigner/TsacertOptionTest.java @@ -31,6

RFR 8168127: FilePermissionCollection merges incorrectly

Please review the code change at http://cr.openjdk.java.net/~weijun/8168127/webrev.00/ Two changes: 1. npath2 is considered in equals and hashCode of FilePermission, so 2 objects with different npath2 can be added to a map and different entries. 2. special name for newPermUsingAltPath and

Re: RFR 8163304: jarsigner -verbose -verify should print the algorithms used to sign the jar

Updated at http://cr.openjdk.java.net/~weijun/8163304/webrev.02/ changes to webrev.01 is at http://cr.openjdk.java.net/~weijun/8163304/webrev.02/interdiff.patch.html Thanks Max

Re: RFR 8163304: jarsigner -verbose -verify should print the algorithms used to sign the jar

> Am Wed, 19 Oct 2016 16:13:24 -0400 > schrieb Sean Mullan < > sean.mullan at oracle.com > >: > > > > 150 "The jar will be treated as unsigned, because it > > > > is signed with a weak algorithm that is now disabled.\n\nRe-run > > > > jarsigner with the -verbose option for

Re: RFR 8163304: jarsigner -verbose -verify should print the algorithms used to sign the jar

with the file name itself the > content. > 70 * with the file name itself the content. > > These 2 lines would be more understandable if you changed "itself the > content" to "itself as the content". Yes. > > * TimestampCheck.java > > You will nee

RFR 8163304: jarsigner -verbose -verify should print the algorithms used to sign the jar

Please review the code change at http://cr.openjdk.java.net/~weijun/8163304/webrev.01/ With this change, "jarsigner -verify -verbose" will print out how a jar was signed. For example, a jar which was signed and timestamped with many weak algorithms will show - Signed by "CN=old"

RFR 8167647: Copy-and-paste bug in javax.security.auth.kerberos.KerberosTicket.toString()

Please take a review on this change: diff --git a/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosTicket.java b/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosTicket.java ---

RFR 8167181: Exported elements referring to inaccessible types in jdk.security.jgss

Please review the code change for jdk9/dev/jdk repo at http://cr.openjdk.java.net/~weijun/8167181/webrev.00 and for jdk9/dev which is simply diff --git a/make/CompileJavaModules.gmk b/make/CompileJavaModules.gmk --- a/make/CompileJavaModules.gmk +++ b/make/CompileJavaModules.gmk @@ -452,10

Re: [9] RFR: JDK-8164322: sun/security/pkcs11/PKCS11Test.java shall be updated to run on ARM platforms

> On Sep 28, 2016, at 7:59 AM, Xuelei Fan wrote: > >> Currently the tests silently quit which looks like they pass. This makes >> people think that everything went smoothly, but actually nothing was >> tested. >> > I did not get the idea. I think what Artem meant is

Re: [9] RFR: JDK-8164322: sun/security/pkcs11/PKCS11Test.java shall be updated to run on ARM platforms

Looking at the webrev, it looks we've never tested on "Linux-arm-32" and "Linux-aarch64-64" before and we only realized it now. This is a true problem. On the other hand, I also agree with Xuelei's concern. If a new platform is added and it does not have NSS libs tests will fail. How about

Re: RFR: JDK-8049516: sun.security.provider.SeedGenerator throws ArrayIndexOutOfBoundsException

I am OK with your fix, but I found "(latch + 1) % Integer.MAX_VALUE" a little difficult to understand. Does rndTab[latch & 0xff] also work? Thanks Max > On Sep 21, 2016, at 11:57 PM, Jamil Nimeh wrote: > > Hi Max and Xuelei, > > Yesterday I also reached out to the

Re: RFR(s): 8166450: SMARTCARDIO related tests failed on compilation

Change looks fine. One question: When you say the --limit-modules option, is it a new option for jtreg that allows it to automatically choose modules described in the @modules tags? Or it's just the standard VM option and you still need to provide the module names yourself? Thanks Max > On

Re: RFR: JDK-8049516: sun.security.provider.SeedGenerator throws ArrayIndexOutOfBoundsException

> On Sep 21, 2016, at 9:58 AM, Xuelei Fan wrote: > > 359 while (System.nanoTime() - startTime < 25000) { > 360 synchronized(this){}; > - 361 latch++; > + 361 latch = (latch + 1) % Integer.MAX_VALUE; > 362 } > > This block may be not CPU

Re: Code Review Request, JDK-8146600 AVA Normalizer.Form issue

> On Sep 20, 2016, at 8:58 AM, Xuelei Fan wrote: >> >> I this case, a comma appears but then it is escaped. You might say it is >> unexpected, but at least after escaping, it becomes a legal string. >> > I did not get the point. A comma (",") should be escaped and it

Re: Code Review Request, JDK-8146600 AVA Normalizer.Form issue

Sorry. Whenever I wrote NFC, I meant NFD. Typo. > 在 2016年9月19日，23:16，Xuelei Fan <xuelei@oracle.com> 写道： > >> On 9/19/2016 11:03 PM, Wang Weijun wrote: >> After some thinking, my current opinion is. >> >> 1. Maybe NFC is better than NFKD, but I am not a

Re: Code Review Request, JDK-8146600 AVA Normalizer.Form issue

After some thinking, my current opinion is. 1. Maybe NFC is better than NFKD, but I am not a Unicode expert. 2. I think the real bug is the order of escaping and normalization. The normalization (if a must) should be performed earlier right after valStr is created and only performed on valStr.

Re: Code Review Request, JDK-8146600 AVA Normalizer.Form issue

I am not sure of this change for several reasons: 1. I cannot find anywhere in RFC 2253 (or its new versions) mentioning normalizations. Do you know elsewhere? 2. It's not obvious to say "Hello, world!" and "Hello， world!" should be different if NFKD thinks they are. 3. Why not NFC? Although

Re: Intended behavior of the -providerName option of keytool

> On Sep 15, 2016, at 11:53 PM, Michael Wang wrote: > > Hi, > > I'm trying to understand what the -providerName option of keytool does. The > documentation for -providerName just says: > > "Used to identify a cryptographic service provider's name when listed in the >

Re: Do your NSS DLLs on Windows have execute permission?

> On Sep 16, 2016, at 2:30 AM, Bradford Wetmore > wrote: > > As of today's JDK 9 code, look at the "prep" target" in the jdk/test/Makefile > test directory. The "prep" target updates the DLLs as needed if this is not > a repository (which I think is how our

Re: X.509 Certificate Testing...

I don't know a single place including all these things. In fact, in most cases we avoid including a certificate directly in a test if it can be created on the fly. --Max > On Sep 16, 2016, at 7:19 AM, Milton Smith wrote: > > Hi All, > > I'm looking for a set of

Re: RFR(M): 8166032: Fix module dependencies for javax.SSL tests

d some research yesterday. The "/javax/net/ssl/TLSCommon" lib depends on > krb5. For example, BufferOverflowUnderflowTest need to set up KDC and test > krb5 cipher suites. > > Xuelei > > On 9/15/2016 6:21 AM, Wang Weijun wrote: >> Confusing. This does not show

Re: RFR(M): 8166032: Fix module dependencies for javax.SSL tests

Confusing. This does not show why jgss is needed. I'll do some investigation. Thanks Max > 在 2016年9月14日，23:57，Sergei Kovalev 写道： > > java.lang.module.ResolutionException: Module java.naming not found, required > by java.security.jgss

Re: RFR(S): 8165689: Fix module dependencies for sun/security/pkcs11/* tests

Sorry I was thinking about another bug on TLS tests -- 8166032. What exception is thrown there if the jgss module is missing? Thanks Max > 在 2016年9月14日，23:44，Wang Weijun <weijun.w...@oracle.com> 写道： > > The example shows jdk.crypto.pkcs11 is needed, but I still

Re: RFR(S): 8165689: Fix module dependencies for sun/security/pkcs11/* tests

The example shows jdk.crypto.pkcs11 is needed, but I still don't know why java.security.jgss is. Can you give another example where jgss must be present? Thanks Max > 在 2016年9月14日，23:26，Sergei Kovalev 写道： > > Hi Sean, > > I'm working for testing minimal JRE image.

Re: RFR(M): 8166032: Fix module dependencies for javax.SSL tests

I also have no idea why these are needed: + * @modules java.security.jgss + * jdk.security.auth Do the test uses KRB5-related cipher suites? Thanks Max > On Sep 14, 2016, at 8:54 PM, Xuelei Fan wrote: > > Hi Sergei, > > Thanks for the update. The fix looks

Re: RFR: 8061842: Package jurisdiction policy files as something other than JAR

Before this change, you require default policy in neither export nor import to be empty but do not care about the getMinimum() result. In this change, you make sure the final result is not empty. I assume this is a fix? 283 // Did we find a default perms? What does this

Re: RFR : 8147772, 8163104

The changes look fine. Thanks Max > On 2016年8月10日, at 下午9:48, Seán Coffey wrote: > > Looking to backport the following two bug fixes to jdk8u-dev : > > JDK-8147772 Update KerberosTicket to describe behavior if it has been > destroyed and fix NullPointerExceptions >

  1   2   3   4   5   6   7   >