Integrated: 8282077: PKCS11 provider C_sign() impl should handle CKR_BUFFER_TOO_SMALL error
On Fri, 18 Feb 2022 21:52:59 GMT, Valerie Peng wrote: > Could someone please help review this trivial change? This is to add an error > handling for the potential CKR_BUFFER_TOO_SMALL error when calling C_Sign(). > Since none of the supported signature algorithms trigger this error as the > default buffer size is large enough, this is more for consistency sake. No > new regression test for this and thus the @noreg-hard label. > > Thanks, > Valerie This pull request has now been integrated. Changeset: d7f31d0d Author:Valerie Peng URL: https://git.openjdk.java.net/jdk/commit/d7f31d0d53bfec627edc83ceb75fc6202891e186 Stats: 12 lines in 1 file changed: 11 ins; 0 del; 1 mod 8282077: PKCS11 provider C_sign() impl should handle CKR_BUFFER_TOO_SMALL error Reviewed-by: mikael - PR: https://git.openjdk.java.net/jdk/pull/7540
Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v9]
On Fri, 18 Feb 2022 20:05: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 `CONTEXT [0]` >> without the tag and length bytes. >> 2. The argument 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: > > make exception message clearer That's my intent, as the (updated) spec says, only a "valid supported char string" is converted, otherwise the raw bytes. The original `makeAltNames` method could fail for several reasons, but I don't want the updated one to fail for more. - PR: https://git.openjdk.java.net/jdk/pull/7167
Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v8]
On 2/18/2022 3:05 PM, Weijun Wang wrote: On Thu, 17 Feb 2022 16:00: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 `CONTEXT [0]` without the tag and length bytes. 2. The argument 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: s/can/may/ _Mailing list message from Michael StJohns... I'll use your exception message on not a `[0]`. For dealing with the error while the parsing of `nameValue`, we've discussed it and my last comment is at https://github.com/openjdk/jdk/pull/7167#discussion_r81016. I'd rather not fail. - PR: https://git.openjdk.java.net/jdk/pull/7167 Hi Weijun - You're already adding an error condition for a badly encoded OtherName that wasn't there before. Extending that error condition check to cover the wrapped ASN1 object doesn't seem to me to be much of a stretch. Looking at the OtherName specifications, there shouldn't be any ambiguity here - ANY is required to be a valid ASN1 encoded object. Hmm... wouldn't these (both) errors be masked by the location in X509CertImpl you were discussing? E.g. you're still going to have the raw bytes, but the IOException(s) will just be captured (and maybe logged per Sean's suggestion) and ignored. Later, Mike
Re: RFR: 8282077: PKCS11 provider C_sign() impl should handle CKR_BUFFER_TOO_SMALL error [v2]
On Sat, 19 Feb 2022 00:07:34 GMT, Valerie Peng wrote: >> Could someone please help review this trivial change? This is to add an >> error handling for the potential CKR_BUFFER_TOO_SMALL error when calling >> C_Sign(). Since none of the supported signature algorithms trigger this >> error as the default buffer size is large enough, this is more for >> consistency sake. No new regression test for this and thus the @noreg-hard >> label. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional > commit since the last revision: > > free allocated 'ckpData' upon OOM. Thanks for the review! Will proceed with integration once the checks completed... - PR: https://git.openjdk.java.net/jdk/pull/7540
Re: RFR: 8282077: PKCS11 provider C_sign() impl should handle CKR_BUFFER_TOO_SMALL error [v2]
On Sat, 19 Feb 2022 00:07:34 GMT, Valerie Peng wrote: >> Could someone please help review this trivial change? This is to add an >> error handling for the potential CKR_BUFFER_TOO_SMALL error when calling >> C_Sign(). Since none of the supported signature algorithms trigger this >> error as the default buffer size is large enough, this is more for >> consistency sake. No new regression test for this and thus the @noreg-hard >> label. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional > commit since the last revision: > > free allocated 'ckpData' upon OOM. Marked as reviewed by mikael (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7540
Re: RFR: 8282077: PKCS11 provider C_sign() impl should handle CKR_BUFFER_TOO_SMALL error [v2]
> Could someone please help review this trivial change? This is to add an error > handling for the potential CKR_BUFFER_TOO_SMALL error when calling C_Sign(). > Since none of the supported signature algorithms trigger this error as the > default buffer size is large enough, this is more for consistency sake. No > new regression test for this and thus the @noreg-hard label. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: free allocated 'ckpData' upon OOM. - Changes: - all: https://git.openjdk.java.net/jdk/pull/7540/files - new: https://git.openjdk.java.net/jdk/pull/7540/files/19d1451a..67d70e9d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7540=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7540=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7540.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7540/head:pull/7540 PR: https://git.openjdk.java.net/jdk/pull/7540
Re: RFR: 8282077: PKCS11 provider C_sign() impl should handle CKR_BUFFER_TOO_SMALL error
On Fri, 18 Feb 2022 22:10:17 GMT, Mikael Vidstedt wrote:
>> Could someone please help review this trivial change? This is to add an
>> error handling for the potential CKR_BUFFER_TOO_SMALL error when calling
>> C_Sign(). Since none of the supported signature algorithms trigger this
>> error as the default buffer size is large enough, this is more for
>> consistency sake. No new regression test for this and thus the @noreg-hard
>> label.
>>
>> Thanks,
>> Valerie
>
> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_sign.c line 151:
>
>> 149: if (bufP == NULL) {
>> 150: throwOutOfMemoryError(env, 0);
>> 151: return NULL;
>
> Does ckpData need to be freed here?
Yes, good catch. I will change it with a cleanup label and jump to the cleanup
label as in other methods.
-
PR: https://git.openjdk.java.net/jdk/pull/7540
Re: RFR: 8282077: PKCS11 provider C_sign() impl should handle CKR_BUFFER_TOO_SMALL error
On Fri, 18 Feb 2022 21:52:59 GMT, Valerie Peng wrote:
> Could someone please help review this trivial change? This is to add an error
> handling for the potential CKR_BUFFER_TOO_SMALL error when calling C_Sign().
> Since none of the supported signature algorithms trigger this error as the
> default buffer size is large enough, this is more for consistency sake. No
> new regression test for this and thus the @noreg-hard label.
>
> Thanks,
> Valerie
src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_sign.c line 151:
> 149: if (bufP == NULL) {
> 150: throwOutOfMemoryError(env, 0);
> 151: return NULL;
Does ckpData need to be freed here?
-
PR: https://git.openjdk.java.net/jdk/pull/7540
RFR: 8282077: PKCS11 provider C_sign() impl should handle CKR_BUFFER_TOO_SMALL error
Could someone please help review this trivial change? This is to add an error handling for the potential CKR_BUFFER_TOO_SMALL error when calling C_Sign(). Since none of the supported signature algorithms trigger this error as the default buffer size is large enough, this is more for consistency sake. No new regression test for this and thus the @noreg-hard label. Thanks, Valerie - Commit messages: - 8282077: PKCS11 provider C_sign() impl should handle CKR_BUFFER_TOO_SMALL error Changes: https://git.openjdk.java.net/jdk/pull/7540/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7540=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282077 Stats: 11 lines in 1 file changed: 10 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7540.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7540/head:pull/7540 PR: https://git.openjdk.java.net/jdk/pull/7540
Integrated: 8277488: Add expiry exception for Digicert (geotrustglobalca) expiring in May 2022
On Fri, 18 Feb 2022 18:24:46 GMT, Rajan Halade wrote: > We are checking with CA if root cert can be removed. Meanwhile, updated test > to add expiry exception. This pull request has now been integrated. Changeset: d3749de4 Author:Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/d3749de47832c6de4bcee9cf64a0b698e796b2f2 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8277488: Add expiry exception for Digicert (geotrustglobalca) expiring in May 2022 Reviewed-by: weijun - PR: https://git.openjdk.java.net/jdk/pull/7537
Re: RFR: 8277488: Add expiry exception for Digicert (geotrustglobalca) expiring in May 2022
On Fri, 18 Feb 2022 18:24:46 GMT, Rajan Halade wrote: > We are checking with CA if root cert can be removed. Meanwhile, updated test > to add expiry exception. Looks fine to me. - Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7537
Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v9]
> 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 `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: make exception message clearer - Changes: - all: https://git.openjdk.java.net/jdk/pull/7167/files - new: https://git.openjdk.java.net/jdk/pull/7167/files/5043812c..96b6b7ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7167=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7167=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7167.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7167/head:pull/7167 PR: https://git.openjdk.java.net/jdk/pull/7167
Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v8]
On Thu, 17 Feb 2022 16:00: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 `CONTEXT [0]` >> without the tag and length bytes. >> 2. The argument 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: > > s/can/may/ > _Mailing list message from Michael StJohns... I'll use your exception message on not a `[0]`. For dealing with the error while the parsing of `nameValue`, we've discussed it and my last comment is at https://github.com/openjdk/jdk/pull/7167#discussion_r81016. I'd rather not fail. - PR: https://git.openjdk.java.net/jdk/pull/7167
Re: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v7]
> Hi all, > > Please review the attached patch to address > > - That JarFile::getInputStream did not check for a null ZipEntry passed as a > parameter > - Have Zip/JarFile::getInputStream throw a ZipException in the event that an > unexpected exception occurs > > Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar > test runs > > Best > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: remove extra '}' - Changes: - all: https://git.openjdk.java.net/jdk/pull/7348/files - new: https://git.openjdk.java.net/jdk/pull/7348/files/818c2857..839d99f7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7348=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7348=05-06 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7348.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7348/head:pull/7348 PR: https://git.openjdk.java.net/jdk/pull/7348
Re: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v6]
> Hi all, > > Please review the attached patch to address > > - That JarFile::getInputStream did not check for a null ZipEntry passed as a > parameter > - Have Zip/JarFile::getInputStream throw a ZipException in the event that an > unexpected exception occurs > > Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar > test runs > > Best > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: remove trailing space - Changes: - all: https://git.openjdk.java.net/jdk/pull/7348/files - new: https://git.openjdk.java.net/jdk/pull/7348/files/490c986d..818c2857 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7348=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7348=04-05 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7348.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7348/head:pull/7348 PR: https://git.openjdk.java.net/jdk/pull/7348
Re: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v4]
On Fri, 18 Feb 2022 17:20:26 GMT, Alan Bateman wrote: > > If you feel there is still something lacking for documentation, I can > > certainly make another pass clarify/add it, but I tried to cover the steps > > (but I also understand what might be obvious to me might not be as obvious > > as I thought). > > Yes, I think clear instructions are important to have for tests like this. It > doesn't need much but what you know is scattered across a method and a > comment on a byte array, just not clear/easy. Ok, thank you for the feedback. I just pushed a change with additional comments on the jar creation which hopefully will address your input above. - PR: https://git.openjdk.java.net/jdk/pull/7348
Re: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v5]
> Hi all, > > Please review the attached patch to address > > - That JarFile::getInputStream did not check for a null ZipEntry passed as a > parameter > - Have Zip/JarFile::getInputStream throw a ZipException in the event that an > unexpected exception occurs > > Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar > test runs > > Best > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Add additional comments describing how the jars are created - Changes: - all: https://git.openjdk.java.net/jdk/pull/7348/files - new: https://git.openjdk.java.net/jdk/pull/7348/files/d5cf8db8..490c986d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7348=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7348=03-04 Stats: 29 lines in 1 file changed: 28 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7348.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7348/head:pull/7348 PR: https://git.openjdk.java.net/jdk/pull/7348
Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v5]
OtherName.java @93,97
PR:https://git.openjdk.java.net/jdk/pull/7167
if (derValue1.isContextSpecific((byte) 0) &&
derValue1.isConstructed()) {
nameValue = derValue1.data.toByteArray();
} else {
throw new IOException("value is not [0]");
}
That exception string isn't correct (the value is usually not just the
tag), nor very descriptive. How about instead:
throw new IOException ("value is not EXPLICTly tagged [0]");
Also, the derValue1.data should be parseable into a DerValue itself.
Should that be checked here as well and an error thrown if invalid?
I.e., add this after nameValue = ...
try {
new DerValue (nameValue);
} catch (IOException ex) {
throw new IOException ("Body of OtherName is not a valid BER or
DER value", ex);
}
Thanks - Mike
RFR: 8277488: Add expiry exception for Digicert (geotrustglobalca) expiring in May 2022
We are checking with CA if root cert can be removed. Meanwhile, updated test to add expiry exception. - Commit messages: - 8277488: Add expiry exception for Digicert (geotrustglobalca) expiring in May 2022 Changes: https://git.openjdk.java.net/jdk/pull/7537/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7537=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277488 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7537.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7537/head:pull/7537 PR: https://git.openjdk.java.net/jdk/pull/7537
Re: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v4]
On Fri, 18 Feb 2022 17:15:17 GMT, Lance Andersen wrote: > If you feel there is still something lacking for documentation, I can > certainly make another pass clarify/add it, but I tried to cover the steps > (but I also understand what might be obvious to me might not be as obvious as > I thought). Yes, I think clear instructions are important to have for tests like this. It doesn't need much but what you know is scattered across a method and a comment on a byte array, just not clear/easy. - PR: https://git.openjdk.java.net/jdk/pull/7348
Re: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v4]
On Fri, 18 Feb 2022 17:05:53 GMT, Alan Bateman wrote: > > > The updates changes to ZipFile/JarFile look okay. I don't have time to > > > study the test too closely right now but it will need to include > > > instructions on how to re-create the signed JAR that is stored in the > > > byte array. > > > > > > Those instructions are already in the comments for the constant > > `SIGNED_VALID_ENTRY_NAME` > > That's the keytool command to sign the JAR. What I meant is the complete > steps to create the JAR file, sign it, and then create the byte array. The `createByteArray` method which is at the bottom of the test class documents how the byte array can be made from a jar. The signed jar is created using the steps defined in `SIGNED_VALID_ENTRY_NAME` from the jar derived from `VALID_ENTRY_NAME` If you feel there is still something lacking for documentation, I can certainly make another pass clarify/add it, but I tried to cover the steps (but I also understand what might be obvious to me might not be as obvious as I thought). - PR: https://git.openjdk.java.net/jdk/pull/7348
Re: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v4]
On Fri, 18 Feb 2022 16:25:30 GMT, Lance Andersen wrote: > > The updates changes to ZipFile/JarFile look okay. I don't have time to > > study the test too closely right now but it will need to include > > instructions on how to re-create the signed JAR that is stored in the byte > > array. > > Those instructions are already in the comments for the constant > `SIGNED_VALID_ENTRY_NAME` That's the keytool command to sign the JAR. What I meant is the complete steps to create the JAR file, sign it, and then create the byte array. - PR: https://git.openjdk.java.net/jdk/pull/7348
Integrated: 8255266: Update Public Suffix List to 3c213aa
On Thu, 17 Feb 2022 23:28:35 GMT, Weijun Wang wrote: > Updating to a recent release of PSL. This pull request has now been integrated. Changeset: 7ce75afb Author:Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/7ce75afbbcca7635356c7377be7ddff15335e563 Stats: 1254 lines in 5 files changed: 887 ins; 215 del; 152 mod 8255266: Update Public Suffix List to 3c213aa Reviewed-by: xuelei - PR: https://git.openjdk.java.net/jdk/pull/7526
Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v5]
On Fri, 18 Feb 2022 16:28:25 GMT, Weijun Wang wrote: >> While I understand that, `new DerValue(byte[])` will be ignored and this >> will be also inconsistent with the remaining general names. Looking at >> sun.security.x509.GeneralName.GeneralName(DerValue, boolean) they all throw >> `IOException`. > > For other known names, you either return a parsed name or fail. For > `otherName`, you already have the raw data and this further parsed name is a > bonus. I just don't like a problem in getting the bonus to ruin the original > benefit. Also, I think the caller will have to check the length and the type > anyway so this will not be an extra burden. Besides, I always feel that > `otherName` could be freely extended and the quality of its encoding might > not be as guaranteed as the other ones. @seanjmullan, any comment here? > > Too many "other" used and hopefully no one get confused. This seems like a reasonable balance between preserving existing behavior and still providing the data for the application to inspect. To help debugging, you could log the exception. - PR: https://git.openjdk.java.net/jdk/pull/7167
Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v5]
On Fri, 18 Feb 2022 15:17:30 GMT, Michael Osipov wrote: >> I want to minimize behavior change and I'm leaving them to notice there's no >> string there and fail. > > While I understand that, `new DerValue(byte[])` will be ignored and this will > be also inconsistent with the remaining general names. Looking at > sun.security.x509.GeneralName.GeneralName(DerValue, boolean) they all throw > `IOException`. For other known names, you either return a parsed name or fail. For `otherName`, you already have the raw data and this further parsed name is a bonus. I just don't like a problem in getting the bonus to ruin the original benefit. Also, I think the caller will have to check the length and the type anyway so this will not be an extra burden. Besides, I always feel that `otherName` could be freely extended and the quality of its encoding might not be as guaranteed as the other ones. @seanjmullan, any comment here? Too many "other" used and hopefully no one get confused. - PR: https://git.openjdk.java.net/jdk/pull/7167
Re: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v4]
On Fri, 18 Feb 2022 12:09:53 GMT, Alan Bateman wrote: > The updates changes to ZipFile/JarFile look okay. I don't have time to study > the test too closely right now but it will need to include instructions on > how to re-create the signed JAR that is stored in the byte array. Those instructions are already in the comments for the constant `SIGNED_VALID_ENTRY_NAME` - PR: https://git.openjdk.java.net/jdk/pull/7348
Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v5]
On Fri, 18 Feb 2022 15:06:07 GMT, Weijun Wang wrote: >> So you leave it to the user to read the ASN.1 value and fail if the encoding >> is incorrect instead of throwing a `Ceritificate..Exception` although other >> GeneralNames do? > > I want to minimize behavior change and I'm leaving them to notice there's no > string there and fail. While I understand that, `new DerValue(byte[])` will be ignored and this will be inconsistent with the remaining general names. Looking at sun.security.x509.GeneralName.GeneralName(DerValue, boolean) they all throw `IOException`. - PR: https://git.openjdk.java.net/jdk/pull/7167
Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v5]
On Fri, 18 Feb 2022 06:56:04 GMT, Michael Osipov wrote: >> Yes. I don't want to let the method fail. Since `instanceof String` should >> be called anyway the caller can decide how to fail. > > So you leave it to the user to read the ASN.1 value and fail if the encoding > is incorrect instead of throwing a `Ceritificate..Exception` although other > GeneralNames do? I want to minimize behavior change and I'm leaving them to notice there's no string there and fail. - PR: https://git.openjdk.java.net/jdk/pull/7167
Re: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v4]
On Thu, 17 Feb 2022 19:00:47 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review the attached patch to address >> >> - That JarFile::getInputStream did not check for a null ZipEntry passed as a >> parameter >> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an >> unexpected exception occurs >> >> Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar >> test runs >> >> Best >> Lance > > Lance Andersen has updated the pull request incrementally with one additional > commit since the last revision: > > Return null when ZipEntry::getName is null The updates changes to ZipFile/JarFile look okay. I don't have time to study the test too closely right now but it will need to include instructions on how to re-create the signed JAR that is stored in the byte array. - PR: https://git.openjdk.java.net/jdk/pull/7348
Re: RFR: 8255266: 2021-11-27 public suffix list update v 3c213aa
On Thu, 17 Feb 2022 23:28:35 GMT, Weijun Wang wrote: > Updating to a recent release of PSL. Marked as reviewed by ahmadsha...@github.com (no known OpenJDK username). - PR: https://git.openjdk.java.net/jdk/pull/7526
