On Sat, 11 Jun 2022 03:30:45 GMT, Kevin Driver wrote:
>> This PR resolves: https://bugs.openjdk.org/browse/JDK-8267860
>
> Kevin Driver 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
On Fri, 10 Jun 2022 12:16:17 GMT, Matthias Baesken wrote:
> When trying to construct an LdapURL object with a bad input string (in this
> example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run
> into the
On Fri, 10 Jun 2022 15:09:58 GMT, Rajan Halade wrote:
>> Updated with new test artifacts from CA.
>
> Rajan Halade has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Adjust hard wrap to 90 chars
Marked as reviewed by mullan (Reviewer).
On Thu, 9 Jun 2022 22:54:20 GMT, Hai-May Chao wrote:
>> src/java.base/share/classes/javax/crypto/CryptoPolicyParser.java line 202:
>>
>>> 200: if (!processedPermissions.isEmpty()) {
>>> 201: throw new ParsingException(st.lineno(), "Inconsistent
>>> policy");
>>>
On Tue, 7 Jun 2022 20:52:33 GMT, Hai-May Chao wrote:
>> Please review a small fix in CryptoPolicyParser class that it should not
>> pass “processedPermissions” parameter by value.
>> Ran MACH5 tier1 and tier2 without failures.
>
> Hai-May Chao has updated the pull request incrementally with two
On Thu, 9 Jun 2022 17:31:29 GMT, Rajan Halade wrote:
> Updated test artifacts. Test will continue to fail intermittently with what
> appears to be issue in CA infra. JDK-8277855 will track it.
Marked as reviewed by mullan (Reviewer).
On Thu, 9 Jun 2022 18:59:36 GMT, Rajan Halade wrote:
> Updated test certificates to new from CA. I did a loop run of this test and
> don't see the intermittent failure anymore.
Marked as reviewed by mullan (Reviewer).
On Wed, 8 Jun 2022 10:30:45 GMT, Sibabrata Sahoo wrote:
>> A Test updated to cover the getCodeSigners.
>
> Sibabrata Sahoo has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8209935: Test to cover CodeSource.getCodeSigners()
Marked as
On Tue, 7 Jun 2022 20:52:33 GMT, Hai-May Chao wrote:
>> Please review a small fix in CryptoPolicyParser class that it should not
>> pass “processedPermissions” parameter by value.
>> Ran MACH5 tier1 and tier2 without failures.
>
> Hai-May Chao has updated the pull request incrementally with two
On Thu, 2 Jun 2022 01:53:25 GMT, Hai-May Chao wrote:
> Please review a small fix in CryptoPolicyParser class that it should not pass
> “processedPermissions” parameter by value.
> Ran MACH5 tier1 and tier2 without failures.
The fix looks fine. Could you add a test for this in the
On Tue, 24 May 2022 16:29:02 GMT, Sean Mullan wrote:
> Please review this fix to the XML Signature implementation to check for null
> or missing DSA parameters and throw a MarshalException before trying to
> create a DSA public key from its XML encoding. This will allow the code t
ing provider to detect illegal or
> missing parameters.
Sean Mullan has updated the pull request incrementally with one additional
commit since the last revision:
Clarify why we don't support missing DSA params.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8870/files
Please review this fix to the XML Signature implementation to check for null or
missing DSA parameters and throw a MarshalException before trying to create a
DSA public key from its XML encoding. This will allow the code to fail earlier
and not depend on the underlying provider to detect
On Mon, 23 May 2022 20:14:37 GMT, Rajan Halade wrote:
> Incorporated patch from my @seanjmullan and removed expired root chains.
LGTM although someone else should probably have a look over this since I
contributed the fix.
test/jdk/sun/security/ssl/X509TrustManagerImpl/Symantec/Distrust.java
On Tue, 17 May 2022 19:56:22 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
> different
On Mon, 16 May 2022 12:59:09 GMT, Sean Mullan wrote:
>> Please review the small change to add RC2 and ARCFOUR to
>> jdk.security.legacyAlgorithms. So it enables keytool -genseckey, -list, and
>> -importkeystore commands to warn users when RC2 or ARCFOUR algorithm is used
On Sat, 14 May 2022 01:51:34 GMT, Hai-May Chao wrote:
> Please review the small change to add RC2 and ARCFOUR to
> jdk.security.legacyAlgorithms. So it enables keytool -genseckey, -list, and
> -importkeystore commands to warn users when RC2 or ARCFOUR algorithm is used.
Marked as reviewed by
On Fri, 13 May 2022 20:58:16 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/java/security/Signature.java line 1012:
>>
>>> 1010: * values used by the underlying signature scheme. If the required
>>> 1011: * parameters were not supplied and can be generated by the
>>>
On Sat, 14 May 2022 01:51:34 GMT, Hai-May Chao wrote:
> Please review the small change to add RC2 and ARCFOUR to
> jdk.security.legacyAlgorithms. So it enables keytool -genseckey, -list, and
> -importkeystore commands to warn users when RC2 or ARCFOUR algorithm is used.
On Fri, 13 May 2022 19:35:35 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 Thu, 12 May 2022 19:45:37 GMT, Valerie Peng wrote:
>> That sentence is specifically if the caller did not specify parameters
>> though. The previous wording is if the caller did specify parameters (as say
>> an `AlgorithmParameterSpec`) and the implementation cannot return them as
>>
On Thu, 12 May 2022 03:28:15 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
>>
On Wed, 11 May 2022 22:12:48 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/java/security/SignatureSpi.java line 399:
>>
>>> 397: * values used by the underlying signature scheme. If the required
>>> 398: * parameters were not supplied and can be generated by the
>>>
On Thu, 12 May 2022 13:48:46 GMT, Weijun Wang wrote:
> I've already modified the prompt a little before the CSR is finalized. How
> about
>
> ```
> Enter the distinguished name. Provider a single dot (.) to leave a
> sub-component empty or press ENTER to use the default value in braces.
> ```
On Wed, 11 May 2022 23:40:46 GMT, Weijun Wang wrote:
>> This code change allows one entering "." at a distinguished name prompt to
>> skip a sub-component when running `keytool -genkeyapir`. Several new
>> resource strings are added.
>>
>> There is no detailed description in `keytool.html`,
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 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 Tue, 3 May 2022 02:07:13 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.
>
> Xue-Lei Andrew Fan has updated the pull request
On Thu, 5 May 2022 06:02:14 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
On Wed, 4 May 2022 20:16:12 GMT, Hai-May Chao wrote:
>> Please review these changes to add DES/3DES/MD5 to
>> `jdk.security.legacyAlgorithms` security property, and to add the legacy
>> algorithm constraint checking to `keytool` commands that are associated with
>> secret key entries stored
On Wed, 4 May 2022 05:55:08 GMT, Hai-May Chao wrote:
>> Please review these changes to add DES/3DES/MD5 to
>> `jdk.security.legacyAlgorithms` security property, and to add the legacy
>> algorithm constraint checking to `keytool` commands that are associated with
>> secret key entries stored
Hi Andrey,
On 4/29/22 11:59 AM, Andrey Turbanov wrote:
Hello.
I found a suspicious code in CryptoPolicyParser method calls.
Method 'isConsistent' is called only from a method
'parsePermissionEntry'. It accepts the 'processedPermissions'
parameter from 'parsePermissionEntry'.
Method
On Thu, 21 Apr 2022 16:10:54 GMT, Alan Bateman wrote:
> > @AlanBateman So there is even more 3rd party code in there? :-( I tried to
> > ignore fixes for all files that I could identify as 3rd party. It's
> > actually a bit annoying that we have imported source code thrown around
> > like
On Tue, 3 May 2022 02:20:23 GMT, Xue-Lei Andrew Fan wrote:
>> Hi. Sorry, I should have brought this up earlier, but there is a jtreg test
>> library to help with ensuring the GC runs,
>> `test/lib/jdk/test/lib/util/ForceGC.java`. You might consider replacing the
>> test code that runs/checks
On Fri, 29 Apr 2022 19:42:27 GMT, Hai-May Chao wrote:
>> Please review these changes to add DES/3DES/MD5 to
>> `jdk.security.legacyAlgorithms` security property, and to add the legacy
>> algorithm constraint checking to `keytool` commands that are associated with
>> secret key entries stored
On Fri, 29 Apr 2022 21:49:32 GMT, Weijun Wang wrote:
>> We added a new system property back in
>> https://bugs.openjdk.java.net/browse/JDK-8153005 but it's better to describe
>> it in the `java.security` file as well.
>>
>> Please review the text. I especially added the last sentence so that
On Fri, 29 Apr 2022 20:40:46 GMT, Weijun Wang wrote:
>> It's a little long, but I can see why it is useful, so I think it's good. I
>> would avoid the word "new" as this won't be new in a few years time. Here is
>> an edit where I removed words which I thought were not essential:
>>
>>> Some
On Fri, 29 Apr 2022 13:28:11 GMT, Weijun Wang wrote:
>> I think the text above might still make some users concerned that they
>> should always set this property.
>> Maybe we can be less specific, and just say: "If you encounter compatibility
>> issues with software that doesn't support the
On Fri, 29 Apr 2022 17:06:28 GMT, Hai-May Chao wrote:
>> Please review these changes to add DES/3DES/MD5 to
>> `jdk.security.legacyAlgorithms` security property, and to add the legacy
>> algorithm constraint checking to `keytool` commands that are associated with
>> secret key entries stored
On Thu, 28 Apr 2022 19:11:23 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 Thu, 28 Apr 2022 23:20:18 GMT, Weijun Wang wrote:
>> But isn't it mostly an issue when creating new keystores and not reading
>> existing ones? I would want to avoid users thinking that they had to set
>> this in more cases than needed.
>
> How about this?
>
> To work with legacy PKCS #12
On Fri, 29 Apr 2022 09:03:58 GMT, Pavel Rappo wrote:
> * Syntactically improves a few cases from 8285676
> (https://github.com/openjdk/jdk/pull/8410)
> * Fixes a few misspelled `@param` tags for elements that, although are not
> included in the API Documentation, are visible in and processed
On Mon, 18 Apr 2022 13:35:25 GMT, Sean Mullan wrote:
> This change improves the specification for the case when a
> `PKIXRevocationChecker` is supplied as one of the `CertPathChecker`
> parameters. Specifically, it makes it more clear that a
> `PKIXRevocationChecker` overrides
On Thu, 28 Apr 2022 19:54:36 GMT, Weijun Wang wrote:
>> src/java.base/share/conf/security/java.security line 1174:
>>
>>> 1172: # If the property is not set or empty, a default value will be used.
>>> 1173: #
>>> 1174: # For compatibility, the system property "keystore.pkcs12.legacy" can
>>>
On Thu, 28 Apr 2022 14:35:54 GMT, Weijun Wang wrote:
> We added a new system property back in
> https://bugs.openjdk.java.net/browse/JDK-8153005 but it's better to describe
> it in the `java.security` file as well.
>
> Please review the text. I especially added the last sentence so that
On Wed, 27 Apr 2022 20:01:26 GMT, Sean Mullan wrote:
>> I don't see the ProviderException being mentioned?
>> Per the description under JDK-8209038, the requests are:
>> 1) describe the returned parameters following what's in Signature class,
>> i.e. if this obj
On Wed, 27 Apr 2022 19:35:04 GMT, Sean Mullan wrote:
>> Hai-May Chao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> SecretKeyConstraintsParameters subclass created and property description
>> updated
&
On Thu, 28 Apr 2022 06:46:35 GMT, Hai-May Chao wrote:
>> Please review these changes to add DES/3DES/MD5 to
>> `jdk.security.legacyAlgorithms` security property, and to add the legacy
>> algorithm constraint checking to `keytool` commands that are associated with
>> secret key entries stored
On Thu, 28 Apr 2022 07:01:25 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have this test update reviewed?
>
> The javax/security/auth/callback/PasswordCallback/CheckCleanerBound.java test
> case failed on one of the test setups. The test runs gc in a loop and
> expects the GC to have
On Wed, 27 Apr 2022 19:48:01 GMT, Valerie Peng 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.
On Tue, 19 Apr 2022 16:08:28 GMT, Hai-May Chao wrote:
> Please review these changes to add DES/3DES/MD5 to
> `jdk.security.legacyAlgorithms` security property, and to add the legacy
> algorithm constraint checking to `keytool` commands that are associated with
> secret key entries stored in
On Tue, 19 Apr 2022 16:08:28 GMT, Hai-May Chao wrote:
> Please review these changes to add DES/3DES/MD5 to
> `jdk.security.legacyAlgorithms` security property, and to add the legacy
> algorithm constraint checking to `keytool` commands that are associated with
> secret key entries stored in
On Wed, 27 Apr 2022 17:10:28 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
On Wed, 27 Apr 2022 16:22:38 GMT, Xue-Lei Andrew Fan wrote:
>> Please review this password cleanup enhancement in the PasswordCallback
>> implementation. This is one of the effort to clean up the buffered
>> passwords.
>>
>> The PasswordCallback.setPassword() clones the password, but is not
On Tue, 26 Apr 2022 16:04:14 GMT, Xue-Lei Andrew Fan wrote:
>> Please review this password cleanup enhancement in the PasswordCallback
>> implementation. This is one of the effort to clean up the buffered
>> passwords.
>>
>> The PasswordCallback.setPassword() clones the password, but is not
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
a PKIX service provider, and will be used to check revocation irrespective
> of the setting of the RevocationEnabled parameter.
>
> Will also file a CSR.
Sean Mullan has updated the pull request incrementally with one additional
commit since the last revision:
Change wording of "Howe
On Wed, 27 Apr 2022 06:44:37 GMT, Xue-Lei Andrew Fan wrote:
>> This change improves the specification for the case when a
>> `PKIXRevocationChecker` is supplied as one of the `CertPathChecker`
>> parameters. Specifically, it makes it more clear that a
>> `PKIXRevocationChecker` overrides the
On Mon, 18 Apr 2022 13:35:25 GMT, Sean Mullan wrote:
> This change improves the specification for the case when a
> `PKIXRevocationChecker` is supplied as one of the `CertPathChecker`
> parameters. Specifically, it makes it more clear that a
> `PKIXRevocationChecker` overrides
On Mon, 18 Apr 2022 13:26:30 GMT, Sibabrata Sahoo wrote:
>> A Test updated to cover the getCodeSigners.
>
> Sibabrata Sahoo has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Update Implies.java
Marked as reviewed by mullan (Reviewer).
On Tue, 26 Apr 2022 18:28:03 GMT, Valerie Peng wrote:
>>> I can do the Signature update through
>>> https://bugs.openjdk.java.net/browse/JDK-8253176 which I have targeted to
>>> fix in 19 also.
>>
>> Ok.
>
> I have filed the PR for the Signature at:
> https://github.com/openjdk/jdk/pull/8396
nformation, please let me know.
Thanks for that offer. I don't have an avenue for that information yet,
but I will see if we can start creating a list of significant SM-enabled
libraries and other projects that we can monitor over time.
--Sean
Thanks,
Scott
On Apr 26, 2022 at 11:09:22 AM, S
Hello Scott,
On 4/25/22 2:25 PM, Scott Stark wrote:
Hello,
I'm Scott Stark of Red Hat, and a member of the Jakarta EE platform dev
group (EEPD). I'm currently coordinating the Jakarta EE 10 release that
is targeting June of this year (2022). The removal of the
SecurityManager as described
On Tue, 26 Apr 2022 04:27:37 GMT, Xue-Lei Andrew Fan wrote:
>> test/jdk/javax/security/auth/callback/PasswordCleanup.java line 74:
>>
>>> 72: }
>>> 73:
>>> 74: private static void checkClearing() throws Exception {
>>
>> How is this test testing that the password is cleared?
>
> The
On Thu, 21 Apr 2022 06:55:22 GMT, Xue-Lei Andrew Fan wrote:
>> Please review this password cleanup enhancement in the PasswordCallback
>> implementation. This is one of the effort to clean up the buffered
>> passwords.
>>
>> The PasswordCallback.setPassword() clones the password, but is not
On Mon, 25 Apr 2022 05:48:04 GMT, Xue-Lei Andrew Fan wrote:
> > However, I think that we need to carefully check the interactions between
> > cleaners and methods that explicitly allow the contents to be cleared so
> > that there are not unexpected results.
>
> I think @RogerRiggs explained
On Thu, 21 Apr 2022 23:31:37 GMT, Valerie Peng 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
On Sun, 24 Apr 2022 15:54:15 GMT, Xue-Lei Andrew Fan wrote:
> I like this explanation more. I have no more comment about the patch. Please
> add a noreg label in JBS.
`noreg-sqe` seems appropriate.
-
PR: https://git.openjdk.java.net/jdk/pull/8372
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 Tue, 19 Apr 2022 15:21:49 GMT, Xue-Lei Andrew Fan wrote:
> > Won't there be a small performance hit (perhaps negligible) for code that
> > already calls clearPassword?
>
> The impact should be minimal. If clearPassword() has been called, the cleanup
> (Cleanerable.clean()) won't happen
On Tue, 19 Apr 2022 15:03:05 GMT, Xue-Lei Andrew Fan wrote:
> > I am not quite seeing the rationale for this change.
>
> There were a lot of effort to clean up the buffering password in JDK. In some
> circumstances, the PasswordCallback would be called for further using of the
> password.
On Wed, 20 Apr 2022 16:10:17 GMT, Sean Mullan 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 additional default or
On Tue, 19 Apr 2022 02:44:01 GMT, Valerie Peng 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 4/15/22 10:46 PM, Peter Firmstone wrote:
To securely instrument access controls onto public Java API, we need to
have the ability to disable finalizers, to prevent finalizer attacks
from circumventing access controls.
Since finalizers are planned for removal, as soon as finalizers are
On Mon, 18 Apr 2022 23:36:56 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.
>>
>> The CSR will
On Tue, 19 Apr 2022 16:50:12 GMT, Magnus Ihse Bursie wrote:
>> I ran `codespell` on the `src/java.base` directory, and accepted those
>> changes where it indeed discovered real typos.
>>
>> (Due to false positives this can unfortunately not be run automatically)
>>
>> The majority of fixes
On Mon, 18 Apr 2022 19:27:21 GMT, Stuart Marks wrote:
>> I think its "belt and suspenders".
>> If the caller does not call `clearPassword` before calling a second
>> `setPassword,` the previous char array will still contain the previous
>> password and remain uncleared in memory for a (longer)
On Mon, 18 Apr 2022 18:07:59 GMT, Roger Riggs wrote:
>> I can see why that might be a good idea. Would require a specification
>> change though. I also think it is fine to keep the behavior the same, and
>> place the responsibility on the application to call `clearPassword` before
>> setting
On Mon, 18 Apr 2022 15:21:18 GMT, Xue-Lei Andrew Fan wrote:
>> Please review this password cleanup enhancement in the PasswordCallback
>> implementation. This is one of the effort to clean up the buffered
>> passwords.
>>
>> The PasswordCallback.setPassword() clones the password, but is not
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-factoring.
>>
>> The CSR will
On Mon, 18 Apr 2022 16:39:36 GMT, Stuart Marks wrote:
>> Xue-Lei Andrew Fan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update test case
>
> src/java.base/share/classes/javax/security/auth/callback/PasswordCallback.java
> line 123:
On Thu, 14 Apr 2022 20:16:38 GMT, Sean Mullan wrote:
>>> Are the changes necessary for this part?
>>
>> @seanjmullan no, they are just performance refinement.
>>
>> If you really that wanna 100% sync ,
>>
>> I can use the old 1.8 api to migrate tha
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.
>
>
This change improves the specification for the case when a
`PKIXRevocationChecker` is supplied as one of the `CertPathChecker` parameters.
Specifically, it makes it more clear that a `PKIXRevocationChecker` overrides
the default revocation checking mechanism of a PKIX service provider, and will
On Mon, 18 Apr 2022 09:46:06 GMT, Sibabrata Sahoo wrote:
> A Test updated to cover the getCodeSigners.
test/jdk/java/security/CodeSource/Implies.java line 60:
> 58: = new CodeSource(thatURL,
> (java.security.cert.Certificate[]) null);
> 59: if (thisCs.implies(thatCs)
On Mon, 18 Apr 2022 04:40:27 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have the simple update reviewed?
>
> In the java.security.jgss module implementation, some of the debug
> information could be generated even if debugging is not enabled, which is not
> resource friendly.
>
>
On Thu, 14 Apr 2022 20:16:21 GMT, Bradford Wetmore wrote:
>> I ran `codespell` on the `src/java.base` directory, and accepted those
>> changes where it indeed discovered real typos.
>>
>> (Due to false positives this can unfortunately not be run automatically)
>>
>> The majority of fixes are
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 and request is to broaden
On Thu, 14 Apr 2022 20:11:37 GMT, XenoAmess wrote:
> > Are the changes necessary for this part?
>
> @seanjmullan no, they are just performance refinement.
>
> If you really that wanna 100% sync ,
>
> I can use the old 1.8 api to migrate that part, and make a mirror pr to that
> part of
On Thu, 14 Apr 2022 18:10:28 GMT, XenoAmess wrote:
>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> add `@LastModified: Apr 2022` to DocumentCache
Right, we generally try to
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-factoring.
>>
>> The CSR will
On Wed, 13 Apr 2022 18:28:33 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/javax/crypto/spec/OAEPParameterSpec.java line 81:
>>
>>> 79: * parameters for mgf -- MGF1ParameterSpec.SHA1
>>> 80: * source of encoding input -- PSource.PSpecified.DEFAULT
>>> 81: *
>>
>> I think
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.
>
> The CSR will be
On Tue, 12 Apr 2022 02:48:51 GMT, Michael StJohns wrote:
> I think deprecating DEFAULT? is wrong.? RFC8017 still has this definition:
>
> > RSAES-OAEP-params ::= SEQUENCE {
> > hashAlgorithm [0] HashAlgorithm DEFAULT sha1,
> > maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1,
On Fri, 8 Apr 2022 13:40:37 GMT, Sean Mullan wrote:
> Please review these changes to update the security libraries to use sealed
> classes. See JEP 409 for more details on sealed classes.
>
> No CSR is required as all the changes are to internal classes. A few classes
> th
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 is to broaden this
stead of sealed.
Sean Mullan 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 revision:
- Make KrbAsRep final.
- Mer
stead of sealed.
Sean Mullan has updated the pull request incrementally with one additional
commit since the last revision:
Make some classes package-private instead of sealed.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8165/files
- new: https://git.openjdk.java.ne
On Fri, 8 Apr 2022 16:11:27 GMT, Weijun Wang wrote:
>> Sean Mullan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Make some classes package-private instead of sealed.
>
> src/java.base/share/classes/sun/
On Fri, 8 Apr 2022 16:17:19 GMT, Weijun Wang wrote:
> It looks `KrbTgsRep.java`, `Krb5ProxyCredential.java`, `Builder.java`,
> `Vertex.java`, `Validator.java`, and `RSAKeyPairGenerator.java` can all be
> made package private.
Good point, although I would prefer to leave `Validator` as public
1 - 100 of 2178 matches
Mail list logo
