On Fri, 7 Feb 2025 22:19:41 GMT, Valerie Peng wrote:
> Could someone help review this straight forward change?
>
> Changing to use block size instead of the hash output length as the default
> Hmac key sizes. The relevant regression tests have been adjusted accordingly
> as well.
>
> Thanks,
> During JVM startup, the class KnownOIDs is loaded. KnownOIDs has 10 anonymous
> classes, which slows down the startup. This PR is to improve KnownOIDs and
> eliminate unnecessary embedded classes.
>
>
> Here's how to reproduce this:
>
>
> public class Startup {
> public static void main
On Fri, 4 Apr 2025 13:36:19 GMT, Hannes Wallnöfer wrote:
> Please review an enhancement to treat classes and interfaces that are not
> included and not unconditionally exported as hidden. This means they do not
> show up in the generated documentation even if they are implemented or
> extended
On Wed, 2 Apr 2025 07:38:34 GMT, Ferenc Rakoczi wrote:
>> By using the AVX-512 vector registers the speed of the computation of the
>> ML-DSA algorithms (key generation, document signing, signature verification)
>> can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request in
> **A DESCRIPTION OF THE PROBLEM :**
> Enabling -Djava.security.debug=x509,ava affects how special characters in
> certificates are processed. The expected behavior is that debugging should
> not interfere with the normal encoding of certificate fields.
>
> **Fix:**
> The Debugging will no longe
On Wed, 2 Apr 2025 21:43:19 GMT, Valerie Peng wrote:
> This PR removes the internal JSSE HKDF impl and changes to use the KDF API
> for the HKDF support from JCA/JCE providers.
>
> This is just code refactoring. Known-answer regression test for the internal
> JSSE HKDF impl is removed as the t
On Thu, 3 Apr 2025 00:51:44 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java line 120:
>>
>>> 118: SecretKey earlySecret =
>>> hkdf.deriveKey("TlsEarlySecret",
>>> 119: HKDFParameterSpec.ofExtract().addSalt(zer
On Fri, 4 Apr 2025 19:00:02 GMT, Roger Riggs wrote:
>> Now that the Security Manager is permanently disabled, the following
>> permission classes in the core libraries area can be deprecated for removal
>> as they are no longer useful: FilePermission, LinkPermission,
>> LoggingPermission, Prop
On Tue, 25 Mar 2025 14:29:22 GMT, Artur Barashev wrote:
> We have an incorrect regex syntax when describing a "usage" algorithm
> constraint. Current syntax indicates that usage types are optional while they
> are not: at least one usage type should be specified.
looks good
-
Mar
On Fri, 17 Jan 2025 17:24:57 GMT, Martin Balao wrote:
> Hello,
>
> I would like to propose a solution for this test that makes it more clear
> when it's skipped.
>
> Regards,
> Martin.-
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.org/jdk
On Tue, 18 Mar 2025 23:15:13 GMT, Francisco Ferrari Bihurriet
wrote:
>> As part of [https://bugs.openjdk.org/browse/JDK-8301553](JDK-8301553),
>> SunPKCS11 provider added support for PBE SecretKeyFactories for
>> `HmacPBESHAxxx` and `PBEWithHmacSHAxxxAndAES_yyy`. These impls produce keys
>> w
> Disable SHA-1 in TLS/DTLS 1.2 handshake signatures (but not in certificate
> signatures).
> https://www.rfc-editor.org/rfc/rfc9155.html
Artur Barashev has updated the pull request incrementally with one additional
commit since the last revision:
Disable ECDSA_SHA1 to be used for TLSv1.3 han
> This code change adds supports for getting public key from an EC private key
> and slicing a secret key in PKCS #11. These are necessary to support DHKEM
> for keys in SunPKCS11. The first support is still not complete and there is
> no way to get the public key if the private key is unwrapped
> Now that the Security Manager is permanently disabled, the following
> permission classes in the core libraries area can be deprecated for removal
> as they are no longer useful: FilePermission, LinkPermission,
> LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission,
> a
> Now that the Security Manager is permanently disabled, the following
> permission classes in the core libraries area can be deprecated for removal
> as they are no longer useful: FilePermission, LinkPermission,
> LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission,
> a
On Tue, 11 Mar 2025 15:15:39 GMT, Mikhail Yankelevich
wrote:
> 8351566: Consolidate third party artifacts used in tests
test/lib/jdk/test/lib/security/NSSArtifactFetcher.java line 44:
> 42: final Class nssLibClass = getNssLibClass(osId);
> 43: if(nssLibClass == null){
> 44:
On Thu, 6 Mar 2025 19:26:14 GMT, Volodymyr Paprotski
wrote:
>> Ferenc Rakoczi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Accepted review comments.
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 409:
>
>> 407: __ evmo
On Fri, 4 Apr 2025 19:00:02 GMT, Roger Riggs wrote:
>> Now that the Security Manager is permanently disabled, the following
>> permission classes in the core libraries area can be deprecated for removal
>> as they are no longer useful: FilePermission, LinkPermission,
>> LoggingPermission, Prop
On Mon, 24 Mar 2025 17:24:01 GMT, Artur Barashev wrote:
>> Currently when a signature scheme constraint is specified with
>> "jdk.tls.disabledAlgorithms" property we don't differentiate between
>> signatures used to sign a TLS handshake exchange and the signatures used in
>> TLS certificates:
On Wed, 12 Mar 2025 17:26:30 GMT, Artur Barashev wrote:
>> Currently when a signature scheme constraint is specified with
>> "jdk.tls.disabledAlgorithms" property we don't differentiate between
>> signatures used to sign a TLS handshake exchange and the signatures used in
>> TLS certificates:
> Now that the Security Manager is permanently disabled, the following
> permission classes in the core libraries area can be deprecated for removal
> as they are no longer useful: FilePermission, LinkPermission,
> LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission,
> a
On Thu, 27 Mar 2025 21:37:24 GMT, Sean Mullan wrote:
>> Hai-May Chao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix typo
>
> Marked as reviewed by mullan (Reviewer).
@seanjmullan @wangweij Thanks for the review.
-
PR
On Thu, 3 Apr 2025 00:27:50 GMT, Martin Balao wrote:
>> src/java.base/share/classes/java/security/Provider.java line 1037:
>>
>>> 1035: }
>>> 1036:
>>> 1037: if (mi.isLegacy) {
>>
>> For legacy entry, there is no check on the `legacyApiCall` value, is this
>> due to th
On Fri, 4 Apr 2025 17:50:58 GMT, Artur Barashev wrote:
>> test/jdk/sun/security/ssl/SignatureScheme/DisableSHA1inHandshakeSignatureTLS12.java
>> line 28:
>>
>>> 26: * @bug 8340321
>>> 27: * @summary Disable SHA-1 in TLS/DTLS 1.2 signatures.
>>> 28: * This test only covers TLS 1.2.
>
On Wed, 2 Apr 2025 15:58:00 GMT, Artur Barashev wrote:
>> test/jdk/sun/security/ssl/SignatureScheme/DisableSHA1inHandshakeSignatureDTLS12.java
>> line 34:
>>
>>> 32: */
>>> 33:
>>> 34: import java.lang.Override;
>>
>> You shouldn't have to import java.lang.Override
>
> Indeed, thanks! For so
> Disable SHA-1 in TLS/DTLS 1.2 handshake signatures (but not in certificate
> signatures).
> https://www.rfc-editor.org/rfc/rfc9155.html
Artur Barashev has updated the pull request incrementally with one additional
commit since the last revision:
Add TLSv1.3 unit test
-
Changes
On Fri, 4 Apr 2025 18:21:29 GMT, Roger Riggs wrote:
>> Now that the Security Manager is permanently disabled, the following
>> permission classes in the core libraries area can be deprecated for removal
>> as they are no longer useful: FilePermission, LinkPermission,
>> LoggingPermission, Prop
> This code change adds support for getting public key from an EC private key
> in PKCS #11. This is is necessary to support DHKEM for keys in SunPKCS11. The
> support is still not complete and there is no way to get the public key if
> the private key is unwrapped from an encrypted form. PKCS #
On Mon, 31 Mar 2025 14:17:50 GMT, Artur Barashev wrote:
>> Currently when a signature scheme constraint is specified with
>> "jdk.tls.disabledAlgorithms" property we don't differentiate between
>> signatures used to sign a TLS handshake exchange and the signatures used in
>> TLS certificates:
Greetings Daniel,
For the sake of discussion, I will look at these classes as classifiable
into two groups: classes that we use (or are useful) only in the context of
a security manager, and classes that we use (or are useful) independently
of any other JDK API.
I would put all three of these cla
On Fri, 4 Apr 2025 18:04:39 GMT, Sean Mullan wrote:
>> Please review this change to terminally deprecate the following security
>> related permission classes: `java.security.UnresolvedPermission`,
>> `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`,
>> `javax.security.auth.P
On Fri, 4 Apr 2025 18:04:39 GMT, Sean Mullan wrote:
>> Please review this change to terminally deprecate the following security
>> related permission classes: `java.security.UnresolvedPermission`,
>> `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`,
>> `javax.security.auth.P
On Mon, 3 Mar 2025 18:31:19 GMT, Valerie Peng wrote:
>> Francisco Ferrari Bihurriet has updated the pull request incrementally with
>> one additional commit since the last revision:
>>
>> Clear ServicesMap fields in the declared order
>>
>> Constructors assign the fields in the same orde
> The jarsigner -verify command currently performs verification by reading from
> JarFile to navigate the central directory (CEN) headers. It is now enhanced
> to include cross-validation of entries between JarFile (CEN-based) and
> JarInputStream (stream-based) representations of the JAR. It em
> Now that the Security Manager is permanently disabled, the following
> permission classes in the core libraries area can be deprecated for removal
> as they are no longer useful: FilePermission, LinkPermission,
> LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission,
> a
On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan wrote:
> Please review this change to terminally deprecate the following security
> related permission classes: `java.security.AllPermission`,
> `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`,
> `javax.security.auth.AuthPermissi
> Please review this change to terminally deprecate the following security
> related permission classes: `java.security.UnresolvedPermission`,
> `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`,
> `javax.security.auth.PrivateCredentialPermission`,
> `javax.security.auth.kerbe
On Thu, 3 Apr 2025 18:42:35 GMT, Volodymyr Paprotski
wrote:
> 8353671: Remove dead code missed in JDK-8350459
@ascarpino If you wouldn't mind, should be a quick one :)
-
PR Comment: https://git.openjdk.org/jdk/pull/24423#issuecomment-2779414600
On Fri, 4 Apr 2025 17:18:44 GMT, Sean Mullan wrote:
>> Disable SHA-1 in TLS/DTLS 1.2 handshake signatures (but not in certificate
>> signatures).
>> https://www.rfc-editor.org/rfc/rfc9155.html
>
> test/jdk/sun/security/ssl/SignatureScheme/DisableSHA1inHandshakeSignatureTLS12.java
> line 28:
>
On Fri, 4 Apr 2025 13:51:33 GMT, Sean Mullan wrote:
>> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally
>> with one additional commit since the last revision:
>>
>> 8349890:Option -Djava.security.debug=x509,ava breaks special chars
>
> test/jdk/sun/security/x509/X5
> **A DESCRIPTION OF THE PROBLEM :**
> Enabling -Djava.security.debug=x509,ava affects how special characters in
> certificates are processed. The expected behavior is that debugging should
> not interfere with the normal encoding of certificate fields.
>
> **Fix:**
> The Debugging will no longe
On Tue, 1 Apr 2025 20:53:01 GMT, Artur Barashev wrote:
> Disable SHA-1 in TLS/DTLS 1.2 handshake signatures (but not in certificate
> signatures).
> https://www.rfc-editor.org/rfc/rfc9155.html
test/jdk/sun/security/ssl/SignatureScheme/DisableSHA1inHandshakeSignatureTLS12.java
line 28:
> 26:
Please review this change to terminally deprecate the following security
related permission classes: `java.security.AllPermission`,
`java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`,
`javax.security.auth.AuthPermission`,
`javax.security.auth.PrivateCredentialPermission`,
`jav
On Fri, 4 Apr 2025 03:18:31 GMT, Koushik Muthukrishnan Thirupattur
wrote:
>> **A DESCRIPTION OF THE PROBLEM :**
>> Enabling -Djava.security.debug=x509,ava affects how special characters in
>> certificates are processed. The expected behavior is that debugging should
>> not interfere with the n
> Now that the Security Manager is permanently disabled, the following
> permission classes in the core libraries area can be deprecated for removal
> as they are no longer useful: FilePermission, LinkPermission,
> LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission,
> a
On Fri, 4 Apr 2025 14:26:30 GMT, Sean Mullan wrote:
> > Done I think: https://bugs.openjdk.org/browse/JDK-8297970
>
> Is this link correct? This issue was fixed in JDK 20.
Sorry.. copy/paste didnt notice.. https://bugs.openjdk.org/browse/JDK-8353670
(also ends in *70!)
-
PR Comme
On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan wrote:
> Please review this change to terminally deprecate the following security
> related permission classes: `java.security.AllPermission`,
> `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`,
> `javax.security.auth.AuthPermissi
On Fri, 4 Apr 2025 14:49:36 GMT, David M. Lloyd wrote:
> `AllPermission` is an integral concept of permission sets, and thus we would
> be obliged to create our own if the JDK one disappeared, causing
> compatibility problems due to the class moving to a new package from the
> point of view of
Hi David,
Are there other subclasses of Permission that this framework uses?
More specifically - would it be fine to deprecate NetPermission,
URLPermission and SocketPermission classes?
best regards,
-- daniel
On 04/04/2025 15:51, David M. Lloyd wrote:
Can you elaborate or give an example/poi
On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan wrote:
> Please review this change to terminally deprecate the following security
> related permission classes: `java.security.AllPermission`,
> `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`,
> `javax.security.auth.AuthPermissi
On Fri, 4 Apr 2025 14:35:59 GMT, Andrew Haley wrote:
>> This fix addresses a performance regression found on some aarch64
>> processors, namely the Apple M1, when we moved to a quarter round parallel
>> implementation in JDK-8349106. After making some improvements in the
>> ordering of the in
On Thu, 3 Apr 2025 18:49:24 GMT, Volodymyr Paprotski
wrote:
> Done I think: https://bugs.openjdk.org/browse/JDK-8297970
Is this link correct? This issue was fixed in JDK 20.
-
PR Comment: https://git.openjdk.org/jdk/pull/23719#issuecomment-2778889529
On Fri, 4 Apr 2025 14:12:55 GMT, Sean Mullan wrote:
> > > Please review this change to terminally deprecate the following security
> > > related permission classes: `java.security.AllPermission`,
> > > `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`,
> > > `javax.security.a
On Thu, 3 Apr 2025 16:31:39 GMT, Jamil Nimeh wrote:
> This fix addresses a performance regression found on some aarch64 processors,
> namely the Apple M1, when we moved to a quarter round parallel implementation
> in JDK-8349106. After making some improvements in the ordering of the
> instruc
On Thu, 27 Mar 2025 21:04:39 GMT, Valerie Peng wrote:
>>> Hi @valeriepeng, I found code assuming `com.sun.crypto.provider.PBEKey`
>>> contains only ASCII, please find my suggestions in the review comments. I
>>> also added a suggestion for the tests, in order to increase the coverage in
>>> th
Please review an enhancement to treat classes and interfaces that are not
included and not unconditionally exported as hidden. This means they do not
show up in the generated documentation even if they are implemented or extended
by a documented type.
This change makes the `@hidden` JavaDoc ta
On Thu, 6 Mar 2025 11:49:12 GMT, Mikhail Yankelevich
wrote:
>> Refactor the following to run fully in java:
>> test/java/security//Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh
>> test/java/security//Security/ClassLoaderDeadlock/Deadlock.sh
>
> Mikhail Yankelevich has updated the pull requ
On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan wrote:
> Please review this change to terminally deprecate the following security
> related permission classes: `java.security.AllPermission`,
> `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`,
> `javax.security.auth.AuthPermissi
On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan wrote:
> Please review this change to terminally deprecate the following security
> related permission classes: `java.security.AllPermission`,
> `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`,
> `javax.security.auth.AuthPermissi
Now that the Security Manager is permanently disabled, the following permission
classes in the core libraries area can be deprecated for removal as they are no
longer useful: FilePermission, LinkPermission, LoggingPermission,
PropertyPermission, ReflectPermission, RuntimePermission, and
Seriali
On Fri, 4 Apr 2025 12:37:32 GMT, Roger Riggs wrote:
> Now that the Security Manager is permanently disabled, the following
> permission classes in the core libraries area can be deprecated for removal
> as they are no longer useful: FilePermission, LinkPermission,
> LoggingPermission, Property
In general I don't disagree.
There is, however, at least _some_ cases where the imperative API is
less difficult to use.
In some cases you know that a class has a complex lifecycle -- perhaps
it starts off in a simple "larval" state, where the instance only exist
in a single thread.
In
62 matches
Mail list logo
