On Fri, 2 Apr 2021 01:56:15 GMT, Weijun Wang wrote:
>> Only a few minor comments. Approved.
>
> Maybe we don't need to resolve it in this code change. If we look carefully
> at RFC 8410 Sections 10.1 and 10.2, it shows the X25519 certificate in 10.2
> is using the signer's S
On Fri, 2 Apr 2021 01:44:03 GMT, Weijun Wang wrote:
>> Hai-May Chao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update with review comments
>
> Only a few minor comments. Approved.
Maybe we don't n
On Thu, 1 Apr 2021 23:36:04 GMT, Hai-May Chao wrote:
>> Please review the changes that adds the -signer option to keytool
>> -genkeypair command. As key agreement algorithms do not have a signing
>> algorithm, the specified signer's private key will be used to sign and
>> generate a key
On Thu, 1 Apr 2021 20:37:47 GMT, Hai-May Chao wrote:
>> Please review the changes that adds the -signer option to keytool
>> -genkeypair command. As key agreement algorithms do not have a signing
>> algorithm, the specified signer's private key will be used to sign and
>> generate a key
On Thu, 1 Apr 2021 16:34:43 GMT, Hai-May Chao wrote:
>> Please review the changes that adds the -signer option to keytool
>> -genkeypair command. As key agreement algorithms do not have a signing
>> algorithm, the specified signer's private key will be used to sign and
>> generate a key
On Thu, 1 Apr 2021 16:25:49 GMT, Hai-May Chao wrote:
>> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1941:
>>
>>> 1939: signerFlag = true;
>>> 1940:
>>> 1941: if (keyStore.containsAlias(signerAlias) == false) {
>>
>> It's probably more precise
On Thu, 1 Apr 2021 16:34:43 GMT, Hai-May Chao wrote:
>> Please review the changes that adds the -signer option to keytool
>> -genkeypair command. As key agreement algorithms do not have a signing
>> algorithm, the specified signer's private key will be used to sign and
>> generate a key
On Thu, 1 Apr 2021 16:26:39 GMT, Hai-May Chao wrote:
>> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2013:
>>
>>> 2011: }
>>> 2012:
>>> 2013: X509Certificate[] chain = new X509Certificate[1];
>>
>> Since the chain might contain one, I'd suggest we just
On Thu, 1 Apr 2021 16:25:13 GMT, Hai-May Chao wrote:
>> src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java
>> line 114:
>>
>>> 112: }
>>> 113:
>>> 114: /**
>>
>> The original constructor can be modified to call
>> `this(keyType,sigAlg,providerName,null,null)`.
tands extra fields in `PSSParameterSpec` and is aware of the
> defaults in both directions.
> 3. Update `DOMSignedInfo` so that secure validation can restrict
> `DigestMethod` used inside `RSAPSSParameterSpec`
> 4. Tests
Weijun Wang has updated the pull request incrementally with one additional
On Tue, 30 Mar 2021 20:24:49 GMT, Weijun Wang wrote:
>> I wonder if the @implSpec is clear enough that this will be returned. I
>> might suggest adding a similar @implSpec in this method that basically
>> states what you said above.
>
> I'm not sure if it's appropriat
On Wed, 31 Mar 2021 06:30:01 GMT, Hai-May Chao wrote:
> Please review the changes that adds the -signer option to keytool -genkeypair
> command. As key agreement algorithms do not have a signing algorithm, the
> specified signer's private key will be used to sign and generate a key
>
On Tue, 30 Mar 2021 18:41:45 GMT, Sean Mullan wrote:
>> There are other fields in `RSASSAParams`, so if there is no DigestMethod, it
>> will be SHA-256 but the other fields (like SaltLength or TrailerField) will
>> still be read if they exist.
>>
>> If there is no `RSASSAParams` at all or if
On Tue, 30 Mar 2021 15:34:16 GMT, Sean Mullan wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update XMLUtils (not used by tests here)
>
> src/java.xml.crypto/share/clas
On Tue, 30 Mar 2021 15:31:22 GMT, Sean Mullan wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update XMLUtils (not used by tests here)
>
> src/java.xml.crypto/share/clas
On Tue, 30 Mar 2021 15:04:29 GMT, Sean Mullan wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update XMLUtils (not used by tests here)
>
> src/java.xml.crypto/share/clas
These permissions are needed so that the URIDereferencer is able to read data
from a file system or a network. As the test shows, you still have to grant the
same type of permission to your application.
-
Depends on: https://git.openjdk.java.net/jdk/pull/3181
Commit messages:
-
tands extra fields in `PSSParameterSpec` and is aware of the
> defaults in both directions.
> 3. Update `DOMSignedInfo` so that secure validation can restrict
> `DigestMethod` used inside `RSAPSSParameterSpec`
> 4. Tests
Weijun Wang has updated the pull request incrementally with one additional
On Wed, 24 Mar 2021 21:36:21 GMT, Weijun Wang wrote:
> This enhancement contains the following code changes:
>
> 1. Create a new public API `javax/xml/crypto/dsig/spec/RSAPSSParameterSpec`
> and remove the internal one.
> 2. Update marshaling and unmarshal
This enhancement contains the following code changes:
1. Create a new public API `javax/xml/crypto/dsig/spec/RSAPSSParameterSpec` and
remove the internal one.
2. Update marshaling and unmarshaling code inside `DOMRSAPSSSignatureMethod` so
it understands extra fields in `PSSParameterSpec` and is
On Mon, 22 Mar 2021 15:49:55 GMT, Weijun Wang wrote:
> We don't use `digest` anymore but still need to ignore the 0 argument.
This pull request has now been integrated.
Changeset: 0b2aa1b6
Author: Weijun Wang
URL: https://git.openjdk.java.net/jdk/commit/0b2aa1b6
Stats: 5 li
> We don't use `digest` anymore but still need to ignore the 0 argument.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
simplify
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/3124/files
- new: ht
On Mon, 22 Mar 2021 18:40:37 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> typo
>
> src/java.base/share/classes/java/security/SecureRandom.java line 739:
>
>
> We don't use `digest` anymore but still need to ignore the 0 argument.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
typo
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/3124/files
- new: ht
We don't use `digest` anymore but still need to ignore the 0 argument.
-
Commit messages:
- 8263978: Clarify why 0 argument is ignored in SecureRandom::setSeed
Changes: https://git.openjdk.java.net/jdk/pull/3124/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3124=00
On Mon, 22 Mar 2021 10:30:07 GMT, Sibabrata Sahoo wrote:
> The Test is updated to use positive integer as seed for SecureRandom.
Marked as reviewed by weijun (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/3114
names are renamed to be internal. There are also some
> bulk changes on company name, comment style, and white spaces.
>
> Next steps are patches applied by JDK. Some are old patches before the last
> import. Some are new.
>
> Several tests need to be updated because of internal method
On Thu, 18 Mar 2021 20:10:20 GMT, Sean Mullan wrote:
>> Weijun Wang 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 15 addi
On Fri, 12 Mar 2021 16:29:34 GMT, Sean Mullan wrote:
>> Weijun Wang 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 15 addi
On Fri, 12 Mar 2021 22:04:35 GMT, Ziyi Luo wrote:
>> My understanding is that the problem here is the 2 `isAssignableFrom` checks
>> are in wrong order. The parent class RSA_PRIV_KEYSPEC_CLS should be checked
>> first.
>>
>> BTW, please add a regression test to the fix. Thanks.
>
> Hi
On Fri, 12 Mar 2021 09:22:40 GMT, Aleksey Shipilev wrote:
> SonarCloud actually found this:
> Verify this is the index that was intended; it was already set before.
>
>
> public byte[][] toByteArray() {
> byte[][] result = new byte[nameStrings.length][];
> for (int i =
On Thu, 11 Mar 2021 19:51:19 GMT, Ziyi Luo wrote:
> This is a P2 regression introduced by JDK-8254717.
>
> In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the
> KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is
> described as follow:
>
> X-axis:
names are renamed to be internal. There are also some
> bulk changes on company name, comment style, and white spaces.
>
> Next steps are patches applied by JDK. Some are old patches before the last
> import. Some are new.
>
> Several tests need to be updated because of internal method
On Sun, 10 Jan 2021 05:17:23 GMT, Xue-Lei Andrew Fan wrote:
>> 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.
>
> Mark
names are renamed to be internal. There are also some
> bulk changes on company name, comment style, and white spaces.
>
> Next steps are patches applied by JDK. Some are old patches before the last
> import. Some are new.
>
> Several tests need to be updated because of internal method
names are renamed to be internal. There are also some
> bulk changes on company name, comment style, and white spaces.
>
> Next steps are patches applied by JDK. Some are old patches before the last
> import. Some are new.
>
> Several tests need to be updated because of internal method
names are renamed to be internal. There are also some
> bulk changes on company name, comment style, and white spaces.
>
> Next steps are patches applied by JDK. Some are old patches before the last
> import. Some are new.
>
> Several tests need to be updated because of internal method
On Fri, 13 Nov 2020 17:22:10 GMT, Weijun Wang wrote:
> This is a multi-commits PR that upgrades xmldsig to be equivalent to
> Santuario 2.2.0.
>
> The first step is an auto-import. The JDK implementation is removed first and
> Santuario code are imported. Some unrelated files
On Fri, 12 Feb 2021 15:24:07 GMT, Weijun Wang wrote:
> The code change fixes the ECDSA XML signature length issue. It should only
> happen when there is no P1363 ECDSA support, which is not true when SunEC is
> used.
>
> If a PrivateKey is not of ECPrivateKey type then the bug
On Thu, 25 Feb 2021 21:23:51 GMT, Sean Mullan wrote:
>> The code change fixes the ECDSA XML signature length issue. It should only
>> happen when there is no P1363 ECDSA support, which is not true when SunEC is
>> used.
>>
>> If a PrivateKey is not of ECPrivateKey type then the bug will still
When default_tkt_enctypes or default_tgs_enctypes, use the value of
permitted_enctypes if it exists.
Please also review the CSR at https://bugs.openjdk.java.net/browse/JDK-8262391
and release note at https://bugs.openjdk.java.net/browse/JDK-8262401.
-
Commit messages:
- 8262389:
On Wed, 24 Feb 2021 01:38:07 GMT, Weijun Wang wrote:
> Deprecate des3-hmac-sha1 (etype 16) and rc4-hmac (etype 23). User can add
> "allow_weak_crypto = true" in krb5.conf to re-enable them (plus the DES-based
> etypes deprecated long ago).
This pull request has now been int
> Deprecate des3-hmac-sha1 (etype 16) and rc4-hmac (etype 23). User can add
> "allow_weak_crypto = true" in krb5.conf to re-enable them (plus the DES-based
> etypes deprecated long ago).
Weijun Wang has updated the pull request incrementally with one additional
commit sinc
On Thu, 25 Feb 2021 13:40:59 GMT, Sean Mullan wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> test updates
>
> test/jdk/sun/security/krb5/auto/W83.java line 26:
>
>> 24: /*
On Wed, 24 Feb 2021 22:02:45 GMT, Sean Mullan wrote:
> > All test changes are about re-enabling disabled algorithms. Do we have a
> > test on ensuring disabled algorithms are indeed disabled? How about we set
> > "org.jcp.xml.dsig.secureValidation" to false everywhere in the existing
> >
> Deprecate des3-hmac-sha1 (etype 16) and rc4-hmac (etype 23). User can add
> "allow_weak_crypto = true" in krb5.conf to re-enable them (plus the DES-based
> etypes deprecated long ago).
Weijun Wang has updated the pull request incrementally with one additional
commit sinc
On Wed, 24 Feb 2021 21:43:52 GMT, Weijun Wang wrote:
>> Is there a test that checks that the weak algorithms are actually disabled?
>> I wasn't sure if I saw anything or maybe that is another test that you
>> didn't have to modify?
>
>> Is there a test that chec
On Wed, 24 Feb 2021 21:33:33 GMT, Sean Mullan wrote:
> Is there a test that checks that the weak algorithms are actually disabled? I
> wasn't sure if I saw anything or maybe that is another test that you didn't
> have to modify?
Actually there's no. I can add all weak etypes into
On Wed, 24 Feb 2021 21:28:41 GMT, Sean Mullan wrote:
>> Deprecate des3-hmac-sha1 (etype 16) and rc4-hmac (etype 23). User can add
>> "allow_weak_crypto = true" in krb5.conf to re-enable them (plus the
>> DES-based etypes deprecated long ago).
>
> test/jdk/sun/security/krb5/auto/NewSalt.java
Deprecate des3-hmac-sha1 (etype 16) and rc4-hmac (etype 23). User can add
"allow_weak_crypto = true" in krb5.conf to re-enable them (plus the DES-based
etypes deprecated long ago).
-
Commit messages:
- 8139348: Deprecate 3DES and RC4 in Kerberos
Changes:
On Mon, 22 Feb 2021 16:39:56 GMT, Fernando Guallini
wrote:
> Kerberos new replay cache format released in 1.18 (installed in OL8.3) is
> causing the tests failures:
> `https://web.mit.edu/kerberos/www/krb5-latest/doc/formats/rcache_file_format.html`
>
> New and old format are not compatible,
On Mon, 11 Jan 2021 17:58:03 GMT, Weijun Wang wrote:
>> I've force pushed a new series of commits from scratch. The difference:
>>
>> 1. The `s/Portions copyright/Copyright/` change is inside auto import.
>> 2. Some `s/Sun Microsystems/Oracle/` change in auto import
of internal method signature changes.
>
> The "Support RSA-PSS with parameters" commit introduces a new public API and
> would need a CSR.
>
> The last patch is one we just fixed several days ago.
Weijun Wang has refreshed the contents of this pull request, and previous
commits h
On Fri, 19 Feb 2021 21:44:15 GMT, Weijun Wang wrote:
> `InetAddress` is loading native library `net` and at the same time
> `SunNativeProvider` is loading `j2gss`, and in the `OnLoad` function inside
> `j2gss` it is calling `FindClass(env, "java/net/InetAddress")` and
dress` in `SunNativeProvider.` before loading
> the jgss library. i.e. use `Class.forName` to ensure `InetAddress` is
> initialized. Thanks to @dholmes-ora for providing this workaround.
>
> No new regression test, hard to reproduce.
Weijun Wang has updated the pull request increme
On Mon, 22 Feb 2021 18:33:17 GMT, Xue-Lei Andrew Fan wrote:
>> `InetAddress` is loading native library `net` and at the same time
>> `SunNativeProvider` is loading `j2gss`, and in the `OnLoad` function inside
>> `j2gss` it is calling `FindClass(env, "java/net/InetAddress")` and thus a
>>
On Mon, 22 Feb 2021 07:12:57 GMT, Valerie Peng wrote:
> Changes look good. Thanks~
Thanks a lot for your patience and precious feedback.
-
PR: https://git.openjdk.java.net/jdk/pull/2070
On Mon, 8 Feb 2021 20:46:41 GMT, Sean Mullan wrote:
> Please review this change to disable XML signatures that use SHA-1 based
> digest or signature algorithms. SHA-1 is weak and is not a recommended
> algorithm for digital signatures. This will improve out of the box security
> by
On Tue, 9 Feb 2021 21:04:00 GMT, Weijun Wang wrote:
>> Please review this change to disable XML signatures that use SHA-1 based
>> digest or signature algorithms. SHA-1 is weak and is not a recommended
>> algorithm for digital signatures. This will improve out o
On Thu, 18 Feb 2021 11:09:17 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> materials
>
> Other files look fine. Thanks~
Add one more clean.
> Clean up temporary byte array, char array, and keyspec around keys and
> passwords.
>
> No new regression test.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
simpler spec creation, and one more clean
--
`InetAddress` is loading native library `net` and at the same time
`SunNativeProvider` is loading `j2gss`, and in the `OnLoad` function inside
`j2gss` it is calling `FindClass(env, "java/net/InetAddress")` and thus a
deadlock.
We can access `InetAddress` in `SunNativeProvider.` before loading
On Thu, 18 Feb 2021 11:08:06 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> materials
>
> src/java.base/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerat
On Thu, 18 Feb 2021 05:03:58 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> materials
>
> src/java.base/share/classes/com/sun/crypto/provider/TlsKeyMaterialGener
On Fri, 12 Feb 2021 20:42:03 GMT, Hai-May Chao wrote:
>> This change is made for compliance with RFC 5280 section 4.2.1.1 for
>> Authority Key Identifier extension.
>
> Hai-May Chao has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Reduced
The code change fixes the ECDSA XML signature length issue. It should only
happened when there is no P1363 ECDSA support, which is not true when SunEC is
used.
Technically, if a PrivateKey is not of ECPrivateKey the bug will still show up,
and in this case we can actually look into the
On Wed, 10 Feb 2021 01:23:29 GMT, Weijun Wang wrote:
> Accept macOS 11.x as well.
>
> No new regression test. This can be approved by running the existing test
> test/sun/security/krb5/config/native/TestDynamicStore.java on Big Sur.
This pull request has now been integrated
On Thu, 11 Feb 2021 22:10:55 GMT, Hai-May Chao wrote:
>> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1482:
>>
>>> 1480: byte[] signerSubjectKeyIdExt =
>>> ((X509Certificate)signerCert).getExtensionValue(
>>> 1481:
On Thu, 11 Feb 2021 01:01:56 GMT, Hai-May Chao wrote:
>> This change is made for compliance with RFC 5280 section 4.2.1.1 for
>> Authority Key Identifier extension.
>
> Hai-May Chao has updated the pull request incrementally with one additional
> commit since the last revision:
>
> API used
On Wed, 10 Feb 2021 23:07:51 GMT, Hai-May Chao wrote:
>> test/jdk/sun/security/tools/keytool/CheckCertAKID.java line 69:
>>
>>> 67: .shouldContain(": 00 01 02 03 04 05 06 07 08 09
>>> 10 11 12 13 14 15")
>>> 68: .shouldContain("0010: 16 17 18 19")
>>> 69:
On Wed, 10 Feb 2021 21:52:01 GMT, Hai-May Chao wrote:
>> This change is made for compliance with RFC 5280 section 4.2.1.1 for
>> Authority Key Identifier extension.
>
> Hai-May Chao has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Test
On Wed, 10 Feb 2021 01:52:21 GMT, Jamil Nimeh wrote:
>> Print out "no limit" instead. This is the words RFC 5280 uses: "Where
>> pathLenConstraint does not appear, no limit is imposed".
>>
>> No regression test. Trivial.
>
> Looks fine to me.
> Sorry - not quite right, it's not quite that
On Wed, 10 Feb 2021 01:39:15 GMT, Weijun Wang wrote:
> Print out "no limit" instead. This is the words RFC 5280 uses: "Where
> pathLenConstraint does not appear, no limit is imposed".
>
> No regression test. Trivial.
This pull request has now been integra
Print out "no limit" instead. This is the words RFC 5280 uses: "Where
pathLenConstraint does not appear, no limit is imposed".
No regression test. Trivial.
-
Commit messages:
- 8261472: BasicConstraintsExtension::toString shows "PathLen:2147483647" if
there is no
Accept macOS 11.x as well.
No new regression test. This can be approved by running the existing test
test/sun/security/krb5/config/native/TestDynamicStore.java on Big Sur.
-
Commit messages:
- 8261481: Cannot read Kerberos settings in dynamic store on macOS Big Sur
Changes:
On Mon, 8 Feb 2021 20:46:41 GMT, Sean Mullan wrote:
> Please review this change to disable XML signatures that use SHA-1 based
> digest or signature algorithms. SHA-1 is weak and is not a recommended
> algorithm for digital signatures. This will improve out of the box security
> by
On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov
wrote:
>> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8080272: Refactor I/O stream
On Fri, 5 Feb 2021 16:34:29 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> drbg
>>
>> only in patch2:
>> unchanged:
>
> src/java.base/share
> Clean up temporary byte array, char array, and keyspec around keys and
> passwords.
>
> No new regression test.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
materials
-
Changes:
> Clean up temporary byte array, char array, and keyspec around keys and
> passwords.
>
> No new regression test.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
TLS key generators
-
Changes:
On Fri, 5 Feb 2021 21:54:19 GMT, Sean Mullan wrote:
> I think it would be useful to add a test that checks that `keytool` now
> creates the AKID from the issuing CA's SKID. `keytool -ext` should be able to
> create a certificate with your own AKID, but you need to specify the OID and
> a
On Thu, 4 Feb 2021 15:20:02 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> cleanups for key generations
>
> src/java.base/share/classes/com/sun/crypto/provider/AES
On Thu, 4 Feb 2021 16:13:11 GMT, Valerie Peng wrote:
> > New commit for key generations.
>
> How about the Tls*Generator classes in SunJCE provider? Looks like they need
> to be handled as well.
I'll take a look. I thought the secrets going in and out of them are ephemeral.
-
On Thu, 4 Feb 2021 15:25:14 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> cleanups for key generations
>
> src/java.base/share/classes/com/sun/crypto/provider/DES
On Thu, 4 Feb 2021 16:08:09 GMT, Fernando Guallini
wrote:
>> The following tests have been split based on lower/higher key sizes in order
>> to reduce individual execution time and run in parallel with jtreg
>> sun/security/provider/DSA/SupportedDSAParamGen.java
>>
On Wed, 3 Feb 2021 22:24:03 GMT, Fernando Guallini
wrote:
>> The following tests have been split based on lower/higher key sizes in order
>> to reduce individual execution time and run in parallel with jtreg
>> sun/security/provider/DSA/SupportedDSAParamGen.java
>>
On Wed, 3 Feb 2021 18:24:05 GMT, Fernando Guallini
wrote:
>> test/jdk/sun/security/rsa/SignatureTest.java line 137:
>>
>>> 135: return new Key[]{
>>> 136: kf.generatePublic(kf.getKeySpec(key,
>>> RSAPublicKeySpec.class)),
>>> 137:
On Fri, 18 Dec 2020 19:20:47 GMT, Weijun Wang wrote:
> This fix covers both
>
> - [[macOS]: Remove JNF dependency from
> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
> - [[macOS]: Remove JNF dependency from
> libosxkrb5/SCDynamicSt
On Wed, 3 Feb 2021 13:29:54 GMT, Fernando Guallini
wrote:
> The following tests have been split based on lower/higher key sizes in order
> to reduce individual execution time and run in parallel with jtreg
> sun/security/provider/DSA/SupportedDSAParamGen.java
>
> This fix covers both
>
> - [[macOS]: Remove JNF dependency from
> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
> - [[macOS]: Remove JNF dependency from
> libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860
On Wed, 3 Feb 2021 11:27:49 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - file attr error
>> - objc use .m
>
> src/java.security.jgss/share/classes/sun/sec
On Mon, 1 Feb 2021 22:51:06 GMT, Daniel D. Daugherty wrote:
> @wangweij - just a heads up that I'm ProblemListing the two tests you said to
> "ignore".
No problem! Good idea!! Well done!!!
-
PR: https://git.openjdk.java.net/jdk/pull/2342
> This fix covers both
>
> - [[macOS]: Remove JNF dependency from
> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
> - [[macOS]: Remove JNF dependency from
> libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860
On Mon, 1 Feb 2021 11:41:02 GMT, Magnus Ihse Bursie wrote:
>> Weijun Wang 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 cont
> This fix covers both
>
> - [[macOS]: Remove JNF dependency from
> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
> - [[macOS]: Remove JNF dependency from
> libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860
On Sat, 30 Jan 2021 00:06:51 GMT, Phil Race wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> phil comment
>
> Marked as reviewed by prr (Reviewer).
Added a test. Unfortunately it has t
> This fix covers both
>
> - [[macOS]: Remove JNF dependency from
> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
> - [[macOS]: Remove JNF dependency from
> libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860
> This fix covers both
>
> - [[macOS]: Remove JNF dependency from
> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
> - [[macOS]: Remove JNF dependency from
> libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860
> This fix covers both
>
> - [[macOS]: Remove JNF dependency from
> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
> - [[macOS]: Remove JNF dependency from
> libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860
On Fri, 29 Jan 2021 22:05:21 GMT, Phil Race wrote:
>> So I should remember how env was retrieved and only detach when it's from
>> `AttachCurrentThreadAsDaemon`? In fact, in my test the plain `GetEnv` has
>> never succeeded and it was always attached.
>
> Yes that is the idea. BTW which thread
701 - 800 of 2902 matches
Mail list logo
