Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v4]

2022-02-15 Thread Weijun Wang
On Tue, 15 Feb 2022 16:12:17 GMT, Michael Osipov wrote: > I don't expect any new ASN.1 string types to be added in the future, but of > someone decides to create a public ASN.1 I've seen new string types that need 2 bytes tag, but don't know if they are used anywhere. Also, there are

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v5]

2022-02-15 Thread Weijun Wang
On Tue, 15 Feb 2022 15:16:58 GMT, Weijun Wang wrote: >> The enhancement adds two extra items in the `getSubjectAlternativeNames()` >> output for an OtherName. >> >> It also fix several errors: >> 1. In `OtherName.java`, `nameValue` should be the value inside `CO

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v4]

2022-02-15 Thread Weijun Wang
On Tue, 15 Feb 2022 15:59:42 GMT, Michael Osipov wrote: > > ``` > > 2. I feel a little uneasy of the new `if` and `otherwise` words inside > > parentheses, especially the second one which seems out of nowhere. Please > > suggest better wording if possible. > > ``` > > > What about? > > >

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v5]

2022-02-15 Thread Weijun Wang
On Tue, 15 Feb 2022 15:46:10 GMT, Michael Osipov wrote: >> I have difficulty describing `!(a && b)`. There is no parentheses in human >> language and `!` has higher order than `&&`. >> >> I thought about completely reverse the block but that means everything after >> the throw will be inside

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v5]

2022-02-15 Thread Weijun Wang
On Tue, 15 Feb 2022 15:28:29 GMT, Michael Osipov wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> string at 4th place > > src/java.base/share/classes/sun/security/x509/OtherName.java

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v4]

2022-02-15 Thread Weijun Wang
On Tue, 15 Feb 2022 15:50:07 GMT, Michael Osipov wrote: > Are you going to address this separately or document to be implicitly fixed > by this PR? Normally we close the other one as a duplicate. I'll do it now. - PR: https://git.openjdk.java.net/jdk/pull/7167

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v5]

2022-02-15 Thread Weijun Wang
On Tue, 15 Feb 2022 15:21:08 GMT, Michael Osipov wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> string at 4th place > > test/jdk/sun/security/x509/OtherName/Parse.java line 89: &

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v4]

2022-02-15 Thread Weijun Wang
On Fri, 11 Feb 2022 17:13:46 GMT, Weijun Wang wrote: >> The enhancement adds two extra items in the `getSubjectAlternativeNames()` >> output for an OtherName. >> >> It also fix several errors: >> 1. In `OtherName.java`, `nameValue` should be the value inside `CO

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v5]

2022-02-15 Thread Weijun Wang
gument in constructor `extClass.getConstructor(Object.class)` is > suspicious. Maybe it meant `byte[]`. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: string at 4th place - Changes: - all: https://git.openjdk.java.net/jdk

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v2]

2022-02-15 Thread Weijun Wang
On Tue, 15 Feb 2022 14:36:35 GMT, Weijun Wang wrote: >> Your words are more precise. A reader should check the size first. A new >> commit pushed and the CSR is also updated. > >> @wangweij I would highly recommend to address this ticket first: >> https://bugs.

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v4]

2022-02-15 Thread Weijun Wang
On Tue, 15 Feb 2022 09:10:22 GMT, Michael Osipov wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> specifies the type of the 4th element > > src/java.base/share/classes/sun/securi

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v2]

2022-02-15 Thread Weijun Wang
On Thu, 10 Feb 2022 21:09:45 GMT, Weijun Wang wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> wording, title > > Your words are more precise. A reader should check the size first. A ne

Re: RFR: 8277976: Break up SEQUENCE in X509Certiticate::getSubjectAlternativeNames and X509Certiticate::getIssuerAlternativeNames in otherName [v3]

2022-02-11 Thread Weijun Wang
On Fri, 11 Feb 2022 14:58:30 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> more precise spec > > src/java.base/share/classes/java/security/cert/X509Certif

Re: RFR: 8277976: Break up SEQUENCE in X509Certiticate::getSubjectAlternativeNames and X509Certiticate::getIssuerAlternativeNames in otherName [v4]

2022-02-11 Thread Weijun Wang
gument in constructor `extClass.getConstructor(Object.class)` is > suspicious. Maybe it meant `byte[]`. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: specifies the type of the 4th element - Changes: - all: https://git.openjd

Re: RFR: 8277976: Break up SEQUENCE in X509Certiticate::getSubjectAlternativeNames and X509Certiticate::getIssuerAlternativeNames in otherName [v2]

2022-02-10 Thread Weijun Wang
On Thu, 10 Feb 2022 16:47:55 GMT, Weijun Wang wrote: >> The enhancement adds two extra items in the `getSubjectAlternativeNames()` >> output for an OtherName. >> >> It also fix several errors: >> 1. In `OtherName.java`, `nameValue` should be the value inside `CO

Re: RFR: 8277976: Break up SEQUENCE in X509Certiticate::getSubjectAlternativeNames and X509Certiticate::getIssuerAlternativeNames in otherName [v3]

2022-02-10 Thread Weijun Wang
gument in constructor `extClass.getConstructor(Object.class)` is > suspicious. Maybe it meant `byte[]`. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: more precise spec - Changes: - all: https://git.openjdk.java.net/jdk/pull/7

Re: RFR: 8277976: Break up SEQUENCE in X509Certiticate::getSubjectAlternativeNames and X509Certiticate::getIssuerAlternativeNames in otherName

2022-02-10 Thread Weijun Wang
On Thu, 20 Jan 2022 19:42:22 GMT, Weijun Wang wrote: > The enhancement adds two extra items in the `getSubjectAlternativeNames()` > output for an OtherName. > > It also fix several errors: > 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` &g

Re: RFR: 8277976: Break up SEQUENCE in X509Certiticate::getSubjectAlternativeNames and X509Certiticate::getIssuerAlternativeNames in otherName [v2]

2022-02-10 Thread Weijun Wang
gument in constructor `extClass.getConstructor(Object.class)` is > suspicious. Maybe it meant `byte[]`. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: wording, title - Changes: - all: https://git.openjdk.java.net/jdk/pull/7

Re: RFR: 8277976: Break up SEQUENCE in X509Certiticate#getSubjectAlternativeNames() in otherName

2022-02-10 Thread Weijun Wang
On Thu, 10 Feb 2022 13:45:16 GMT, Sean Mullan wrote: > Looks good, but I think a CSR should also be filed. Sure, I'll write one now. I've added the `csr` label so that I will not forget about it. Just want to delay the writing after we agree on the text. >

Re: RFR: 8265765: DomainKeyStore may stop enumerating aliases if a constituting KeyStore is empty [v2]

2022-02-09 Thread Weijun Wang
On Wed, 9 Feb 2022 06:34:40 GMT, Hai-May Chao wrote: >> This is to fix `DomainKeyStore::engineAliases` to take into account that >> there may be empty keystore(s) within the collection of keystores of a >> domain keystore. > > Hai-May Chao has updated the pull request incrementally with one

Re: RFR: 8265765: DomainKeyStore may stop enumerating aliases if a constituting KeyStore is empty

2022-02-08 Thread Weijun Wang
On Tue, 8 Feb 2022 17:13:53 GMT, Hai-May Chao wrote: > This is to fix `DomainKeyStore::engineAliases` to take into account that > there may be empty keystore(s) within the collection of keystores of a domain > keystore. Looks good to me. Do you want to play with text blocks in the test for

Integrated: 8281175: Add a -providerPath option to jarsigner

2022-02-07 Thread Weijun Wang
On Thu, 3 Feb 2022 17:12:05 GMT, Weijun Wang wrote: > Add the `-providerPath` option to jarsigner to be consistent with keytool. This pull request has now been integrated. Changeset: 2ed1f4cf Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/com

Re: RFR: 8280890: Cannot use '-Djava.system.class.loader' with class loader in signed JAR

2022-02-04 Thread Weijun Wang
On Tue, 1 Feb 2022 21:54:29 GMT, Sean Mullan wrote: > This fixes a bootstrapping issue if a custom system class loader is set with > the `-Djava.system.class.loader` option and the custom class loader is inside > a signed JAR. In order to load the custom class loader, the runtime must >

Re: RFR: 8281234: The -protected option is not always checked in keytool and jarsigner [v2]

2022-02-03 Thread Weijun Wang
> The option means there is no need to provide a password when loading a > keystore. In some places in jarsigner and keytool, even with the option > specified, password is still prompted for or warnings are still shown. Weijun Wang has updated the pull request incrementally with one a

Re: RFR: 8281175: Add a -providerPath option to jarsigner [v2]

2022-02-03 Thread Weijun Wang
On Thu, 3 Feb 2022 19:11:17 GMT, Hai-May Chao wrote: > Code change looks good to me. > I have a comment on the CSR. The “Options for jarsigner” section in > `jarsigner` manpage, where it describes `-digestalg algorithm` and `-sigalg > algorithm`, we would update it to include this new option

RFR: 8281234: The -protected option is not always checked in keytool and jarsigner

2022-02-03 Thread Weijun Wang
The option means there is no need to provide a password when loading a keystore. In some places in jarsigner and keytool, even with the option specified, password is still prompted for or warnings are still shown. - Commit messages: - 8281234: The -protected option is not always

Re: RFR: 8281175: Add a -providerPath option to jarsigner [v2]

2022-02-03 Thread Weijun Wang
> Add the `-providerPath` option to jarsigner to be consistent with keytool. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: no need to append to null - Changes: - all: https://git.openjdk.java.net/jdk/pull/7338/fi

Re: RFR: 8281175: Add a -providerPath option to jarsigner

2022-02-03 Thread Weijun Wang
On Thu, 3 Feb 2022 18:03:48 GMT, Xue-Lei Andrew Fan wrote: >> Add the `-providerPath` option to jarsigner to be consistent with keytool. > > src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 256: > >> 254: String path = null; >> 255:

RFR: 8281175: Add a -providerPath option to jarsigner

2022-02-03 Thread Weijun Wang
Add the `-providerPath` option to jarsigner to be consistent with keytool. - Commit messages: - 8281175: Add a -providerPath option to jarsigner Changes: https://git.openjdk.java.net/jdk/pull/7338/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7338=00 Issue:

Re: RFR: 8065422: Trailing dot in hostname causes TLS handshake to fail with SNI disabled [v3]

2022-02-02 Thread Weijun Wang
On Thu, 3 Feb 2022 03:42:33 GMT, Xue-Lei Andrew Fan wrote: >> A hostname in an URL ending with a dot is valid (See RFC 1034). However, it >> is not a valid SNI hostname. The ending dot should be ignored while >> checking the hostname with SNI or the name in a X.509 certificate. >> >> The

Re: RFR: 8065422: Trailing dot in hostname causes TLS handshake to fail with SNI disabled [v2]

2022-02-02 Thread Weijun Wang
On Wed, 26 Jan 2022 18:58:07 GMT, Xue-Lei Andrew Fan wrote: >> A hostname in an URL ending with a dot is valid (See RFC 1034). However, it >> is not a valid SNI hostname. The ending dot should be ignored while >> checking the hostname with SNI or the name in a X.509 certificate. >> >> The

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v10]

2022-01-26 Thread Weijun Wang
On Wed, 26 Jan 2022 16:25:24 GMT, Daniel Fuchs wrote: >> Michael McMahon has updated the pull request incrementally with one >> additional commit since the last revision: >> >> removed ^M from test > > test/jdk/sun/security/krb5/auto/HttpsCB.java line 120: > >> 118: >> 119: boolean

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v10]

2022-01-26 Thread Weijun Wang
On Wed, 26 Jan 2022 16:27:29 GMT, Daniel Fuchs wrote: >> Michael McMahon has updated the pull request incrementally with one >> additional commit since the last revision: >> >> removed ^M from test > > test/jdk/sun/security/krb5/auto/HttpsCB.java line 201: > >> 199: return

Re: RFR: 8065422: Trailing dot in hostname causes TLS handshake to fail with SNI disabled

2022-01-25 Thread Weijun Wang
On Tue, 25 Jan 2022 00:13:32 GMT, Xue-Lei Andrew Fan wrote: > A hostname in an URL ending with a dot is valid (See RFC 1034). However, it > is not a valid SNI hostname. The ending dot should be ignored while checking > the hostname with SNI or the name in a X.509 certificate. > > The update

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v7]

2022-01-24 Thread Weijun Wang
On Mon, 24 Jan 2022 22:11:51 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS >> (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, >> Kerberos) authentication scheme. When enabled, the implementation >> preemptively

Re: RFR: 8255739: x509Certificate returns � for invalid subjectAlternativeNames [v2]

2022-01-24 Thread Weijun Wang
On Fri, 14 Jan 2022 11:18:23 GMT, Masanori Yano wrote: >> Could you please review the JDK-8255739 bug fix? >> >> I think sun.security.x509.SubjectAlternativeNameExtension() should throw an >> exception for incorrect SubjectAlternativeNames instead of returning the >> substituted characters,

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6]

2022-01-24 Thread Weijun Wang
On Mon, 24 Jan 2022 15:54:01 GMT, Michael McMahon wrote: >> src/java.base/share/classes/sun/security/util/TlsChannelBinding.java line >> 100: >> >>> (failed to retrieve contents of file, check the PR for context) >> I think this method should stay here. Suppose one day the CBT type is >>

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6]

2022-01-24 Thread Weijun Wang
On Mon, 24 Jan 2022 13:54:12 GMT, Daniel Fuchs wrote: >> Michael McMahon has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains eight additional >>

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v4]

2022-01-24 Thread Weijun Wang
On Fri, 21 Jan 2022 15:40:16 GMT, Daniel Fuchs wrote: >> Michael McMahon has updated the pull request incrementally with one >> additional commit since the last revision: >> >> more tidy-up > > src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java line 144: > >> 142:

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v6]

2022-01-24 Thread Weijun Wang
On Mon, 24 Jan 2022 13:36:47 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS >> (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, >> Kerberos) authentication scheme. When enabled, the implementation >> preemptively

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v5]

2022-01-21 Thread Weijun Wang
On Fri, 21 Jan 2022 16:02:29 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS >> (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, >> Kerberos) authentication scheme. When enabled, the implementation >> preemptively

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v5]

2022-01-21 Thread Weijun Wang
On Fri, 21 Jan 2022 16:02:29 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS >> (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, >> Kerberos) authentication scheme. When enabled, the implementation >> preemptively

Integrated: 8280401: [sspi] gss_accept_sec_context leaves output_token uninitialized

2022-01-20 Thread Weijun Wang
On Thu, 20 Jan 2022 18:19:19 GMT, Weijun Wang wrote: > Set `output_token` to empty. It is always accessed (even for a > `GSS_S_FAILURE`) at > https://github.com/openjdk/jdk/blob/cfa3f7493149170f2b23a516bc95110dab43fd06/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c#L1160.

RFR: 8277976: Break up SEQUENCE in X509Certiticate#getSubjectAlternativeNames() in otherName

2022-01-20 Thread Weijun Wang
The enhancement adds two extra items in the `getSubjectAlternativeNames()` output for an OtherName. It also fix several errors: 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` without the tag and length bytes. 2. The argument in constructor

RFR: 8280401: [sspi] gss_accept_sec_context leaves output_token uninitialized

2022-01-20 Thread Weijun Wang
Set `output_token` to empty. It is always accessed (even for a `GSS_S_FAILURE`) at https://github.com/openjdk/jdk/blob/cfa3f7493149170f2b23a516bc95110dab43fd06/src/java.security.jgss/share/native/libj2gss/GSSLibStub.c#L1160. - Commit messages: - 8280401: [sspi]

Integrated: 8279796: Fix typo: Constucts -> Constructs

2022-01-19 Thread Weijun Wang
On Wed, 19 Jan 2022 22:18:32 GMT, Weijun Wang wrote: > Two edits. This pull request has now been integrated. Changeset: 98d96a77 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/98d96a770756ffe3e7f5e4b82120e9fb484cad9a Stats: 2 lines in 1 file changed: 0 ins

Re: RFR: 8279796: Fix typo: Constucts -> Constructs [v2]

2022-01-19 Thread Weijun Wang
> Two edits. Weijun Wang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision: - year - Upd

Re: RFR: 8279796: Fix typo: Constucts -> Constructs

2022-01-19 Thread Weijun Wang
On Wed, 19 Jan 2022 22:57:06 GMT, Sergey Bylokhov wrote: >> Two edits. > > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java > line 727: > >> 725: Handler handler; >> 726: /** >> 727: * Constructs a {@code DoubleClickListener}. > > This

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v2]

2022-01-19 Thread Weijun Wang
On Wed, 19 Jan 2022 22:20:47 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS >> (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, >> Kerberos) authentication scheme. When enabled, the implementation >> preemptively

RFR: 8279796: Fix typo: Constucts -> Constructs

2022-01-19 Thread Weijun Wang
Two edits. - Commit messages: - Another year - year - Update DigestMD5Base.java - 8279796: Fix typo: Constucts -> Constructs Changes: https://git.openjdk.java.net/jdk/pull/7147/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7147=00 Issue:

Re: RFR: 8280122: SupportedGroupsExtension should output "named groups" rather than "versions"

2022-01-18 Thread Weijun Wang
On Tue, 18 Jan 2022 19:33:19 GMT, Xue-Lei Andrew Fan wrote: >> If so, should the `SupportedVersionsExtension` get a more precise >> description as well? > >> If so, should the `SupportedVersionsExtension` get a more precise >> description as well? > > I did not get the point. Did you mean to

Re: RFR: 8280122: SupportedGroupsExtension should output "named groups" rather than "versions"

2022-01-18 Thread Weijun Wang
On Tue, 18 Jan 2022 16:13:42 GMT, Xue-Lei Andrew Fan wrote: >> MessageFormat messageFormat = new MessageFormat( >> ""versions": '['{0}']'", Locale.ENGLISH); >> >> In class SupportedGroupsExtension, the above "versions" should be "named >> groups". > >

Re: RFR: 8280122: SupportedGroupsExtension should output "named groups" rather than "versions"

2022-01-18 Thread Weijun Wang
On Tue, 18 Jan 2022 11:11:49 GMT, John Jiang wrote: > MessageFormat messageFormat = new MessageFormat( > ""versions": '['{0}']'", Locale.ENGLISH); > > In class SupportedGroupsExtension, the above "versions" should be "named > groups". Marked as reviewed by weijun (Reviewer).

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos

2022-01-14 Thread Weijun Wang
On Fri, 14 Jan 2022 10:18:50 GMT, Daniel Fuchs wrote: >> This is what was intended (equivalent) >> >> `if (s ==null || (s!="always" && s!="never" && !s.startsWith("domain")))` > > Argh - you're right I missed the fact that the 3 expressions where included > in parenthesis. I read it as > > !

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos

2022-01-14 Thread Weijun Wang
On Fri, 14 Jan 2022 18:40:41 GMT, Michael McMahon wrote: >> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 152: >> >>> 150: * If enabled (for a particular destination) then SPNEGO >>> authentication requests will include >>> 151: * a channel binding token for the

Re: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos

2022-01-14 Thread Weijun Wang
On Fri, 14 Jan 2022 18:42:08 GMT, Michael McMahon wrote: >> src/java.security.jgss/share/classes/module-info.java line 36: >> >>> 34: module java.security.jgss { >>> 35: requires java.naming; >>> 36: requires java.security.sasl; >> >> Someone from security-dev should probably review

Integrated: 8279064: New options for ktab to provide non-default salt

2022-01-14 Thread Weijun Wang
On Fri, 7 Jan 2022 19:35:56 GMT, Weijun Wang wrote: > Please review this enhancement and its > [CSR](https://bugs.openjdk.java.net/browse/JDK-8279632). Two new options `-s > salt` and `-f` can be specified on the `ktab` command when adding entries. > > I'm a little

Re: RFR: 8279064: New options for ktab to provide non-default salt [v2]

2022-01-14 Thread Weijun Wang
On Thu, 13 Jan 2022 21:40:16 GMT, Weijun Wang wrote: >> Please review this enhancement and its >> [CSR](https://bugs.openjdk.java.net/browse/JDK-8279632). Two new options `-s >> salt` and `-f` can be specified on the `ktab` command when adding entries. >> >>

Re: RFR: 8278851: Correct signer logic for jars signed with multiple digestalgs [v2]

2022-01-13 Thread Weijun Wang
On Thu, 13 Jan 2022 21:57:57 GMT, Sean Mullan wrote: >> If a JAR is signed with multiple digest algorithms and one of the digest >> algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly >> returning null indicating that the jar entry has no signers. >> >> This fixes the

Re: RFR: 8278851: Correct signer logic for jars signed with multiple digestalgs [v2]

2022-01-13 Thread Weijun Wang
On Thu, 13 Jan 2022 19:54:44 GMT, Sean Mullan wrote: >> src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java >> line 211: >> >>> 209: } >>> 210: >>> 211: CodeSigner[] entrySigners = sigFileSigners.get(name); >> >> What if we return here if `entrySigners ==

Re: RFR: 8279064: New options for ktab to provide non-default salt [v2]

2022-01-13 Thread Weijun Wang
On Thu, 13 Jan 2022 20:26:05 GMT, Valerie Peng wrote: >> Same goes for test/jdk/sun/security/krb5/auto/Context.java. > > And test/jdk/sun/security/krb5/tools/KtabCheck.java. Yes. - PR: https://git.openjdk.java.net/jdk/pull/6991

Re: RFR: 8279064: New options for ktab to provide non-default salt [v2]

2022-01-13 Thread Weijun Wang
On Thu, 13 Jan 2022 19:45:37 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> duplicate words, and another year > > src/java.security.jgss/windows/classes/sun/security

Re: RFR: 8279064: New options for ktab to provide non-default salt [v2]

2022-01-13 Thread Weijun Wang
On Thu, 13 Jan 2022 19:52:55 GMT, Valerie Peng wrote: >> src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Ktab.java >> line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2003, 2021, Oracle and/or its affiliates. All rights >>> reserved. >> >> 2022 > > Same goes for

Re: RFR: 8279064: New options for ktab to provide non-default salt [v2]

2022-01-13 Thread Weijun Wang
tructor which always uses the default salt. For consistency, it looks > like a new constructor should be added that takes the salt string as a > parameter as well. However, I don't intend to add it as I cannot see a proper > usage for it. In fact, I now regret adding the constructor link

Re: RFR: 8278851: Correct signer logic for jars signed with multiple digestalgs

2022-01-13 Thread Weijun Wang
On Wed, 12 Jan 2022 21:57:22 GMT, Sean Mullan wrote: > If a JAR is signed with multiple digest algorithms and one of the digest > algorithms is disabled, `ManifestEntryVerifier.verify()` was incorrectly > returning null indicating that the jar entry has no signers. > > This fixes the issue

Integrated: 8279801: EC KeyFactory and KeyPairGenerator do not have aliases for OID format

2022-01-13 Thread Weijun Wang
On Tue, 11 Jan 2022 20:34:59 GMT, Weijun Wang wrote: > Add OID aliases for the 2 service. This makes sure KeyFactory can be created > and read an encoded key without knowing what the OID in the encoding is for. This pull request has now been integrated. Changeset: 0a839b43 Author:

Integrated: 8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards

2022-01-12 Thread Weijun Wang
On Tue, 11 Jan 2022 20:38:30 GMT, Weijun Wang wrote: > Change the order so parent class is at the left. This pull request has now been integrated. Changeset: cb250298 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/cb25029885b176be9ebbc84ac1a8ba71be96a6a7 St

Re: RFR: 8279801: EC KeyFactory and KeyPairGenerator do not have aliases for OID format

2022-01-12 Thread Weijun Wang
On Wed, 12 Jan 2022 21:22:34 GMT, Valerie Peng wrote: >> src/jdk.crypto.ec/share/classes/sun/security/ec/SunEC.java line 322: >> >>> 320: */ >>> 321: putService(new ProviderServiceA(this, "KeyPairGenerator", >>> 322: "EC", "sun.security.ec.ECKeyPairGenerator",

Re: RFR: 8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards

2022-01-12 Thread Weijun Wang
On Tue, 11 Jan 2022 20:38:30 GMT, Weijun Wang wrote: > Change the order so parent class is at the left. New commit pushed. Turns out `PBKDF2HmacSHA1Factory.java` is useless now. The algorithm is now implemented as a sub-class of `PBKDF2Core`. - PR: https://git.openjdk.java.

Re: RFR: 8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards [v2]

2022-01-12 Thread Weijun Wang
> Change the order so parent class is at the left. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: 8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards - Chan

Re: RFR: 8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards

2022-01-12 Thread Weijun Wang
On Wed, 12 Jan 2022 19:31:31 GMT, Valerie Peng wrote: >> If so, then the `if` block will be true and the spec object is casted to >> your specified class (`AlgorithmParameterSpec.class` or `Object.class`) and >> it always succeeds. >> >> This is exactly what I want to achieve. In fact, this

Re: RFR: 8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards

2022-01-12 Thread Weijun Wang
On Wed, 12 Jan 2022 19:41:31 GMT, Valerie Peng wrote: >> Change the order so parent class is at the left. > > test/jdk/java/security/spec/IsAssignableFromOrder.java line 72: > >> 70: static void test(String algorithm, AlgorithmParameterSpec spec, >> 71: Class... classes) throws

Re: RFR: 8279903: Redundant modulo operation in ECDHKeyAgreement [v2]

2022-01-12 Thread Weijun Wang
On Wed, 12 Jan 2022 07:29:04 GMT, John Jiang wrote: >> In class `sun.security.ec.ECDHKeyAgreement`, the last `mod()` in the below >> line looks redundant, >> >> BigInteger lhs = y.modPow(BigInteger.valueOf(2), p).mod(p); >> >> I think this tiny change just be a code cleanup, so no test for it

Re: RFR: 8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards

2022-01-12 Thread Weijun Wang
On Wed, 12 Jan 2022 06:08:29 GMT, Xue-Lei Andrew Fan wrote: >> Change the order so parent class is at the left. > > src/java.base/share/classes/com/sun/crypto/provider/BlockCipherParamsCore.java > line 111: > >> 109: T getParameterSpec(Class >> paramSpec) >> 110: throws

RFR: 8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards

2022-01-11 Thread Weijun Wang
Change the order so parent class is at the left. - Commit messages: - 8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards Changes: https://git.openjdk.java.net/jdk/pull/7037/files Webrev:

RFR: 8279801: EC KeyFactory and KeyPairGenerator do not have aliases for OID format

2022-01-11 Thread Weijun Wang
Add OID aliases for the 2 service. This makes sure KeyFactory can be created and read an encoded key without knowing what the OID in the encoding is for. - Commit messages: - 8279801: EC KeyFactory and KeyPairGenerator do not have aliases for OID format Changes:

Re: RFR: 8275918: Remove unused local variables in java.base security code [v3]

2022-01-10 Thread Weijun Wang
On Wed, 27 Oct 2021 18:49:26 GMT, Andrey Turbanov wrote: >> Cleanup unused local variables. Looks like they are leftovers after >> refactoring. > > Andrey Turbanov has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains three commits: >

RFR: 8279064: New options for ktab to provide non-default salt

2022-01-07 Thread Weijun Wang
Please review this enhancement and its [CSR](https://bugs.openjdk.java.net/browse/JDK-8279632). Two new options `-s salt` and `-f` can be specified on the `ktab` command when adding entries. I'm a little concerned about the compatibility risk described in the CSR, i.e. the `-f` option is

Re: RFR: 8255739: x509Certificate returns � for invalid subjectAlternativeNames

2022-01-06 Thread Weijun Wang
On Thu, 23 Dec 2021 11:59:18 GMT, Masanori Yano wrote: > Could you please review the JDK-8255739 bug fix? > > I think sun.security.x509.SubjectAlternativeNameExtension() should throw an > exception for incorrect SubjectAlternativeNames instead of returning the > substituted characters, which

Integrated: 8279520: SPNEGO has not passed channel binding info into the underlying mechanism

2022-01-06 Thread Weijun Wang
On Wed, 5 Jan 2022 16:25:27 GMT, Weijun Wang wrote: > 8279520: SPNEGO has not passed channel binding info into the underlying > mechanism This pull request has now been integrated. Changeset: 8d0f385f Author:Weijun Wang URL: https://git.openjdk.java.net/jdk/

RFR: 8279520: SPNEGO has not passed channel binding info into the underlying mechanism

2022-01-05 Thread Weijun Wang
8279520: SPNEGO has not passed channel binding info into the underlying mechanism - Commit messages: - 8279520: SPNEGO has not passed channel binding info into the underlying mechanism Changes: https://git.openjdk.java.net/jdk/pull/6969/files Webrev:

Re: RFR: JDK-8279385: [test] Adjust sun/security/pkcs12/KeytoolOpensslInteropTest.java after 8278344

2022-01-03 Thread Weijun Wang
On Mon, 3 Jan 2022 14:52:13 GMT, Matthias Baesken wrote: > Hello , please review this XXS test adjustment. After 8278344, it has been > commented that better shouldMatch should be used for the adjusted test > parsing output of different OpenSSL versions. Hurray! I see 2022! -

Re: RFR: 8209398: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failed with "PKCS11Exception: CKR_ATTRIBUTE_SENSITIVE"

2021-12-22 Thread Weijun Wang
On Tue, 14 Dec 2021 18:33:47 GMT, Valerie Peng wrote: > Can someone help review this small fix? NSS returns PKCS11 > CKR_ATTRIBUTE_SENSITIVE error when trying to retrieve CKA_VALUE out of its > token keys. So this fix is to add special handling for NSS token secret keys. > There is already an

Re: RFR: 8209398: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failed with "PKCS11Exception: CKR_ATTRIBUTE_SENSITIVE"

2021-12-21 Thread Weijun Wang
On Tue, 14 Dec 2021 18:33:47 GMT, Valerie Peng wrote: > Can someone help review this small fix? NSS returns PKCS11 > CKR_ATTRIBUTE_SENSITIVE error when trying to retrieve CKA_VALUE out of its > token keys. So this fix is to add special handling for NSS token secret keys. > There is already an

Re: RFR: 8209398: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failed with "PKCS11Exception: CKR_ATTRIBUTE_SENSITIVE"

2021-12-21 Thread Weijun Wang
On Tue, 14 Dec 2021 18:33:47 GMT, Valerie Peng wrote: > Can someone help review this small fix? NSS returns PKCS11 > CKR_ATTRIBUTE_SENSITIVE error when trying to retrieve CKA_VALUE out of its > token keys. So this fix is to add special handling for NSS token secret keys. > There is already an

Integrated: 8279066: entries.remove(entry) is useless in PKCS12KeyStore

2021-12-21 Thread Weijun Wang
On Tue, 21 Dec 2021 16:31:57 GMT, Weijun Wang wrote: > Before password-less PKCS12 keystores are supported, certificates in a PKCS12 > file are always encrypted. Therefore if one loads the keystore with a null > pass, it contains `PrivateKeyEntry`s without certificates. This has alway

Re: RFR: 8279066: entries.remove(entry) is useless in PKCS12KeyStore

2021-12-21 Thread Weijun Wang
On Tue, 21 Dec 2021 16:31:57 GMT, Weijun Wang wrote: > Before password-less PKCS12 keystores are supported, certificates in a PKCS12 > file are always encrypted. Therefore if one loads the keystore with a null > pass, it contains `PrivateKeyEntry`s without certificates. This has alway

Re: RFR: 8279066: entries.remove(entry) is useless in PKCS12KeyStore [v2]

2021-12-21 Thread Weijun Wang
u can find out a usage of a > private key entry without any certificate and think it's worth kept that way, > I can simply remove the `remove` call and leave the entry there. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

Re: RFR: 8279043: Some Security Exception Messages Miss Spaces

2021-12-21 Thread Weijun Wang
On Mon, 20 Dec 2021 14:50:08 GMT, Daniel Jeliński wrote: > Trivial change. Issue reported by > [lgtm.com](https://lgtm.com/projects/g/openjdk/jdk/alerts/?mode=tree=java=1952840153). Thanks. I'll run some tests before sponsoring it. Hopefully no one uses the exact exception message as a golden

Re: RFR: 8279043 Some Security Exception Messages Miss Spaces

2021-12-21 Thread Weijun Wang
On Mon, 20 Dec 2021 14:50:08 GMT, Daniel Jeliński wrote: > Trivial change. Issue reported by > [lgtm.com](https://lgtm.com/projects/g/openjdk/jdk/alerts/?mode=tree=java=1952840153). Change looks good. Please add a colon after the bug ID in the title. Otherwise Skara might not integrate it.

RFR: 8279066: Still see private key entries without certificates in a PKCS12 keystore

2021-12-21 Thread Weijun Wang
Before password-less PKCS12 keystores are supported, certificates in a PKCS12 file are always encrypted. Therefore if one loads the keystore with a null pass, it contains `PrivateKeyEntry`s without certificates. This has always been awkward (and most likely useless) so when JDK-8076190

Integrated: 8278560: X509KeyManagerImpl::getAliases might return a good key with others

2021-12-17 Thread Weijun Wang
On Fri, 10 Dec 2021 23:09:46 GMT, Weijun Wang wrote: > Perfect match does not always appear at the beginning if there are multiple > KeyTypes. This pull request has now been integrated. Changeset: 6412d57a Author:Weijun Wang URL: https://git.openjdk.java.net/jdk/

Integrated: 8278186: org.jcp.xml.dsig.internal.dom.Utils.parseIdFromSameDocumentURI throws StringIndexOutOfBoundsException when calling substring method

2021-12-15 Thread Weijun Wang
On Wed, 8 Dec 2021 15:36:36 GMT, Weijun Wang wrote: > Add check on `xpointer(id('name'))` format. This pull request has now been integrated. Changeset: 1f1db838 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/1f1db838ab7d427170d59a8b55fdb45c4d80c359 Stats:

[jdk18] Integrated: 8278744: KeyStore:getAttributes() not returning unmodifiable Set

2021-12-14 Thread Weijun Wang
On Tue, 14 Dec 2021 15:24:58 GMT, Weijun Wang wrote: > Make the return value of `PKCS12KeyStore::engineGetAttributes` immutable. > Gather the `getAttributes()` value into a new `HashSet` and then make it > immutable. This ensures the final result itself is not mutable an

Withdrawn: 8255266: 2021-11-27 public suffix list update v 3c213aa

2021-12-14 Thread Weijun Wang
On Wed, 1 Dec 2021 17:03:24 GMT, Weijun Wang wrote: > Update Public Suffix List data to the latest version at > https://github.com/publicsuffix/list. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/6643

Re: RFR: JDK-8278344: sun/security/pkcs12/KeytoolOpensslInteropTest.java test fails because of different openssl output

2021-12-13 Thread Weijun Wang
On Thu, 9 Dec 2021 08:25:17 GMT, Matthias Baesken wrote: > Please review this small test fix. > KeytoolOpensslInteropTest.java fails with the output below. > Seems on our SUSE Linux 15 (openssl is > ~> openssl version > OpenSSL 1.1.0i-fips 14 Aug 2018 > ) we get a slightly different output with

RFR: 8278560: X509KeyManagerImpl::getAliases might return a good key with others

2021-12-10 Thread Weijun Wang
Perfect match does not always appear at the beginning if there are multiple KeyTypes. - Commit messages: - 8278560: X509KeyManagerImpl::getAliases might return a good key with others Changes: https://git.openjdk.java.net/jdk/pull/6804/files Webrev:

[jdk18] Withdrawn: 8278186: throw StringIndexOutOfBoundsException when calling substring method

2021-12-09 Thread Weijun Wang
On Thu, 9 Dec 2021 19:34:12 GMT, Weijun Wang wrote: > Add check on `xpointer(id('name'))` format. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk18/pull/1

Withdrawn: 8278186: throw StringIndexOutOfBoundsException when calling substring method

2021-12-09 Thread Weijun Wang
On Wed, 8 Dec 2021 15:36:36 GMT, Weijun Wang wrote: > Add check on `xpointer(id('name'))` format. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/6769

[jdk18] RFR: 8278186: throw StringIndexOutOfBoundsException when calling substring method

2021-12-09 Thread Weijun Wang
Add check on `xpointer(id('name'))` format. - Commit messages: - 8278186: throw StringIndexOutOfBoundsException when calling substring method Changes: https://git.openjdk.java.net/jdk18/pull/1/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18=1=00 Issue:

<    1   2   3   4   5   6   7   8   9   10   >