On 07/03/2024 23:30, Peter Firmstone wrote:
Can this change be documented along with others planned in the new JEP
so these changes are easier to track?
As Sean said, JEP 411 already links to JDK-8267108 that introduced
Subject.current/callAs methods as the replacements for getSubject/doAs.
Hi Paul,
If you're interested in dealing with handshake extensions from user code,
that is currently not possible. SSLEngine abstracts away all TLS messaging.
SSLParameters can be used to configure a limited subset of extensions to
send (like server_name or application protocol), and the negotiated
On Thu, 8 Feb 2024 09:13:18 GMT, Prajwal Kumaraswamy
wrote:
>> I have changed the title to reflect the specific change made here.
>> I'll make changes in createServerPossession as well.
>
> I have made changes and attached the testing snapshots in a zip file attached
> in bug description
I hav
On Thu, 8 Feb 2024 09:11:14 GMT, Prajwal Kumaraswamy
wrote:
>> During the time of server certificate validation, users have the flexibility
>> to use a custom X509 Key Manager implementation by extending
>> "X509ExtendedKeyManager.".
>> In such cases, printing the class name in X509Authenticat
> During the time of server certificate validation, users have the flexibility
> to use a custom X509 Key Manager implementation by extending
> "X509ExtendedKeyManager.".
> In such cases, printing the class name in X509Authentication.java will be
> helpful to trace any failure of the SSL connect
On Thu, 7 Mar 2024 23:13:14 GMT, Hai-May Chao wrote:
>> Change was made to engineGetEntry() in PKCS12KeyStore to extract the key and
>> certificate chain from Entry only once. This is because the entry may get
>> updated between engineGetKey() and engineGetCertificateChain() which causes
>> in
On Thu, 7 Mar 2024 23:13:14 GMT, Hai-May Chao wrote:
>> Change was made to engineGetEntry() in PKCS12KeyStore to extract the key and
>> certificate chain from Entry only once. This is because the entry may get
>> updated between engineGetKey() and engineGetCertificateChain() which causes
>> in
Can this change be documented along with others planned in the new JEP
so these changes are easier to track?
There's no mention of this change in the bug id.
We've placed all future development on hold in software that depends on
Java's Authorization API, (apart from bug fixes), while we figur
> Change was made to engineGetEntry() in PKCS12KeyStore to extract the key and
> certificate chain from Entry only once. This is because the entry may get
> updated between engineGetKey() and engineGetCertificateChain() which causes
> inconsistent result. A new test was added to assess and manip
On Thu, 7 Mar 2024 21:22:11 GMT, Weijun Wang wrote:
>> Hai-May Chao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update bug number in the test
>
> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1346:
>
>> 13
Sent from my iPhone
> On 8 Mar 2024, at 1:35 am, Sean Mullan wrote:
>
> On 3/7/24 7:35 AM, Peter Firmstone wrote:
>> Good Evening,
>> Just noticed the comment below, this is a breaking change.
>> Recalling earlier discussions on this list about the removal of the existing
>> Authorization AP
On Thu, 7 Mar 2024 09:30:41 GMT, Alan Bateman wrote:
>> Jan Lahoda has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/native-access-modules1' into
>> native-access-modules1
>> - Reflecting review f
> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
> automatically granted the native access. I am working on an upgrade of JLine
> inside the `jdk.internal.le` module, and I would like to replace the current
> native bindings with FFM-based bindings (which are now some
Thanks for replying, maybe you can point me in the right direction? So
far none of the docs cover what I need; I feel like I'm being forced
to use BouncyCastle or find something else, when I'd rather stay in
the JDK/JSSE domain. Filed bugs with regard to DTLS are sitting for
years. Unless otherwise
On Wed, 6 Mar 2024 21:16:25 GMT, Jan Lahoda wrote:
>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
>> automatically granted the native access. I am working on an upgrade of JLine
>> inside the `jdk.internal.le` module, and I would like to replace the current
>> na
On Thu, 7 Mar 2024 15:12:18 GMT, Sean Mullan wrote:
>> This enhancement simplifies and improves the performance of the Comparator
>> that the PKIX CertPathBuilder uses to sort candidate certificates.
>>
>> [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.1) requires
>> that cert
On Thu, 7 Mar 2024 17:20:08 GMT, Hai-May Chao wrote:
>> Change was made to engineGetEntry() in PKCS12KeyStore to extract the key and
>> certificate chain from Entry only once. This is because the entry may get
>> updated between engineGetKey() and engineGetCertificateChain() which causes
>> in
On Sat, 3 Feb 2024 17:28:29 GMT, Eirik Bjørsnøs wrote:
>> Please consider this PR which suggests we rename `ZipEntry.extraAttributes`
>> to `ZipEntry.externalAttributes`.
>>
>> This field was introduced in
>> [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under
>> the
Hi,
Thanks for your interest in Java Security but this list is not for help
with code and questions about using the APIs. I suggest you check
various forums on Java and Java Security for more assistance on your
questions.
Thanks,
Sean
On 3/6/24 3:36 PM, Mondain wrote:
I'm here to inquire p
> Change was made to engineGetEntry() in PKCS12KeyStore to extract the key and
> certificate chain from Entry only once. This is because the entry may get
> updated between engineGetKey() and engineGetCertificateChain() which causes
> inconsistent result. A new test was added to assess and manip
On Thu, 7 Mar 2024 16:53:05 GMT, Korov wrote:
>> src/java.base/share/classes/java/net/SocketPermission.java line 305:
>>
>>> 303: private void setDeny() {
>>> 304: defaultDeny = true;
>>> 305: }
>>
>> This method is used in internal whitebox tests - please revert this change
>
>
Change was made to engineGetEntry() in PKCS12KeyStore to extract the key and
certificate chain from Entry only once. This is because the entry may get
updated between engineGetKey() and engineGetCertificateChain() which causes
inconsistent result. A new test was added to assess and manipulate
P
On Thu, 7 Mar 2024 16:21:14 GMT, Daniel Fuchs wrote:
> This is used by internal whitebox test. Please revert this change.
Reverted.
> src/java.base/share/classes/java/net/SocketPermission.java line 305:
>
>> 303: private void setDeny() {
>> 304: defaultDeny = true;
>> 305: }
>
> Removing unused parameter `defval` in `SocketPermission.initEphemeralPorts`,
> so the variable `PRIV_PORT_MAX` and `DEF_EPH_LOW` unused too.
>
> Removing unused parameter `cname` in `SocketPermission.authorizedIPv4` and
> `SocketPermission.authorizedIPv6`.
>
> Parameter 'action' must be not e
On Sat, 2 Mar 2024 13:51:04 GMT, Korov wrote:
>> Removing unused parameter `defval` in `SocketPermission.initEphemeralPorts`,
>> so the variable `PRIV_PORT_MAX` and `DEF_EPH_LOW` unused too.
>>
>> Removing unused parameter `cname` in `SocketPermission.authorizedIPv4` and
>> `SocketPermission.a
> This enhancement simplifies and improves the performance of the Comparator
> that the PKIX CertPathBuilder uses to sort candidate certificates.
>
> [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.1) requires
> that certificates include authority and subject key identifiers to f
On 3/7/24 7:35 AM, Peter Firmstone wrote:
Good Evening,
Just noticed the comment below, this is a breaking change.
Recalling earlier discussions on this list about the removal of the
existing Authorization API post JEP411, it was going to be assigned
another overarching JEP.
Yes that JEP is
On Thu, 8 Feb 2024 09:11:14 GMT, Prajwal Kumaraswamy
wrote:
>> During the time of server certificate validation, users have the flexibility
>> to use a custom X509 Key Manager implementation by extending
>> "X509ExtendedKeyManager.".
>> In such cases, printing the class name in X509Authenticat
On Thu, 7 Mar 2024 12:40:09 GMT, Daniel Jeliński wrote:
>> Currently the SunPKCS11 provider requires other providers in order to offer
>> ECDHE, FFDHE and RSA-PSS in TLS handshakes:
>> - FFDHE requires DiffieHellman AlgorithmParameters from SunJCE
>> - ECDHE requires the SunEC provider to be ins
> Currently the SunPKCS11 provider requires other providers in order to offer
> ECDHE, FFDHE and RSA-PSS in TLS handshakes:
> - FFDHE requires DiffieHellman AlgorithmParameters from SunJCE
> - ECDHE requires the SunEC provider to be installed
> - RSA-PSS requires RSASSA-PSS AlgorithmParameters fro
Good Evening,
Just noticed the comment below, this is a breaking change.
Recalling earlier discussions on this list about the removal of the
existing Authorization API post JEP411, it was going to be assigned
another overarching JEP.
Can we have the entire API destructed in one swift action?
On Wed, 6 Mar 2024 16:20:43 GMT, Sean Coffey wrote:
>> src/java.base/share/classes/sun/security/util/Debug.java line 294:
>>
>>> 292: if (printThreadDetails) {
>>> 293: retString = toHexString(Thread.currentThread().threadId())
>>> + "|" +
>>> 294: Thread
On Tue, 5 Mar 2024 19:53:46 GMT, Weijun Wang wrote:
>> Subject is stored in the RMIConnectionImpl:
>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
>>
>> (That is complicated by SubjectDelegation, which we deprecated for removal.
>> I have the PR out
On Wed, 6 Mar 2024 21:22:40 GMT, Jan Lahoda wrote:
>> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line
>> 812:
>>
>>> 810: }
>>> 811:
>>> 812: private static void addEnableNativeAccess(ModuleLayer layer,
>>> Set moduleNames, boolean shouldWarn) {
>>
>> The pr
On Wed, 6 Mar 2024 21:16:25 GMT, Jan Lahoda wrote:
>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
>> automatically granted the native access. I am working on an upgrade of JLine
>> inside the `jdk.internal.le` module, and I would like to replace the current
>> na
35 matches
Mail list logo
