> **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
I think it would be useful to configure the JVM to prevent loading of
untrusted (unsigned) code. This might be useful in preventing
injection attacks, where the attacker is attempting to have the JVM load
remote untrusted code.
--
Regards,
Peter
On 4/04/2025 3:45 am, Scott Lewis wrote:
On 4/3/2025 8:20 AM, Sean Mullan wrote:
On 3/13/25 3:44 PM, Scott Lewis wrote:
But from the point of view of the OSGi framework implementation (for
example), has there been any discussion to alternatives to leaving
SSLContext.setDefault open to all code at all times? e.g.
deprecation of pub
Since the new Paradigma here is, that all Java Code needs to be trusted I guess there is less and less investive to get rid of those global statics. But besides the issue of Integration multiple codebases there is also a question of features - for example how to configure TLS features based on the
On Thu, 3 Apr 2025 18:42:35 GMT, Volodymyr Paprotski
wrote:
> 8353671: Remove dead code missed in JDK-8350459
Marked as reviewed by sviswanathan (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/24423#pullrequestreview-2741373475
> Hi, this pull request implements the fixes for bugs and inconsistencies
> described in [JDK-8345139](https://bugs.openjdk.org/browse/JDK-8345139 "Fix
> bugs and inconsistencies in the Provider services map").
>
> New services map design
>
> Here is the high-level hierarchy of the new ser
On Fri, 28 Mar 2025 20:10:42 GMT, Volodymyr Paprotski
wrote:
>> src/java.base/share/classes/sun/security/util/math/intpoly/MontgomeryIntegerPolynomialP256.java
>> line 164:
>>
>>> 162: protected void mult(long[] a, long[] b, long[] r) {
>>> 163: multImpl(a, b, r);
>>> 164:
On Tue, 1 Apr 2025 16:54:25 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
On Tue, 18 Mar 2025 14:58:51 GMT, Matthew Donovan wrote:
>> This PR updates the CertificateBuilder with a new method that creates a new
>> instance with common fields (subject name, public key, serial number,
>> validity, and key uses) filled-in. One test, IPIdentities.java, is updated
>> to s
8353671: Remove dead code missed in JDK-8350459
-
Commit messages:
- remove dead code
Changes: https://git.openjdk.org/jdk/pull/24423/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24423&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8353671
Stats: 23 lines in 1 f
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 Mon, 31 Mar 2025 19:57:59 GMT, Sean Mullan wrote:
> > > I think it would also be useful to write a release note describing the
> > > approximate performance improvement gains for the crypto algorithms as
> > > displayed in your chart. Thanks.
> >
> >
> > @seanjmullan I think I only done th
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
instructions in the 20-round loop we found that going back to a block
On 3/13/25 3:44 PM, Scott Lewis wrote:
But from the point of view of the OSGi framework implementation (for
example), has there been any discussion to alternatives to leaving
SSLContext.setDefault open to all code at all times? e.g. deprecation
of public static setDefault, or changing the s
On Tue, 4 Mar 2025 12:53:16 GMT, Matthew Donovan wrote:
> In this PR I removed TEST.properties files that disabled smart action tags.
> It is safe to remove the entire file: the smart action tags was the only
> directive in them. I verified the affected tests pass successfully.
Marked as revie
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
16 matches
Mail list logo
