On Tue, 9 Apr 2024 00:02:33 GMT, Valerie Peng wrote:
>> This PR fixes a problem regarding the usage of dlerror() where an earlier
>> error message causes a premature error out. Added extra code to clear out
>> earlier error message and made minor code refactoring.
>>
>> No regression test as t
On Mon, 8 Apr 2024 19:33:25 GMT, Valerie Peng wrote:
>> Existing legacy mechanism check disables mechanism(s) when the support is
>> partial, e.g. supports decryption but not encryption, or supports
>> verification but not signing. Some mechanisms can be used for both
>> encryption/decryption
On Tue, 9 Apr 2024 00:02:33 GMT, Valerie Peng wrote:
>> This PR fixes a problem regarding the usage of dlerror() where an earlier
>> error message causes a premature error out. Added extra code to clear out
>> earlier error message and made minor code refactoring.
>>
>> No regression test as t
On Thu, 1 Feb 2024 03:08:52 GMT, Fei Yang wrote:
> Looks good and trivial.
@RealFYang @jnimeh Thanks.
-
PR Comment: https://git.openjdk.org/jdk/pull/17646#issuecomment-2043998825
> This PR fixes a problem regarding the usage of dlerror() where an earlier
> error message causes a premature error out. Added extra code to clear out
> earlier error message and made minor code refactoring.
>
> No regression test as this can't be reproduced using the NSS library from
> artifa
On Wed, 3 Apr 2024 21:54:02 GMT, Weijun Wang wrote:
> When UAC is enabled and there is no privilege, I can see that some private
> key entries (Ex: the one for iis) become trusted certificate entries, which
> means their private key is not observable. Have you noticed something
> similar? Are
On Mon, 8 Apr 2024 17:38:51 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address one more review comment.
>
> src/jdk.crypto.cryptoki/unix/native/libj2pkcs11/p11_md.c line 188:
>
>> 186:
On Fri, 5 Apr 2024 13:17:21 GMT, Sean Mullan wrote:
> Please review this change which fixes an issue in revocation checking of
> CRLs. A certificate's CRL Distribution Points extension can contain multiple
> Distribution Points (DPs), and each DP can contain one or more references to
> a CRL.
> Existing legacy mechanism check disables mechanism(s) when the support is
> partial, e.g. supports decryption but not encryption, or supports
> verification but not signing. Some mechanisms can be used for both
> encryption/decryption and sign/verify such as RSA related ones. If the
> particu
On Thu, 4 Apr 2024 21:23:25 GMT, Valerie Peng wrote:
>> This PR fixes a problem regarding the usage of dlerror() where an earlier
>> error message causes a premature error out. Added extra code to clear out
>> earlier error message and made minor code refactoring.
>>
>> No regression test as t
Hi Sean,
Thx for warning me about that.
I understand that maybe this is too soon for contributing code ? and
also that finally this not so sure that you want to integrate (D)TLS
feature that I mentioned previously as Key IoT features.
So not sure what should I do now. In my first message,
On Mon, 8 Apr 2024 12:41:23 GMT, Sean Mullan wrote:
>> Please review this change which fixes an issue in revocation checking of
>> CRLs. A certificate's CRL Distribution Points extension can contain multiple
>> Distribution Points (DPs), and each DP can contain one or more references to
>> a C
> Please review this change which fixes an issue in revocation checking of
> CRLs. A certificate's CRL Distribution Points extension can contain multiple
> Distribution Points (DPs), and each DP can contain one or more references to
> a CRL. These CRL references are typically specified as URLs.
13 matches
Mail list logo
