Hi,
May I have this simple example update in the KeyStore specification?
Password protection should be destroyed in the example code in KeyStore
specification. Otherwise, applications may just copy and past the code, and
forget to clean up password protection.
It's a trivial update, and may
On Tue, 10 May 2022 01:22:21 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java
>> line 314:
>>
>>> 312: } else if (cipher instanceof DESedeCipher
>>> tripleDes) {
>>> 313:
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
>
>
On Mon, 9 May 2022 18:28: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 is to broaden
On Mon, 9 May 2022 18:45:05 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 those in Cipher
On Mon, 9 May 2022 23:23:05 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java line 229:
>>
>>> 227: if (key instanceof javax.crypto.interfaces.PBEKey
>>> pbeKey) {
>>> 228: salt = check(pbeKey.getSalt()); // may
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
>
>
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
>
>
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
>
>
> 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
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/provider/PBES2Core.java line
`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 javadoc for this method to clarify that
this name is meant to
On Sat, 7 May 2022 01:04:03 GMT, Jonathan Gibbons wrote:
> Please review a fix to remove incorrect use of the `@serial` tag from the doc
> comments for methods such as `readObject` and `readResolve`. The tag has no
> effect in this position other than to trigger warnings from the standard
>
On Mon, 9 May 2022 20:19:45 GMT, Jonathan Gibbons wrote:
>> Please review a fix to remove incorrect use of the `@serial` tag from the
>> doc comments for methods such as `readObject` and `readResolve`. The tag has
>> no effect in this position other than to trigger warnings from the standard
On Mon, 9 May 2022 19:38:36 GMT, Daniel Jeliński wrote:
> When a TLS server resumes a session from a stateless session ticket, it
> populates the `SSLSessionImpl`'s `localCerts` and `peerCerts` fields with
> certificates deserialized from the session ticket. These certificates are
> often the
When a TLS server resumes a session from a stateless session ticket, it
populates the `SSLSessionImpl`'s `localCerts` and `peerCerts` fields with
certificates deserialized from the session ticket. These certificates are often
the same across a large number of tickets.
This patch implements a
> Please review a fix to remove incorrect use of the `@serial` tag from the doc
> comments for methods such as `readObject` and `readResolve`. The tag has no
> effect in this position other than to trigger warnings from the standard
> doclet when running javadoc.
>
> There is no change to the
On Mon, 9 May 2022 18:14:35 GMT, Jonathan Gibbons wrote:
>> Please review a fix to remove incorrect use of the `@serial` tag from the
>> doc comments for methods such as `readObject` and `readResolve`. The tag has
>> no effect in this position other than to trigger warnings from the standard
> 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.
>
>
> 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 is to broaden this to accommodate more
> scenarios such as when null can
> Please review a fix to remove incorrect use of the `@serial` tag from the doc
> comments for methods such as `readObject` and `readResolve`. The tag has no
> effect in this position other than to trigger warnings from the standard
> doclet when running javadoc.
>
> There is no change to the
On Fri, 29 Apr 2022 22:30:04 GMT, Weijun Wang wrote:
> All `IntegerPolynimial`s are singletons now. Also, hand-coded implementations
> for Ed25519 and Ed448 are removed. They were not used since `FieldGen` starts
> generating classes for them.
>
> No new regression test. This is a clean-up.
On Fri, 29 Apr 2022 22:57:20 GMT, Weijun Wang wrote:
>> All `IntegerPolynimial`s are singletons now. Also, hand-coded
>> implementations for Ed25519 and Ed448 are removed. They were not used since
>> `FieldGen` starts generating classes for them.
>>
>> No new regression test. This is a
On Fri, 29 Apr 2022 22:57:20 GMT, Weijun Wang wrote:
>> All `IntegerPolynimial`s are singletons now. Also, hand-coded
>> implementations for Ed25519 and Ed448 are removed. They were not used since
>> `FieldGen` starts generating classes for them.
>>
>> No new regression test. This is a
On Sun, 24 Apr 2022 05:13:36 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> Could I have the simple update reviewed?
>
> In the PKCS12 key store implementation, the PBEKeySpec.clearPassword() should
> be called in a finally try block. Otherwise, the password cleanup could be
> interrupted by
On Thu, 31 Mar 2022 20:15:35 GMT, Xue-Lei Andrew Fan wrote:
> Please review the update to remove finalizer method in the SunJSSE provider
> implementation. It is one of the efforts to clean up the use of finalizer
> method in JDK.
This pull request has now been integrated.
Changeset:
On Thu, 5 May 2022 19:38:06 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 lines of
>> code.
On Fri, 29 Apr 2022 22:57:20 GMT, Weijun Wang wrote:
>> All `IntegerPolynimial`s are singletons now. Also, hand-coded
>> implementations for Ed25519 and Ed448 are removed. They were not used since
>> `FieldGen` starts generating classes for them.
>>
>> No new regression test. This is a
On Sat, 7 May 2022 01:04:03 GMT, Jonathan Gibbons wrote:
> Please review a fix to remove incorrect use of the `@serial` tag from the doc
> comments for methods such as `readObject` and `readResolve`. The tag has no
> effect in this position other than to trigger warnings from the standard
>
30 matches
Mail list logo
