On Fri, 27 Aug 2021 19:47:30 GMT, Weijun Wang wrote:
> A one slot ccache is added to avoid multiple authentication from the same
> principal.
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.java.net/jdk/pull/5286
On Fri, 22 Oct 2021 22:00:57 GMT, Bernd wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> renames
>
> src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Util.java
> line 107:
>
>> 105: */
>> 106:
On Sat, 23 Oct 2021 00:40:39 GMT, Weijun Wang wrote:
>> New `Subject` APIs `current()` and `callAs()` are created to be replacements
>> of `getSubject()` and `doAs()` since the latter two methods are now
>> deprecated for removal.
>>
>> In this implementation, by default, `current()` returns
On Fri, 22 Oct 2021 23:50:38 GMT, Anthony Scarpino
wrote:
> Hi,
>
> I need a review of this change. It makes KeyPair implement Destroyable and
> implements the methods to call the underlying privateKey. It also sets the
> public and private key to 'final'.
>
> The bug includes a CSR and
On Fri, 22 Oct 2021 23:50:38 GMT, Anthony Scarpino
wrote:
> Hi,
>
> I need a review of this change. It makes KeyPair implement Destroyable and
> implements the methods to call the underlying privateKey. It also sets the
> public and private key to 'final'.
>
> The bug includes a CSR and
On Fri, 22 Oct 2021 23:50:38 GMT, Anthony Scarpino
wrote:
> Hi,
>
> I need a review of this change. It makes KeyPair implement Destroyable and
> implements the methods to call the underlying privateKey. It also sets the
> public and private key to 'final'.
>
> The bug includes a CSR and
On Fri, 22 Oct 2021 23:50:38 GMT, Anthony Scarpino
wrote:
> Hi,
>
> I need a review of this change. It makes KeyPair implement Destroyable and
> implements the methods to call the underlying privateKey. It also sets the
> public and private key to 'final'.
>
> The bug includes a CSR and
> New `Subject` APIs `current()` and `callAs()` are created to be replacements
> of `getSubject()` and `doAs()` since the latter two methods are now
> deprecated for removal.
>
> In this implementation, by default, `current()` returns the same value as
>
Hi,
I need a review of this change. It makes KeyPair implement Destroyable and
implements the methods to call the underlying privateKey. It also sets the
public and private key to 'final'.
The bug includes a CSR and Release Notes
CSR: https://bugs.openjdk.java.net/browse/JDK-8275823
RN:
On Fri, 22 Oct 2021 19:25:38 GMT, Daniel Jeliński wrote:
>> The current code that changes cipher suites disposes the new suite instead
>> of the old one, which usually silently fails. This patch fixes the code to
>> dispose the old instance instead.
>>
>> DTLS appears to be unaffected:
On Thu, 5 Aug 2021 20:10:44 GMT, Weijun Wang wrote:
> New `Subject` APIs `current()` and `callAs()` are created to be replacements
> of `getSubject()` and `doAs()` since the latter two methods are now
> deprecated for removal.
>
> In this implementation, by default, `current()` returns the
On Thu, 14 Oct 2021 16:04:08 GMT, Hai-May Chao wrote:
> It'd be useful to have a -version option for keytool and jarsigner. Many
> other JDK tools already have a -version option. This is to add -version
> option to keytool and jarsigner like jar command does.
>
> CSR review:
>
On Fri, 22 Oct 2021 18:45:31 GMT, Alexey Bakhtin wrote:
>> Hello,
>>
>> Could you please review the small patch for the issue described in
>> JDK-8271199: Mutual TLS handshake fails signing client certificate with
>> custom sensitive PKCS11 key
>>
>> I suggest updating the
On Fri, 22 Oct 2021 18:45:31 GMT, Xue-Lei Andrew Fan wrote:
>> The current code that changes cipher suites disposes the new suite instead
>> of the old one, which usually silently fails. This patch fixes the code to
>> dispose the old instance instead.
>>
>> DTLS appears to be unaffected:
On Fri, 22 Oct 2021 19:25:38 GMT, Daniel Jeliński wrote:
>> The current code that changes cipher suites disposes the new suite instead
>> of the old one, which usually silently fails. This patch fixes the code to
>> dispose the old instance instead.
>>
>> DTLS appears to be unaffected:
> The current code that changes cipher suites disposes the new suite instead of
> the old one, which usually silently fails. This patch fixes the code to
> dispose the old instance instead.
>
> DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly
> [disposes the old
>
On Fri, 22 Oct 2021 18:24:22 GMT, Daniel Jeliński wrote:
> The current code that changes cipher suites disposes the new suite instead of
> the old one, which usually silently fails. This patch fixes the code to
> dispose the old instance instead.
>
> DTLS appears to be unaffected:
On Fri, 22 Oct 2021 17:24:36 GMT, Valerie Peng wrote:
> Changes look fine. Have you run through all security regression tests besides
> those under sun/security/rsa?
Hi @valeriepeng,
Yes, I've run this code with all security tests. Passed successfully.
-
PR:
On Fri, 22 Oct 2021 18:45:31 GMT, Alexey Bakhtin wrote:
>> Hello,
>>
>> Could you please review the small patch for the issue described in
>> JDK-8271199: Mutual TLS handshake fails signing client certificate with
>> custom sensitive PKCS11 key
>>
>> I suggest updating the
On Fri, 22 Oct 2021 18:24:22 GMT, Daniel Jeliński wrote:
> The current code that changes cipher suites disposes the new suite instead of
> the old one, which usually silently fails. This patch fixes the code to
> dispose the old instance instead.
>
> DTLS appears to be unaffected:
On Thu, 21 Oct 2021 19:16:34 GMT, Alexey Bakhtin wrote:
>> Hello,
>>
>> Could you please review the small patch for the issue described in
>> JDK-8271199: Mutual TLS handshake fails signing client certificate with
>> custom sensitive PKCS11 key
>>
>> I suggest updating the
> Hello,
>
> Could you please review the small patch for the issue described in
> JDK-8271199: Mutual TLS handshake fails signing client certificate with
> custom sensitive PKCS11 key
>
> I suggest updating the RSAPSSSignature.isValid() method to verify if provided
> key components can be
Thanks Xuelei for the JBS ticket and the hint. PR is on its way.
Regards,
Daniel
pt., 22 paź 2021 o 19:28 Xuelei Fan napisał(a):
>
> Hi Daniel,
>
> Thank you for the nice catch! I filed a JBS bug:
> https://bugs.openjdk.java.net/browse/JDK-8275811
>
> It would be nice if you could also
The current code that changes cipher suites disposes the new suite instead of
the old one, which usually silently fails. This patch fixes the code to dispose
the old instance instead.
DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly
[disposes the old
On Thu, 21 Oct 2021 19:16:34 GMT, Alexey Bakhtin wrote:
>> Hello,
>>
>> Could you please review the small patch for the issue described in
>> JDK-8271199: Mutual TLS handshake fails signing client certificate with
>> custom sensitive PKCS11 key
>>
>> I suggest updating the
I would like to point your attention to this issue
https://github.com/openjdk/jdk/pull/5123
Simple 2 compiler warnings / errors because -Werror when building
openjdk in slowdebug mode and a simple fix.
--
Marián Konček
Hi Daniel,
Thank you for the nice catch! I filed a JBS bug:
https://bugs.openjdk.java.net/browse/JDK-8275811
It would be nice if you could also update similar issues in (DTLS)OutRecord
files.
Thanks,
Xuelei
On Oct 22, 2021, at 8:14 AM, Daniel Jeliński
mailto:djelins...@gmail.com>>
On Thu, 21 Oct 2021 19:16:34 GMT, Alexey Bakhtin wrote:
>> Hello,
>>
>> Could you please review the small patch for the issue described in
>> JDK-8271199: Mutual TLS handshake fails signing client certificate with
>> custom sensitive PKCS11 key
>>
>> I suggest updating the
Apoligies, the Java kinit run was not performed with the correct
krb5.conf. I have now repeated with the proper one and the stacktrace
fits the code and my analysis now:
C:\Users\osipovmi>kinit osipo...@ad001.siemens.net
Picked up _JAVA_OPTIONS: -Dsun.security.krb5.debug=false
On Wed, 20 Oct 2021 15:41:35 GMT, Daniel Fuchs wrote:
>> Aleksei Efimov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Change InetAddressResolver method names
>
> Marked as reviewed by dfuchs (Reviewer).
@dfuch @AlanBateman
Hi all,
During routine examination of thread dumps I noticed a stack trace you
may find interesting. Relevant part:
java.lang.Thread.State: RUNNABLE
...
at java.lang.IllegalStateException.(java.base@11.0.11/Unknown Source)
at javax.crypto.Cipher.checkCipherState(java.base@11.0.11/Unknown
> This change implements a new service provider interface for host name and
> address resolution, so that java.net.InetAddress API can make use of
> resolvers other than the platform's built-in resolver.
>
> The following API classes are added to `java.net.spi` package to facilitate
> this:
>
Am 2021-10-21 um 21:38 schrieb Wei-Jun Wang:
KrbKdcReq throws the exception on line 55, so it is the previous check
if (isAsReq && !req.reqBody.cname.equals(rep.cname) &&
((!req.reqBody.kdcOptions.get(KDCOptions.CANONICALIZE) &&
33 matches
Mail list logo
