On Mon, 23 May 2022 19:31:02 GMT, Valerie Peng wrote:
> Need to update the 3 header files due to expiring business approval for 3rd
> party.
>
> The header files contain tabs which jcheck disallows, so I have to replace
> them with spaces.
>
> Thanks,
> Valerie
T
> Need to update the 3 header files due to expiring business approval for 3rd
> party.
>
> The header files contain tabs which jcheck disallows, so I have to replace
> them with spaces.
>
> Thanks,
> Valerie
Valerie Peng has updated the pull request incrementally wit
> Need to update the 3 header files due to expiring business approval for 3rd
> party.
>
> The header files contain tabs which jcheck disallows, so I have to replace
> them with spaces.
>
> Thanks,
> Valerie
Valerie Peng has updated the pull request incrementally wit
Need to update the 3 header files due to expiring business approval for 3rd
party.
The header files contain tabs which jcheck disallows, so I have to replace them
with spaces.
Thanks,
Valerie
-
Commit messages:
- Replaced tab with spaces in order to pass jcheck.
- 8286211:
On Tue, 26 Apr 2022 02:59:48 GMT, Valerie Peng wrote:
> This is to update the method javadoc of
> java.security.Signature.getParameters() with the missing `@throws
> UnsupportedOperationException`. In addition, the wording on the returned
> parameters are updated to match tho
ill be filed later.
>
> Thanks,
> Valerie
Valerie Peng has updated the pull request incrementally with one additional
commit since the last revision:
rewording the UOE for Signature.getParameters() and remove redundant
sentences from SignatureSpi class.
-
Changes:
- all: h
On Tue, 17 May 2022 23:11:06 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> more minor cleanups for consistencies.
>
> src/java.base/share/classes/java/secur
On Wed, 18 May 2022 22:27:18 GMT, Weijun Wang wrote:
>> Let ECDSA's `engineGetParameters()` always return null. At the same time,
>> remove the remembered `sigParams` field. One behavior change is that after
>> calling `setParameter()`, one can call `init()` again with a key using
>>
ill be filed later.
>
> Thanks,
> Valerie
Valerie Peng has updated the pull request incrementally with one additional
commit since the last revision:
more minor cleanups for consistencies.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8396/files
- new: https://gi
On Tue, 3 May 2022 19:30:40 GMT, Valerie Peng wrote:
> This change refactors the PBES2Core and PKCS12PBECipherCore classes in SunJCE
> provider as requested in the bug record. Functionality should remain the same
> with a clearer and simplified code/control flow with less line
On Wed, 6 Apr 2022 00:14:04 GMT, Valerie Peng wrote:
> Anyone can help review this javadoc update? The main change is the wording
> for the method javadoc of
> Cipher.getParameters()/CipherSpi.engineGetParameters(). The original wording
> is somewhat restrictive and request i
On Mon, 16 May 2022 13:28:13 GMT, Sean Mullan wrote:
>> With this modification of 2nd sentence. The whole paragraph becomes:
>>
>> * The returned parameters may be the same that were used to
>> initialize
>> * this signature, or may contain additional default or random parameter
>>
ill be filed later.
>
> Thanks,
> Valerie
Valerie Peng has updated the pull request incrementally with one additional
commit since the last revision:
review feedback
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8396/files
- new: https://git.openjdk.java.net/j
On Fri, 13 May 2022 20:29:11 GMT, Sean Mullan wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix newline.
>
> src/java.base/share/classes/java/security/Signature.java line 1012:
ill be filed later.
>
> Thanks,
> Valerie
Valerie Peng has updated the pull request incrementally with one additional
commit since the last revision:
fix newline.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8396/files
- new: https://git.openjdk.java.net/j
ill be filed later.
>
> Thanks,
> Valerie
Valerie Peng has updated the pull request incrementally with one additional
commit since the last revision:
change the last sentence for the "cannot return AlgorithmParameters"
case.
-
Changes:
- all: https://git.openjdk
On Fri, 13 May 2022 14:35:56 GMT, Sean Mullan wrote:
>> Hmm, would it fall under the "Otherwise, null is returned"? If not, perhaps
>> we can add back the part about returning AlgorithmParameters as below:
>>
>> **If the underlying signature implementation supports returning the
>> parameters
On Thu, 12 May 2022 15:03:40 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> trivial syntax fix.
>
> src/java.base/share/classes/com/sun/crypto/provider/PKCS12
intenance. I enhanced one existing
> regression test to test more scenarios. This test would pass before the
> proposed change and continues to pass with the proposed changes.
Valerie Peng has updated the pull request incrementally with one additional
commit since the last revision:
reset iv
On Thu, 12 May 2022 20:53:00 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> trivial syntax fix.
>
> src/java.base/share/classes/com/sun/crypto/provider/PBES
On Thu, 12 May 2022 19:27:20 GMT, Sean Mullan wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> trivial syntax fix.
>
> src/java.base/share/classes/com/sun/crypto/provider/PBES
On Thu, 12 May 2022 18:23:18 GMT, Sean Mullan wrote:
>> Fixed the nit. Thanks~
>> As for the part about returning the parameters as `{@code
>> AlgorithmParameters}`, it should be covered by current sentence, i.e. `and
>> can be generated by the signature`. Perhaps we don't have to spell out
intenance. I enhanced one existing
> regression test to test more scenarios. This test would pass before the
> proposed change and continues to pass with the proposed changes.
Valerie Peng has updated the pull request incrementally with one additional
commit since the last revision:
On Wed, 11 May 2022 23:45:00 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Changed to extend various CipherSpi implementations.
>
> src/java.base/share/c
intenance. I enhanced one existing
> regression test to test more scenarios. This test would pass before the
> proposed change and continues to pass with the proposed changes.
Valerie Peng has updated the pull request incrementally with one additional
commit since the last revision:
Upd
On Thu, 12 May 2022 00:21:34 GMT, Valerie Peng wrote:
>> This is to update the method javadoc of
>> java.security.Signature.getParameters() with the missing `@throws
>> UnsupportedOperationException`. In addition, the wording on the returned
>> parameters are updated
ill be filed later.
>
> Thanks,
> Valerie
Valerie Peng has updated the pull request incrementally with one additional
commit since the last revision:
Minor update.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8396/files
- new: https://git.openjdk.java.net/j
On Tue, 10 May 2022 20:38:31 GMT, Sean Mullan wrote:
>> Valerie Peng 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 five addi
s when null can be returned.
> The rest are minor things like add {@code } to class name and null, and
> remove redundant ".".
>
> Will file CSR after the review is close to being wrapped up.
> Thanks~
Valerie Peng has updated the pull request incrementally with one ad
On Tue, 10 May 2022 20:42:55 GMT, Sean Mullan wrote:
>> Valerie Peng 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 four addi
intenance. I enhanced one existing
> regression test to test more scenarios. This test would pass before the
> proposed change and continues to pass with the proposed changes.
Valerie Peng has updated the pull request incrementally with one additional
commit since the last revision:
Changed
On Wed, 11 May 2022 04:05:27 GMT, Weijun Wang wrote:
>> It's possible, more refactoring would be needed and not necessarily less
>> lines of code. With your suggested change, the caller has to explicitly
>> destroy the derived key after the cipher.engineInit() call. This would be
>> repeated
On Tue, 10 May 2022 02:27:13 GMT, Weijun Wang wrote:
>> Currently, the specified CipherSpi object is one of RC4, RC2, DESede. The
>> "else" part is for catching new PKCS12 PBE algorithms support which uses
>> other cipher algorithms.
>> CipherSpi.engineInit(...) is protected, so that's why we
On Mon, 9 May 2022 21:44:10 GMT, Weijun Wang wrote:
> `AlgorithmId.getName` is updated for PBES2 algorithm identifiers so it
> directly returns the standard algorithm defined by Java (Ex:
> `PBEWithHmacSHA256AndAES_256`), instead of a simple "PBES2".
>
> Please note I specifically update the
intenance. I enhanced one existing
> regression test to test more scenarios. This test would pass before the
> proposed change and continues to pass with the proposed changes.
Valerie Peng has updated the pull request incrementally with one additional
commit since the last revision:
Addres
On Tue, 10 May 2022 00:09:16 GMT, Weijun Wang wrote:
>> Oh, the comment about "may be 0" is meant toward the
>> pbeKey.getInterationCount() call... Hmm, I will make it clearer.
>
> I see. Another question, shall we reset `salt` and `iCount` at the beginning?
> If `params` is null and `key` is
On Mon, 9 May 2022 14:09:28 GMT, Weijun Wang wrote:
> It's a pity you have to implement all those `engineXyz` methods in all three
> `CipherSpi` implementations here. Is there something simpler?
I debated shifting all these "engineXyz" methods into the PKCS12PBECipherCore
class and store the
On Fri, 6 May 2022 22:24:57 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update copyright year for PBES2Core.java
>
> src/java.base/share/c
On Fri, 6 May 2022 22:22:47 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update copyright year for PBES2Core.java
>
> src/java.base/share/c
On Fri, 6 May 2022 22:26:31 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update copyright year for PBES2Core.java
>
> src/java.base/share/c
On Fri, 6 May 2022 22:20:32 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update copyright year for PBES2Core.java
>
> src/java.base/share/c
intenance. I enhanced one existing
> regression test to test more scenarios. This test would pass before the
> proposed change and continues to pass with the proposed changes.
Valerie Peng has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excl
On Mon, 9 May 2022 14:00:58 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update copyright year for PBES2Core.java
>
> src/java.base/share/classes/com/sun/crypto/pr
ill be filed later.
>
> Thanks,
> Valerie
Valerie Peng 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 four additional commits since
the last revisio
s when null can be returned.
> The rest are minor things like add {@code } to class name and null, and
> remove redundant ".".
>
> Will file CSR after the review is close to being wrapped up.
> Thanks~
Valerie Peng has updated the pull request with a new target base due
ill be filed later.
>
> Thanks,
> Valerie
Valerie Peng has updated the pull request incrementally with one additional
commit since the last revision:
Sync'ed w/ the wording in the other Cipher.getParameters() PR.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pul
On Wed, 4 May 2022 04:16:42 GMT, Xue-Lei Andrew Fan wrote:
>> How about the case when no parameters are given? Say A is the user-supplied
>> values, B is the provider specific default or random values, your suggestion
>> has A, A+B, and null. Isn't the sentence about B needed (no A and
On Thu, 5 May 2022 22:03:16 GMT, Valerie Peng wrote:
>> I think this sentence covers case B, "... or may contain additional default
>> or random parameter
>> values used by the underlying signature implementation."
>
> Sean's comment on the other PR rega
intenance. I enhanced one existing
> regression test to test more scenarios. This test would pass before the
> proposed change and continues to pass with the proposed changes.
Valerie Peng has updated the pull request incrementally with one additional
commit since the last revision:
upd
On Tue, 3 May 2022 00:17:11 GMT, Weijun Wang wrote:
>> An example is RSASSA-PSS, i.e. it requires the caller to explicitly state
>> which message digest to use, etc.
>
> You listed 2 cases when null is returned: 1) not supplied. 2) cannot
> generate. My understanding is that the RSASSA-PSS
On Tue, 3 May 2022 17:51:43 GMT, Weijun Wang wrote:
> Since `keytool -importpass` always uses `KeyFactory.getInstance("PBE")` to
> generate the secret key, and "PBE" is an alias of "PBEwithMD5andDES" inside
> the SunJCE security provider, its `getAlgorithm` is always `PBEwithMD5andDES`.
>
>
This change refactors the PBES2Core and PKCS12PBECipherCore classes in SunJCE
provider as requested in the bug record. Functionality should remain the same
with a clearer and simplified code/control flow with less lines of code. This
should improve readability and maintenance. I enhanced one
s when null can be returned.
> The rest are minor things like add {@code } to class name and null, and
> remove redundant ".".
>
> Will file CSR after the review is close to being wrapped up.
> Thanks~
Valerie Peng has updated the pull request incrementally with one ad
On Mon, 2 May 2022 17:41:52 GMT, Weijun Wang wrote:
> PKCS12 stores the object identifier of a SecretKey along with it, and when
> retrieved, translate the object identifier to an algorithm name.
> Unfortunately, inside `KnownOIDs.java`, "DES" is [only registered
>
On Fri, 29 Apr 2022 04:27:36 GMT, Xue-Lei Andrew Fan wrote:
>> What kind of additional sentence do you have in mind?
>
>> What kind of additional sentence do you have in mind?
>
> It may be fine to put it into the state for 'null" returned value. For
> example:
>
>
> The returned parameters
On Thu, 28 Apr 2022 23:28:39 GMT, Weijun Wang wrote:
>> The impl does not need to generate parameter values, but rather cannot
>> convert the supplied parameter values into AlgorithmParameter objects. By
>> parameter values, I mean the components of the parameters.
>
> Then what does "cannot
On Fri, 29 Apr 2022 15:23:47 GMT, Sean Mullan wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update for getParameters()
>
> src/java.base/share/classes/javax/crypto/Cip
On Fri, 29 Apr 2022 15:18:34 GMT, Sean Mullan wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update for getParameters()
>
> src/java.base/share/classes/javax/crypto/Cip
On Thu, 28 Apr 2022 19:23:18 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update for getParameters()
>
> src/java.base/share/classes/javax/crypto/Ciph
On Thu, 28 Apr 2022 19:17:08 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update for getParameters()
>
> src/java.base/share/classes/javax/crypto/Cip
On Thu, 28 Apr 2022 23:14:56 GMT, Weijun Wang wrote:
>> I assume you were suggesting this? `"The returned parameters may be the same
>> that were used to initialize this signature, or may contain additional
>> default or random parameter values used by the underlying signature
>>
On Wed, 27 Apr 2022 23:02:28 GMT, Weijun Wang wrote:
>> Right, the user-supplied values takes precedence and provider-specific
>> default/random values should just be supplemental.
>>
>> As for EdDSA, looks like the prehash and context are only in RFC 8032 and
>> NOT RFC 8410. caller has to
On Thu, 28 Apr 2022 04:56:47 GMT, Xue-Lei Andrew Fan wrote:
>>> Can you clarify what is the A and B that you are referring to?
>>
>> The sentence is, “If the required parameters were not supplied and the
>> underlying signature implementation can generate the parameter values, it
>> will be
s when null can be returned.
> The rest are minor things like add {@code } to class name and null, and
> remove redundant ".".
>
> Will file CSR after the review is close to being wrapped up.
> Thanks~
Valerie Peng has updated the pull request incrementally with one ad
On Wed, 27 Apr 2022 23:30:22 GMT, Valerie Peng wrote:
>> Can you clarify what is the A and B that you are referring to? The way I
>> read it, it has more than 2 conditions... So, best to clarify the conditions
>> first.
>> I see your point with the wording suggesti
On Wed, 27 Apr 2022 23:19:56 GMT, Valerie Peng wrote:
>>> What does it refer to with 'it'? Is 'it' refer to the implementation
>>> generated parameter values?
>>
>> 'It' refers to the parameters containing all of the parameter values
>> including the suppl
On Wed, 27 Apr 2022 23:15:41 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/java/security/Signature.java line 1014:
>>
>>> 1012: * {@code AlgorithmParameters}. If the required
>>> 1013: * parameters were not supplied and the underlying signatur
On Wed, 27 Apr 2022 05:25:42 GMT, Xue-Lei Andrew Fan wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Undo un-intentional changes.
>
> src/java.base/share/classes/java/security/Signat
On Wed, 27 Apr 2022 15:10:42 GMT, Weijun Wang wrote:
>> I searched about "and/or" and it is said that "or" covers "and". So,
>> "and/or" should just be "or".
>>
>> I am on the fence for requiring provider to generate default parameters
>> (using provider-specific or random values). Could
On Tue, 26 Apr 2022 19:26:41 GMT, Sean Mullan wrote:
>> I have filed the PR for the Signature at:
>> https://github.com/openjdk/jdk/pull/8396
>> Best to get it done along with this one.
>
>> As for the 2nd sentence, it boils down whether we requires provider to
>> generate default parameters
On Tue, 26 Apr 2022 14:59:35 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Undo un-intentional changes.
>
> src/java.base/share/classes/java/security/Signat
On Tue, 26 Apr 2022 22:55:29 GMT, Bradford Wetmore wrote:
> Two new constant fields `MGF1ParameterSpec.SHA512_224` and
> `MGF1ParameterSpec.SHA512_256` didn't have `@since 11` tag added as part of
> [JDK-8146293](https://bugs.openjdk.java.net/browse/JDK-8146293).
>
> This bug addresses this
On Tue, 26 Apr 2022 22:55:29 GMT, Bradford Wetmore wrote:
> Two new constant fields `MGF1ParameterSpec.SHA512_224` and
> `MGF1ParameterSpec.SHA512_256` didn't have `@since 11` tag added as part of
> [JDK-8146293](https://bugs.openjdk.java.net/browse/JDK-8146293).
>
> This bug addresses this
On Mon, 25 Apr 2022 18:14:07 GMT, Sean Mullan wrote:
>> As for the 2nd sentence, it boils down whether we requires provider to
>> generate default parameters and return it when parameter is required.
>> Existing javadoc states that null is returned when parameter is not
>> required. Given
On Tue, 26 Apr 2022 16:02:41 GMT, Weijun Wang wrote:
>> Compare encoded instead of decoded digest in RSA signature verification.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> only check digest value
Marked as reviewed by
ill be filed later.
>
> Thanks,
> Valerie
Valerie Peng has updated the pull request incrementally with one additional
commit since the last revision:
Undo un-intentional changes.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8396/files
- new: https://git.openjdk.j
On Tue, 26 Apr 2022 14:51:31 GMT, Weijun Wang wrote:
>> This is to update the method javadoc of
>> java.security.Signature.getParameters() with the missing `@throws
>> UnsupportedOperationException`. In addition, the wording on the returned
>> parameters are updated to match those in Cipher
On Sun, 24 Apr 2022 14:34:46 GMT, Weijun Wang wrote:
> Regardless whether we ended up with decode/encode, we should make sure
> RSASSA-PSS signature impl is also covered and consistent.
Never mind, PSS has its own way of verification and its impl is based on RFC
8017.
-
PR:
This is to update the method javadoc of java.security.Signature.getParameters()
with the missing `@throws UnsupportedOperationException`. In addition, the
wording on the returned parameters are updated to match those in Cipher and
CipherSpi classes.
CSR will be filed later.
Thanks,
Valerie
On Fri, 22 Apr 2022 17:10:58 GMT, Weijun Wang wrote:
> Compare encoded instead of decoded digest in RSA signature verification.
Regardless whether we ended up with decode/encode, we should make sure
RSASSA-PSS signature impl is also covered and consistent.
-
PR:
On Fri, 22 Apr 2022 06:26:01 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have the simple update reviewed.
>
> In the NativeGSSContext constructor for imported context, the assert is use
> on the object field, instead of the input parameters. As in a constructor,
> `'this'` object does not
On Thu, 21 Apr 2022 23:15:10 GMT, Valerie Peng wrote:
>>> For (1), how about something like below:
>>>
>>> > ```
>>> > * The returned parameters may be the same that were used to initialize
>>> > * this cipher, or may contain addit
On Wed, 20 Apr 2022 16:40:34 GMT, Sean Mullan wrote:
>>> Hmm, I tried the suggested approach in (1), the result looks very lengthy.
>>> Actually, the Cipher.init(..) methods already has a few paragraphs
>>> describing the behavior for parameter generation, perhaps we should not
>>> repeat
On Tue, 12 Apr 2022 01:27:35 GMT, Valerie Peng wrote:
> This trivial change is to deprecate the DEFAULT static field of
> OAEPParameterSpec class. Wordings are mostly the same as the previous
> PSSParameterSpec deprecation change. Rest are just minor code re-factoring.
>
On Tue, 19 Apr 2022 13:48:26 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have the simple update reviewed?
>>
>> In the jdk.crypto.cryptoki module implementation, some of the debug
>> information could be calculated even if the debug is not enabled, which is
>> not resource friendly.
>>
ed.
>
> Thanks,
> Valerie
Valerie Peng has updated the pull request incrementally with one additional
commit since the last revision:
Remove "the" and change to "@throws".
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8191/files
- new: http
On Tue, 19 Apr 2022 19:54:24 GMT, Sean Mullan wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed the private no-arg default constructor and minor javadoc update.
>
> src/java.b
On Tue, 19 Apr 2022 19:52:34 GMT, Sean Mullan wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed the private no-arg default constructor and minor javadoc update.
>
> src/java.b
On Tue, 19 Apr 2022 14:00:06 GMT, Xue-Lei Andrew Fan wrote:
>> This is an effort to fix a problem introduced in the fix for
>> [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which
>> replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However,
>> there is a
On Tue, 19 Apr 2022 02:20:10 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/javax/crypto/Cipher.java line 1054:
>>
>>> 1052: * this cipher, or may contain additional default or random
>>> parameter
>>> 1053: * values used
On Fri, 15 Apr 2022 17:30:38 GMT, Sean Mullan wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update w/ review feedbacks
>
> src/java.base/share/classes/javax/crypto/Cip
On Sat, 16 Apr 2022 05:35:20 GMT, Xue-Lei Andrew Fan wrote:
>> This is an effort to fix a problem introduced in the fix for
>> [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which
>> replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However,
>> there is a
ed.
>
> Thanks,
> Valerie
Valerie Peng has updated the pull request incrementally with one additional
commit since the last revision:
Removed the private no-arg default constructor and minor javadoc update.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8
On Sun, 17 Apr 2022 14:45:49 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have the simple update reviewed?
>
> In the jdk.crypto.cryptoki module implementation, some of the debug
> information could be calculated even if the debug is not enabled, which is
> not resource friendly.
>
>
On Wed, 13 Apr 2022 19:27:00 GMT, Valerie Peng wrote:
>> This trivial change is to deprecate the DEFAULT static field of
>> OAEPParameterSpec class. Wordings are mostly the same as the previous
>> PSSParameterSpec deprecation change. Rest are just minor code re-factori
On Fri, 15 Apr 2022 15:50:19 GMT, Xue-Lei Andrew Fan wrote:
>> This is an effort to fix a problem introduced in the fix for
>> [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which
>> replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However,
>> there is a
On Fri, 15 Apr 2022 15:50:19 GMT, Xue-Lei Andrew Fan wrote:
>> This is an effort to fix a problem introduced in the fix for
>> [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which
>> replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However,
>> there is a
On Wed, 13 Apr 2022 22:04:03 GMT, Valerie Peng wrote:
>> Anyone can help review this javadoc update? The main change is the wording
>> for the method javadoc of
>> Cipher.getParameters()/CipherSpi.engineGetParameters(). The original wording
>> is somewhat restrictive a
On Thu, 14 Apr 2022 18:06:10 GMT, Xue-Lei Andrew Fan wrote:
> This is an effort to fix a problem introduced in the fix for
> [JDK-8284368](https://bugs.openjdk.java.net/browse/JDK-8284368), which
> replaced the finalizers in jdk.crypto.cryptoki with Cleaners. However, there
> is a problem
s when null can be returned.
> The rest are minor things like add {@code } to class name and null, and
> remove redundant ".".
>
> Will file CSR after the review is close to being wrapped up.
> Thanks~
Valerie Peng has updated the pull request incrementally with one ad
1 - 100 of 1334 matches
Mail list logo
