> Earlier code will trigger NPE if the certificate does not contain the
> extensions or if the requested extensions does not exist. The better approach
> for hardening **getExtensionValue** here is to to check for NULL explicitly
> before calling **getExtensionValue()** and avoding try-catch blo
On Tue, 4 Feb 2025 18:57:28 GMT, Ferenc Rakoczi wrote:
>>> @ferakocz I'm afraid you lucked out on getting your change committed before
>>> my reorganization of the stub generation code. If you are unsure of how to
>>> do the merge so your new stub is declared and generated following the new
>>
On Thu, 13 Feb 2025 16:27:03 GMT, Sean Mullan wrote:
> This change adds an API note to these methods recommending that the caller
> should perform further validation steps on the code signers that signed the
> JAR file, such as validating the code signer's certificate chain, and
> determining
On Wed, 19 Feb 2025 10:43:06 GMT, Marcono1234 wrote:
>> This change adds an API note to these methods recommending that the caller
>> should perform further validation steps on the code signers that signed the
>> JAR file, such as validating the code signer's certificate chain, and
>> determin
On Tue, 18 Feb 2025 17:44:12 GMT, Weijun Wang wrote:
> There is still one `if (info != null)` check in `getTBSCertificate()`.
>
> Also, you can combine
>
> ```
> Objects.requireNonNull(info);
> this.info = info;
> ```
>
> to
>
> ```
> this.info = Objects.requireNonNull
On Tue, 18 Feb 2025 20:34:36 GMT, Sean Mullan wrote:
> The fix needs a test or you need to add an appropriate `noreg` label to the
> JBS issue if it isn't necessary or practical for some reason.
Working on a test for it, forgot to change PR to draft, apologies.
-
PR Comment: https
> Changed `HexDumpEncoder`, so `encodeBuffer` always uses ISO_8859_1.
> This also fixes the issue with conversion in `encode` method, as the input is
> always ISO_8859_1.
Mikhail Yankelevich has updated the pull request incrementally with one
additional commit since the last revision:
tests
On Wed, 19 Feb 2025 10:27:26 GMT, Konanki Sreenath wrote:
>> Earlier code will trigger NPE if the certificate does not contain the
>> extensions or if the requested extensions does not exist. The better
>> approach for hardening **getExtensionValue** here is to to check for NULL
>> explicitly
On Wed, 19 Feb 2025 14:48:56 GMT, Konanki Sreenath wrote:
>> Earlier code will trigger NPE if the certificate does not contain the
>> extensions or if the requested extensions does not exist. The better
>> approach for hardening **getExtensionValue** here is to to check for NULL
>> explicitly
On Thu, 13 Feb 2025 16:27:03 GMT, Sean Mullan wrote:
> This change adds an API note to these methods recommending that the caller
> should perform further validation steps on the code signers that signed the
> JAR file, such as validating the code signer's certificate chain, and
> determining
> 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:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3
On Mon, 27 Jan 2025 12:39:45 GMT, Konanki Sreenath wrote:
> Earlier code will trigger NPE if the certificate does not contain the
> extensions or if the requested extensions does not exist. The better approach
> for hardening **getExtensionValue** here is to to check for NULL explicitly
> befo
On Wed, 19 Feb 2025 13:42:38 GMT, Mikhail Yankelevich wrote:
>> Changed `HexDumpEncoder`, so `encodeBuffer` always uses ISO_8859_1.
>> This also fixes the issue with conversion in `encode` method, as the input
>> is always ISO_8859_1.
>
> Mikhail Yankelevich has updated the pull request increme
> This updates the OpenSSL version that is used by test
> `sun/security/pkcs12/KeytoolOpensslInteropTest.java` to the current LTS
> version (3.0 series).
> There are some differences between the 1.1.x and the current OpenSSL version:
> - RC4 is not longer enabled by default, therefore adding the
On Wed, 19 Feb 2025 16:52:36 GMT, Weijun Wang wrote:
>> Mikhail Yankelevich has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> tests added
>
> test/jdk/sun/security/util/HexDumpEncoderTests.java line 101:
>
>> 99: public static voi
On Tue, 18 Feb 2025 17:52:14 GMT, Rajan Halade wrote:
>> Fernando Guallini has updated the pull request with a new target base due to
>> a merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains eight additional
>> c
> Changed `HexDumpEncoder`, so `encodeBuffer` always uses ISO_8859_1.
> This also fixes the issue with conversion in `encode` method, as the input is
> always ISO_8859_1.
Mikhail Yankelevich has updated the pull request incrementally with one
additional commit since the last revision:
change
On Wed, 19 Feb 2025 17:04:15 GMT, Mikhail Yankelevich wrote:
>> test/jdk/sun/security/util/HexDumpEncoderTests.java line 101:
>>
>>> 99: public static void main(String[] args) throws Exception {
>>> 100:
>>> 101: try (final FileInputStream fis = new
>>> FileInputStream(args
> Changed `HexDumpEncoder`, so `encodeBuffer` always uses ISO_8859_1.
> This also fixes the issue with conversion in `encode` method, as the input is
> always ISO_8859_1.
Mikhail Yankelevich has updated the pull request incrementally with one
additional commit since the last revision:
import
On Wed, 19 Feb 2025 14:48:56 GMT, Konanki Sreenath wrote:
>> Earlier code will trigger NPE if the certificate does not contain the
>> extensions or if the requested extensions does not exist. The better
>> approach for hardening **getExtensionValue** here is to to check for NULL
>> explicitly
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 show how
the method can be used to create various certificates. I attach
On Mon, 20 Jan 2025 16:20:27 GMT, Fernando Guallini
wrote:
> The test javax/crypto/CryptoPermissions/InconsistentEntries.java should not
> modify the JDK home directory under test as that could impact the results of
> other tests, or it could fail if the JDK home dir is read-only.
>
> This PR
On Wed, 19 Feb 2025 14:48:56 GMT, Konanki Sreenath wrote:
>> Earlier code will trigger NPE if the certificate does not contain the
>> extensions or if the requested extensions does not exist. The better
>> approach for hardening **getExtensionValue** here is to to check for NULL
>> explicitly
> Earlier code will trigger NPE if the certificate does not contain the
> extensions or if the requested extensions does not exist. The better approach
> for hardening **getExtensionValue** here is to to check for NULL explicitly
> before calling **getExtensionValue()** and avoding try-catch blo
On Wed, 19 Feb 2025 18:56:40 GMT, Mikhail Yankelevich wrote:
>> Changed `HexDumpEncoder`, so `encodeBuffer` always uses ISO_8859_1.
>> This also fixes the issue with conversion in `encode` method, as the input
>> is always ISO_8859_1.
>
> Mikhail Yankelevich has updated the pull request increme
> [JDK-8267068](https://bugs.openjdk.org/browse/JDK-8267068)
Mark Powers has updated the pull request incrementally with one additional
commit since the last revision:
review comments from Valerie and Sean
-
Changes:
- all: https://git.openjdk.org/jdk/pull/23188/files
- new:
On Thu, 13 Feb 2025 08:35:47 GMT, Nicole Xu wrote:
> As is suggested in
> [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should
> be used consistently in microbenchmarks to 'align with the intuition that
> when you use jvmArgsAppend/-Prepend intent is to add to a set of
On Thu, 13 Feb 2025 22:29:46 GMT, Jamil Nimeh wrote:
>> Also, should it be moved to somewhere else like
>> jdk/test/sun/security/provider/certpath?
>
>> Also, should it be moved to somewhere else like
>> jdk/test/sun/security/provider/certpath?
>
> Hmmm...not sure about that, but maybe an exp
On Fri, 14 Feb 2025 19:16:41 GMT, Weijun Wang wrote:
> Also, now we have the same content in 3 places:
>
> 1. Here
>
> 2. In the Security Guide at
> https://docs.oracle.com/en/java/javase/23/security/troubleshooting-security.html#GUID-05F3E865-20FF-46EB-AC35-84D4B552CA48
>
> 3. At
On Fri, 14 Feb 2025 19:12:51 GMT, Koushik Muthukrishnan Thirupattur
wrote:
>> java.security.debug is a widely used debug system property for JDK security
>> libs. It's time to capture details about this property via javadoc.
>>
>> ![image](https://github.com/user-attachments/assets/2c58dd82-36
> This fix makes some minor changes to the internals of the
> `CertificateBuilder` and `SimpleOCSPServer` test classes. They would break
> when ML-DSA was selected as key and signing algorithms. Also RSASSA-PSS
> works better now with these changes. I've also taken this opportunity to do
> s
On Mon, 17 Feb 2025 11:40:59 GMT, Mikhail Yankelevich wrote:
> Changed `HexDumpEncoder`, so `encodeBuffer` always uses ISO_8859_1.
> This also fixes the issue with conversion in `encode` method, as the input is
> always ISO_8859_1.
This pull request has now been integrated.
Changeset: 7734f8e
On Wed, 19 Feb 2025 17:21:10 GMT, Mikhail Yankelevich wrote:
>> Changed `HexDumpEncoder`, so `encodeBuffer` always uses ISO_8859_1.
>> This also fixes the issue with conversion in `encode` method, as the input
>> is always ISO_8859_1.
>
> Mikhail Yankelevich has updated the pull request increme
On Fri, 14 Feb 2025 19:15:21 GMT, Weijun Wang wrote:
> The name and title should not be "Security Properties". This is about the
> debug system property.
Yes, this is because "Security Properties" are different than system
properties, and are listed in the `java.security` file. We may want to
On Mon, 3 Feb 2025 19:26:27 GMT, Ben Perez wrote:
>> 8261513: Various BasicConstraintsExtension issues
>
> Ben Perez has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webrev excludes the unrelated changes brought in
> by the merge/rebase. The pull
On Fri, 14 Feb 2025 18:44:38 GMT, Anthony Scarpino
wrote:
> Hi,
>
> I need a review for the following change. Naming conventions for EdDSA and
> XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator.
> These internal changes help make it more consistent when parsing the act
On Wed, 19 Feb 2025 22:50:40 GMT, Sean Mullan wrote:
>> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally
>> with one additional commit since the last revision:
>>
>> 8328914: Document the java.security.debug property in javadoc
>
> src/java.base/share/classes/java/
> Changed `HexDumpEncoder`, so `encodeBuffer` always uses ISO_8859_1.
> This also fixes the issue with conversion in `encode` method, as the input is
> always ISO_8859_1.
Mikhail Yankelevich has updated the pull request incrementally with one
additional commit since the last revision:
import
> [JDK-8267068](https://bugs.openjdk.org/browse/JDK-8267068)
Mark Powers has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains three commits:
- Merge master
- review comments from Valerie and Sean
- first iteration
-
Change
On Wed, 19 Feb 2025 21:19:22 GMT, Artur Barashev wrote:
>> Hi,
>>
>> I need a review for the following change. Naming conventions for EdDSA and
>> XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator.
>> These internal changes help make it more consistent when parsing the a
On Wed, 19 Feb 2025 21:31:08 GMT, Artur Barashev wrote:
>> Hi,
>>
>> I need a review for the following change. Naming conventions for EdDSA and
>> XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator.
>> These internal changes help make it more consistent when parsing the a
On Wed, 19 Feb 2025 22:39:21 GMT, Sean Mullan wrote:
> > Also, now we have the same content in 3 places:
> > ```
> > 1. Here
> >
> > 2. In the Security Guide at
> > https://docs.oracle.com/en/java/javase/23/security/troubleshooting-security.html#GUID-05F3E865-20FF-46EB-AC35-84D4B552CA48
> >
>
> I need a review of this change that adds new timing controls for the initial
> server setup. On rare occasions, more so on certain architectures, the
> server may not fully start before the client tries to connect. Additional
> debugging is added to help identify if there are other timing is
On Fri, 14 Feb 2025 18:44:38 GMT, Anthony Scarpino
wrote:
> Hi,
>
> I need a review for the following change. Naming conventions for EdDSA and
> XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator.
> These internal changes help make it more consistent when parsing the act
On Thu, 13 Feb 2025 18:43:01 GMT, Daniel Jeliński wrote:
>> Ah ok. So I assume TLS 1.3 is using a different code path or KDF.
>
> TLS 1.3 uses HKDF, and doesn't work with SunPKCS11 yet, see
> [JDK-8278640](https://bugs.openjdk.org/browse/JDK-8278640)
I'd like to clarify the usage of `SunTlsKeyM
On Thu, 13 Feb 2025 20:04:05 GMT, Chen Liang wrote:
>> As is suggested in
>> [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should
>> be used consistently in microbenchmarks to 'align with the intuition that
>> when you use jvmArgsAppend/-Prepend intent is to add to a se
On Thu, 13 Feb 2025 08:35:47 GMT, Nicole Xu wrote:
> As is suggested in
> [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should
> be used consistently in microbenchmarks to 'align with the intuition that
> when you use jvmArgsAppend/-Prepend intent is to add to a set of
On Thu, 13 Feb 2025 08:35:47 GMT, Nicole Xu wrote:
> As is suggested in
> [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should
> be used consistently in microbenchmarks to 'align with the intuition that
> when you use jvmArgsAppend/-Prepend intent is to add to a set of
On Thu, 13 Feb 2025 08:35:47 GMT, Nicole Xu wrote:
> As is suggested in
> [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should
> be used consistently in microbenchmarks to 'align with the intuition that
> when you use jvmArgsAppend/-Prepend intent is to add to a set of
On Wed, 19 Feb 2025 23:27:19 GMT, Koushik Muthukrishnan Thirupattur
wrote:
>> java.security.debug is a widely used debug system property for JDK security
>> libs. It's time to capture details about this property via javadoc.
>>
>> , `jvmArgs` should
> be used consistently in microbenchmarks to 'align with the intuition that
> when you use jvmArgsAppend/-Prepend intent is to add to a set of
On Wed, 19 Feb 2025 17:21:10 GMT, Mikhail Yankelevich wrote:
>> Changed `HexDumpEncoder`, so `encodeBuffer` always uses ISO_8859_1.
>> This also fixes the issue with conversion in `encode` method, as the input
>> is always ISO_8859_1.
>
> Mikhail Yankelevich has updated the pull request increme
> java.security.debug is a widely used debug system property for JDK security
> libs. It's time to capture details about this property via javadoc.
>
> 
>
> NOTE : We are adding a new html file (similar to t
53 matches
Mail list logo
