Allow `udp_preference_limit = 0` to force TCP.
The reason for this bug is that it was read in a similar way as `kdc_timeout`
and `max_retries`, both must be positive to have effect.
-
Commit messages:
- the fix
Changes: https://git.openjdk.org/jdk/pull/19638/files
Webrev:
On Mon, 10 Jun 2024 20:29:54 GMT, Weijun Wang wrote:
> Allow `udp_preference_limit = 0` to force TCP.
>
> The reason for this bug is that it was read in a similar way as `kdc_timeout`
> and `max_retries`, both must be positive to have effect.
This code change introduce a beh
On Tue, 28 May 2024 14:42:13 GMT, John Jiang wrote:
> A simple cleanup on the changes introduced by JDK-8329538.
Looks good. Thanks for the cleanup.
-
Marked as reviewed by weijun (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19429#pullrequestreview-2090895326
On Mon, 13 May 2024 14:34:41 GMT, Weijun Wang wrote:
> Add a new system property to control the name comparison in keytab and ccache
> entry lookup.
This pull request has now been integrated.
Changeset: da3001da
Author:Weijun Wang
URL:
https://git.openjdk.org/jdk/
On Tue, 21 May 2024 17:47:47 GMT, Valerie Peng wrote:
> Changes look good to me. Thanks~
Thanks a lot! Can you please also review the CSR?
-
PR Comment: https://git.openjdk.org/jdk/pull/19216#issuecomment-2123163145
> Add a new system property to control the name comparison in keytab and ccache
> entry lookup.
Weijun Wang has updated the pull request incrementally with two additional
commits since the last revision:
- remove commented out code but leave comment
- fast fail and no need to chec
On Mon, 20 May 2024 22:36:54 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> enhance test
>
> src/java.security.jgss/share/classes/sun/security/krb5/PrincipalNa
> Add a new system property to control the name comparison in keytab and ccache
> entry lookup.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
enhance test
-
Changes:
- all: https://git.openjdk.org/jdk/pull
On Mon, 20 May 2024 16:11:35 GMT, Mark Powers wrote:
> Are there any existing interoperability tests?
Not with real KDCs, but I can probably enhance the test to cover the case when
this prop is not set.
> src/java.security.jgss/share/classes/sun/security/krb5/PrincipalName.java
> line 634:
>
On Sat, 18 May 2024 13:01:30 GMT, SendaoYan wrote:
> > Is there a related bug on the intermittent failure?
>
> I have reportd the itermittent failure
> [JDK-8332433](https://bugs.openjdk.org/browse/JDK-8332433), and
> [JDK-8316138](https://bugs.openjdk.org/browse/JDK-8316138) is subtask of
>
On Sat, 18 May 2024 12:34:39 GMT, SendaoYan wrote:
> Hi all,
> Before `CAInterop.java#globalsigne46` imtermittent failure has been
> resolved, mark the test as intermittent.
Is there a related bug on the intermittent failure?
-
PR Comment:
On Wed, 15 May 2024 19:59:59 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>
> Kevin Driver has updated the
On Fri, 10 May 2024 14:00:55 GMT, Weijun Wang wrote:
>> Add `Cipher::export` API.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> change new method to non final
I don't think KDF API is needed for a
On Fri, 10 May 2024 14:00:55 GMT, Weijun Wang wrote:
>> Add `Cipher::export` API.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> change new method to non final
As for the cart and horse order, I thin
On Fri, 10 May 2024 14:00:55 GMT, Weijun Wang wrote:
>> Add `Cipher::export` API.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> change new method to non final
I haven't started JDK-8325548 yet since
On Fri, 10 May 2024 14:00:55 GMT, Weijun Wang wrote:
>> Add `Cipher::export` API.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> change new method to non final
I don't think it's worth inventing a new
On Tue, 14 May 2024 22:14:47 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>
> Kevin Driver has updated the
On Mon, 13 May 2024 23:11:45 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>
> Kevin Driver has updated the
On Mon, 13 May 2024 23:11:45 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>
> Kevin Driver has updated the
On Mon, 13 May 2024 23:08:41 GMT, Kevin Driver wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/HkdfKeyDerivation.java
>> line 81:
>>
>>> 79: * if the initialization parameters are inappropriate for this
>>> {@code KDFSpi}
>>> 80: */
>>> 81: protected
On Mon, 13 May 2024 22:34:04 GMT, Kevin Driver wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/HkdfKeyDerivation.java
>> line 237:
>>
>>> 235: } catch (InvalidKeyException ike) {
>>> 236: throw new InvalidParameterSpecException(
>>> 237:
On Fri, 10 May 2024 20:54:45 GMT, Kevin Driver wrote:
>> src/java.base/share/classes/javax/crypto/spec/HKDFParameterSpec.java line 47:
>>
>>> 45: final class Builder {
>>> 46:
>>> 47: Extract extract = null;
>>
>> No need to store an `extract` field. Just create one and return it
On Mon, 13 May 2024 17:37:38 GMT, Sean Mullan wrote:
>> Kevin Driver has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update @return statement
>
> src/java.base/share/classes/javax/crypto/KDFSpi.java line 72:
>
>> 70: protected
On Mon, 13 May 2024 09:31:53 GMT, Alan Bateman wrote:
>> Kevin Driver has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> re-enable preview annotations
>
> src/java.base/share/classes/javax/crypto/KDFSpi.java line 41:
>
>> 39: * All the
On Mon, 13 May 2024 19:01:09 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>
> Kevin Driver has updated the
Add a new system property to control the name comparison in keytab and ccache
entry lookup.
-
Commit messages:
- year
- the commit
Changes: https://git.openjdk.org/jdk/pull/19216/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=19216=00
Issue:
On Fri, 10 May 2024 20:55:47 GMT, Kevin Driver wrote:
>> I agree. Also, if we do want to validate arguments (and I don't know if we
>> need to), then I think the `Extract` constructor should be responsible for
>> doing that, not the `Builder`. Doing it in `Extract` is safer since it is
>>
On Sun, 12 May 2024 14:43:04 GMT, Sean Mullan wrote:
>> Kevin Driver has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> commenting out until better understood -- causing failures
>
> src/java.base/share/classes/javax/crypto/KDF.java line
On Mon, 13 May 2024 09:18:55 GMT, Alan Bateman wrote:
>> Kevin Driver has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> re-enable preview annotations
>
> src/java.base/share/classes/javax/crypto/KDF.java line 50:
>
>> 48: * {@code KDF}
On Mon, 13 May 2024 03:46:50 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>
> Kevin Driver has updated the
On Sat, 11 May 2024 16:01:34 GMT, Nizar Benalla wrote:
> Code cleanup. The package was added back in
> [8056174](https://bugs.openjdk.org/browse/JDK-8056174).
> Thanks to anyone reviewing this change. I split my changes into 1 PR per
> module to make reviewing simpler.
LGTM. Thanks!
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Sun, 12 May 2024 14:39:40 GMT, Sean Mullan wrote:
>> Kevin Driver has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> commenting out until better understood -- causing failures
>
> src/java.base/share/classes/javax/crypto/KDF.java line
On Sat, 11 May 2024 02:06:09 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>
> Kevin Driver has updated the
On Fri, 10 May 2024 14:00:55 GMT, Weijun Wang wrote:
>> Add `Cipher::export` API.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> change new method to non final
In fact, the original definition of ex
On Fri, 10 May 2024 14:00:55 GMT, Weijun Wang wrote:
>> Add `Cipher::export` API.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> change new method to non final
I don't know if any AES cipher defin
On Fri, 10 May 2024 14:00:55 GMT, Weijun Wang wrote:
>> Add `Cipher::export` API.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> change new method to non final
One use case for this method is HPKE
> Add `Cipher::export` API.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
change new method to non final
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18409/files
- new: https://git.openjdk.org/jdk/pull/18
On Fri, 10 May 2024 13:08:00 GMT, Alan Bateman wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> rename
>
> src/java.base/share/classes/javax/crypto/Cipher.java line 2625:
>
> Add `Cipher::export` API.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
rename
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18409/files
- new: https://git.openjdk.org/jdk/pull/18409/files/8834f04e..b8658
On Fri, 10 May 2024 12:58:06 GMT, Sean Mullan wrote:
>> Add `Cipher::export` API.
>
> src/java.base/share/classes/javax/crypto/Cipher.java line 2625:
>
>> 2623: * @since 23
>> 2624: */
>> 2625: public final SecretKey export(byte[] context, String algorithm,
>> int length) {
>
>
Add `Cipher::export` API.
-
Commit messages:
- Merge branch 'master' into 8325513
- make test work
- Add test
- Wording
- Wording
- relax requirement
- wording
- the fix
Changes: https://git.openjdk.org/jdk/pull/18409/files
Webrev:
On Fri, 10 May 2024 00:15:32 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>
> Kevin Driver has updated the
On Thu, 9 May 2024 19:46:39 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>
> Kevin Driver has updated the
On Thu, 9 May 2024 19:46:39 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>
> Kevin Driver has updated the
On Thu, 9 May 2024 20:19:41 GMT, Weijun Wang wrote:
>> Kevin Driver has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> some code review comments
>
> src/java.base/share/classes/com/sun/crypto/provider/Hkd
On Thu, 9 May 2024 19:46:39 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>
> Kevin Driver has updated the
On Thu, 9 May 2024 16:19:36 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>
> Kevin Driver has updated the
On Thu, 9 May 2024 16:19:36 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>
> Kevin Driver has updated the
On Tue, 23 Apr 2024 20:42:51 GMT, Kevin Driver wrote:
> Introduce an API for Key Derivation Functions (KDFs), which are cryptographic
> algorithms for deriving additional keys from a secret key and other data. See
> [JEP 478](https://openjdk.org/jeps/478).
Some comments on
On Tue, 23 Apr 2024 20:42:51 GMT, Kevin Driver wrote:
> Introduce an API for Key Derivation Functions (KDFs), which are cryptographic
> algorithms for deriving additional keys from a secret key and other data. See
> [JEP 478](https://openjdk.org/jeps/478).
Two comments on HKDF:
1. Expand
On Tue, 7 May 2024 17:08:46 GMT, Weijun Wang wrote:
> Update PSL to the latest upstream version.
This pull request has now been integrated.
Changeset: b9108334
Author: Weijun Wang
URL:
https://git.openjdk.org/jdk/commit/b91083341aba952befadd79020079920f9540999
Stats: 568 li
Update PSL to the latest upstream version.
-
Commit messages:
- the change
Changes: https://git.openjdk.org/jdk/pull/19127/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=19127=00
Issue: https://bugs.openjdk.org/browse/JDK-8331864
Stats: 568 lines in 5 files changed: 408
On Thu, 2 May 2024 21:24:19 GMT, Francisco Ferrari Bihurriet
wrote:
>> The implementation of this proposal is based on the requirements,
>> specification and design choices described in the [JDK-8319332] ticket and
>> its respective CSR [JDK-8319333]. What follows are implementation notes
>>
On Thu, 2 May 2024 20:34:22 GMT, Francisco Ferrari Bihurriet
wrote:
>> The implementation of this proposal is based on the requirements,
>> specification and design choices described in the [JDK-8319332] ticket and
>> its respective CSR [JDK-8319333]. What follows are implementation notes
>>
On Thu, 2 May 2024 19:06:00 GMT, Weijun Wang wrote:
>> Francisco Ferrari Bihurriet has updated the pull request incrementally with
>> one additional commit since the last revision:
>>
>> Profiles documentation adjustments.
>>
>> Co-authored-by:
On Thu, 2 May 2024 16:45:09 GMT, Francisco Ferrari Bihurriet
wrote:
>> The implementation of this proposal is based on the requirements,
>> specification and design choices described in the [JDK-8319332] ticket and
>> its respective CSR [JDK-8319333]. What follows are implementation notes
>>
On Thu, 2 May 2024 14:07:13 GMT, Francisco Ferrari Bihurriet
wrote:
>> The implementation of this proposal is based on the requirements,
>> specification and design choices described in the [JDK-8319332] ticket and
>> its respective CSR [JDK-8319333]. What follows are implementation notes
>>
On Thu, 2 May 2024 14:07:13 GMT, Francisco Ferrari Bihurriet
wrote:
>> The implementation of this proposal is based on the requirements,
>> specification and design choices described in the [JDK-8319332] ticket and
>> its respective CSR [JDK-8319333]. What follows are implementation notes
>>
On Thu, 2 May 2024 14:07:13 GMT, Francisco Ferrari Bihurriet
wrote:
>> The implementation of this proposal is based on the requirements,
>> specification and design choices described in the [JDK-8319332] ticket and
>> its respective CSR [JDK-8319333]. What follows are implementation notes
>>
On Tue, 23 Apr 2024 17:19:55 GMT, Francisco Ferrari Bihurriet
wrote:
>> The implementation of this proposal is based on the requirements,
>> specification and design choices described in the [JDK-8319332] ticket and
>> its respective CSR [JDK-8319333]. What follows are implementation notes
On Tue, 23 Apr 2024 17:19:55 GMT, Francisco Ferrari Bihurriet
wrote:
>> The implementation of this proposal is based on the requirements,
>> specification and design choices described in the [JDK-8319332] ticket and
>> its respective CSR [JDK-8319333]. What follows are implementation notes
On Tue, 23 Apr 2024 17:19:55 GMT, Francisco Ferrari Bihurriet
wrote:
>> The implementation of this proposal is based on the requirements,
>> specification and design choices described in the [JDK-8319332] ticket and
>> its respective CSR [JDK-8319333]. What follows are implementation notes
On Tue, 23 Apr 2024 17:19:55 GMT, Francisco Ferrari Bihurriet
wrote:
>> The implementation of this proposal is based on the requirements,
>> specification and design choices described in the [JDK-8319332] ticket and
>> its respective CSR [JDK-8319333]. What follows are implementation notes
On Tue, 23 Apr 2024 17:19:55 GMT, Francisco Ferrari Bihurriet
wrote:
>> The implementation of this proposal is based on the requirements,
>> specification and design choices described in the [JDK-8319332] ticket and
>> its respective CSR [JDK-8319333]. What follows are implementation notes
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 Mon, 22 Apr 2024 20:42:44 GMT, Francisco Ferrari Bihurriet
wrote:
>> The implementation of this proposal is based on the requirements,
>> specification and design choices described in the [JDK-8319332] ticket and
>> its respective CSR [JDK-8319333]. What follows are implementation notes
On Fri, 19 Apr 2024 18:51:32 GMT, MustavData wrote:
>> @rebarbora-mckvak Can you please update [this
>> test](https://github.com/openjdk/jdk/blob/master/test/jdk/sun/security/mscapi/AllTypes.java)?
>> There is no need for the `hasAdminPrivileges` flag now.
>
> @wangweij , your [comment on
>
On Wed, 6 Mar 2024 12:19:14 GMT, Francisco Ferrari Bihurriet
wrote:
>> The implementation of this proposal is based on the requirements,
>> specification and design choices described in the [JDK-8319332] ticket and
>> its respective CSR [JDK-8319333]. What follows are implementation notes
>>
On Fri, 19 Apr 2024 13:31:42 GMT, Francisco Ferrari Bihurriet
wrote:
>> Oh, I meant the final `else`. What does it mean if a file is neither
>> "regular" nor "directory"? Also I don't quite understand why one uses
>> `toRealPath` and one uses `toAbsolutePath`. Is this related to resolving a
On Fri, 19 Apr 2024 13:02:03 GMT, Francisco Ferrari Bihurriet
wrote:
> > > Is it worth breaking such invalid URLs?
I'm just not sure about the compatibility impact. The example
"file:///C:\some\path\extra.properties" you gave looks quite innocent and could
be generated by a casual script.
On Fri, 19 Apr 2024 12:58:32 GMT, Francisco Ferrari Bihurriet
wrote:
>> src/java.base/share/classes/java/security/Security.java line 256:
>>
>>> 254: } else if (Files.isDirectory(path)) {
>>> 255: throw new IOException("Is a directory");
>>> 256: } else
On Wed, 17 Apr 2024 19:14:30 GMT, Ben Perez wrote:
>> Updated `getService` to check whether `getProvider` returns null when
>> checking for preferred providers and `continue` the loop if that is the
>> case. Added `NullPreferredList` test.
>
> Ben Perez has updated the pull request with a new
On Wed, 6 Mar 2024 12:19:14 GMT, Francisco Ferrari Bihurriet
wrote:
>> The implementation of this proposal is based on the requirements,
>> specification and design choices described in the [JDK-8319332] ticket and
>> its respective CSR [JDK-8319333]. What follows are implementation notes
>>
On Wed, 6 Mar 2024 12:19:14 GMT, Francisco Ferrari Bihurriet
wrote:
>> The implementation of this proposal is based on the requirements,
>> specification and design choices described in the [JDK-8319332] ticket and
>> its respective CSR [JDK-8319333]. What follows are implementation notes
>>
On Thu, 11 Apr 2024 16:29:00 GMT, Ben Perez wrote:
> Updated `getService` to check whether `getProvider` returns null when
> checking for preferred providers and `continue` the loop if that is the case.
> Added `NullPreferredList` test.
The change looks good, just some tiny comments. Also,
On Thu, 11 Apr 2024 16:29:00 GMT, Ben Perez wrote:
> Updated `getService` to check whether `getProvider` returns null when
> checking for preferred providers and `continue` the loop if that is the case.
> Added `NullPreferredList` test.
test/jdk/sun/security/jca/app-security.properties line
On Tue, 16 Apr 2024 17:21:11 GMT, Valerie Peng wrote:
>> It is reported that some PKCS#11 library/vendor reports major version 3, but
>> doesn't implement the C_GetInterface function and the resulting 'interface'
>> variable value may be NULL and cause unexpected crash later.
>>
>> This PR
On Tue, 16 Apr 2024 00:15:34 GMT, Valerie Peng wrote:
> It is reported that some PKCS#11 library/vendor reports major version 3, but
> doesn't implement the C_GetInterface function and the resulting 'interface'
> variable value may be NULL and cause unexpected crash later.
>
> This PR would
On Sun, 30 Apr 2023 13:03:38 GMT, Weijun Wang wrote:
> The CC can be loaded with any file and its name is not static.
>
> `MemoryCredentialsCache` is removed since it's not used anywhere. We've
> already supported native ccache reading directly with JNI method
&g
> The CC can be loaded with any file and its name is not static.
>
> `MemoryCredentialsCache` is removed since it's not used anywhere. We've
> already supported native ccache reading directly with JNI method
> `Credentials::acquireDefaultNativeCreds`.
Weijun Wang has updated t
> The CC can be loaded with any file and its name is not static.
>
> `MemoryCredentialsCache` is removed since it's not used anywhere. We've
> already supported native ccache reading directly with JNI method
> `Credentials::acquireDefaultNativeCreds`.
Weijun Wang has updated t
> The CC can be loaded with any file and its name is not static.
>
> `MemoryCredentialsCache` is removed since it's not used anywhere. We've
> already supported native ccache reading directly with JNI method
> `Credentials::acquireDefaultNativeCreds`.
Weijun Wang has updated t
> The CC can be loaded with any file and its name is not static.
>
> `MemoryCredentialsCache` is removed since it's not used anywhere. We've
> already supported native ccache reading directly with JNI method
> `Credentials::acquireDefaultNativeCreds`.
Weijun Wang has updated t
On Wed, 10 Apr 2024 13:09:37 GMT, rebarbora-mckvak wrote:
>> Yes it's self signed one.
>>
>> No it's not added to any other keystore. When I said
>> "TrustedCertificateEntry" it's only because in a Java KeyStore an entry with
>> only a certificate is called a TrustedCertificateEntry.
>>
>>
On Thu, 11 Apr 2024 07:57:12 GMT, Bernd wrote:
>> rebarbora-mckvak has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8313367: copyright updated
>
> Did you test with CNG keys as well? Using the new providers is much more
> important
On Wed, 10 Apr 2024 20:46:20 GMT, rebarbora-mckvak wrote:
>> src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp line 807:
>>
>>> 805: // Acquire an alternative CSP handle
>>> 806: if (::CryptAcquireContext(, LPCSTR(pbData),
>>> NULL, //deprecated
>>> 807:
On Wed, 10 Apr 2024 21:10:16 GMT, rebarbora-mckvak wrote:
>> This fixes the defect described at
>> https://bugs.openjdk.org/browse/JDK-8313367
>>
>> If the process does not have write permissions, the store is opened as
>> read-only (instead of failing).
>>
>> Please note that permissions to
On Fri, 22 Mar 2024 22:25:47 GMT, rebarbora-mckvak wrote:
>> This fixes the defect described at
>> https://bugs.openjdk.org/browse/JDK-8313367
>>
>> If the process does not have write permissions, the store is opened as
>> read-only (instead of failing).
>>
>> Please note that permissions to
On Fri, 22 Mar 2024 22:25:47 GMT, rebarbora-mckvak wrote:
>> This fixes the defect described at
>> https://bugs.openjdk.org/browse/JDK-8313367
>>
>> If the process does not have write permissions, the store is opened as
>> read-only (instead of failing).
>>
>> Please note that permissions to
On Tue, 9 Apr 2024 23:19:53 GMT, Jonathan Gibbons wrote:
>> Nizar Benalla has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update copyright year to 2024
>
> [wangweij](https://github.com/wangweij) commented [3 weeks
>
On Fri, 5 Apr 2024 06:31:16 GMT, Julian Waters wrote:
>> I regret not actually addressing the issues with the goto labels in
>> https://github.com/openjdk/jdk/pull/15996, where initialization of locals in
>> sspi were jumped over by gotos to a certain label. I changed the
>> initializations
On Fri, 22 Mar 2024 22:25:47 GMT, rebarbora-mckvak wrote:
>> This fixes the defect described at
>> https://bugs.openjdk.org/browse/JDK-8313367
>>
>> If the process does not have write permissions, the store is opened as
>> read-only (instead of failing).
>>
>> Please note that permissions to
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
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
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
On Fri, 5 Apr 2024 13:48:24 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
On Fri, 22 Mar 2024 22:25:47 GMT, rebarbora-mckvak wrote:
>> This fixes the defect described at
>> https://bugs.openjdk.org/browse/JDK-8313367
>>
>> If the process does not have write permissions, the store is opened as
>> read-only (instead of failing).
>>
>> Please note that permissions to
On Fri, 22 Mar 2024 18:43:11 GMT, MustavData wrote:
>> I also noticed a different problem. No matter if privileged or unprivileged,
>> `keytool -genkeypair -storetype Windows-My-LOCALMACHINE` works successfully
>> but the entries are actually created in Windows-MY-CURRENTUSER. This is
>>
On Fri, 29 Mar 2024 15:09:50 GMT, Sean Coffey wrote:
>> Proposal to improve the `java.security.debug` output so that options exist
>> to add thread ID, thread name, source of log record and a timestamp
>> information to the output.
>>
>> examples:
>> format without patch :
>>
>>
>>
1 - 100 of 1007 matches
Mail list logo
