Re: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic [v6]

2024-05-06 Thread Volodymyr Paprotski
> Performance. Before: > > Benchmark(algorithm) (dataSize) (keyLength) > (provider) Mode Cnt ScoreError Units > SignatureBench.ECDSA.signSHA256withECDSA1024 256 > thrpt3 6443.934 ± 6.491 ops/s > SignatureBench.ECDSA.

Re: RFR: 8330278: Have SSLSocketTemplate.doClientSide use loopback address

2024-05-06 Thread Rajan Halade
On Fri, 3 May 2024 11:22:51 GMT, Sean Coffey wrote: > Using the loopback address by default may prove more reliable for some test > configurations > > ran all jdk_security tests. no issues seen. Marked as reviewed by rhalade (Reviewer). - PR Review: https://git.openjdk.org/jdk/pu

Re: [Bug] javax.security.auth.kerberos.KeyTab returns unrequested keys

2024-05-06 Thread Wei-Jun Wang
I'll probably pick #2 if you also like it. > On May 6, 2024, at 3:59 PM, Osipov, Michael (IN IT IN) > wrote: > > On 2024-05-06 21:55, Wei-Jun Wang wrote: >> Hi Michael, >> Thanks for the report. It seems not conforming to the RFC strictly >> but I hesitate to make a change now. >> The getKeys()

Re: [Bug] javax.security.auth.kerberos.KeyTab returns unrequested keys

2024-05-06 Thread Osipov, Michael (IN IT IN)
On 2024-05-06 21:55, Wei-Jun Wang wrote: Hi Michael, Thanks for the report. It seems not conforming to the RFC strictly but I hesitate to make a change now. The getKeys() method uses the PrincipalName.match() method to compare principal names in case-insensitive style. The same method is also u

Re: [Bug] javax.security.auth.kerberos.KeyTab returns unrequested keys

2024-05-06 Thread Wei-Jun Wang
Hi Michael, Thanks for the report. It seems not conforming to the RFC strictly but I hesitate to make a change now. The getKeys() method uses the PrincipalName.match() method to compare principal names in case-insensitive style. The same method is also used to locate a ticket from a ccache fil

Re: Canonical/portable way to obtain long term key for a GSS security context (acceptor side)

2024-05-06 Thread Wei-Jun Wang
> On May 6, 2024, at 2:55 PM, Osipov, Michael (IN IT IN) > wrote: > > Hi Weijun, > > On 2024-05-06 20:51, Wei-Jun Wang wrote: >> Hi Michael, >> I see you've just reported a bug on KeyTab. Is that your latest workaround >> to the request here? That's also the only one I can think of now. > >

Re: Canonical/portable way to obtain long term key for a GSS security context (acceptor side)

2024-05-06 Thread Osipov, Michael (IN IT IN)
Hi Weijun, On 2024-05-06 20:51, Wei-Jun Wang wrote: Hi Michael, I see you've just reported a bug on KeyTab. Is that your latest workaround to the request here? That's also the only one I can think of now. The bug is unrelated. I just noticed it when working on the issue. BTW, when you said

Re: Canonical/portable way to obtain long term key for a GSS security context (acceptor side)

2024-05-06 Thread Wei-Jun Wang
Hi Michael, I see you've just reported a bug on KeyTab. Is that your latest workaround to the request here? That's also the only one I can think of now. BTW, when you said "disjoint to the security context", the long term key of the server *is* not related to any context. Thanks, Weijun > On

[Bug] javax.security.auth.kerberos.KeyTab returns unrequested keys

2024-05-06 Thread Osipov, Michael (IN IT IN)
Folks, consider the following code: KeyTab keytab = KeyTab.getUnboundInstance(new File("...")); KerberosPrincipal principal = new KerberosPrincipal("foo$", KerberosPrincipal.KRB_NT_PRINCIPAL); KerberosKey[] keys = keytab.getKeys(principal); Let's check the keytab for etype 18 only: 10 2022

Re: Canonical/portable way to obtain long term key for a GSS security context (acceptor side)

2024-05-06 Thread Osipov, Michael (IN IT IN)
On 2024-05-06 16:32, Osipov, Michael (IN IT IN) wrote: Folks, I have a GSS security context established and need to calculate a signature on data received form the client. The client submits me a forwarded signature calculated by the KDC (Active Directory) with the server's long term key from

Canonical/portable way to obtain long term key for a GSS security context (acceptor side)

2024-05-06 Thread Osipov, Michael (IN IT IN)
Folks, I have a GSS security context established and need to calculate a signature on data received form the client. The client submits me a forwarded signature calculated by the KDC (Active Directory) with the server's long term key from the keytab. As far as I can see ExtendedGSSContext only

Integrated: 8328501: Incorrect `@since` tags for java security interfaces

2024-05-06 Thread Nizar Benalla
On Tue, 19 Mar 2024 11:15:56 GMT, Nizar Benalla wrote: > For context, I am writing tests to check for accurate use of `@since` tags in > documentation comments in source code. > We're following these rules for now: > > ### Rule 1: Introduction of New Elements > > - If an element is new in JDK

Re: RFR: 8328501: Incorrect `@since` tags for java security interfaces [v7]

2024-05-06 Thread Nizar Benalla
> For context, I am writing tests to check for accurate use of `@since` tags in > documentation comments in source code. > We're following these rules for now: > > ### Rule 1: Introduction of New Elements > > - If an element is new in JDK N, with no equivalent in JDK N-1, it must > include `@si

Re: RFR: 8328501: Incorrect `@since` tags for java security interfaces [v6]

2024-05-06 Thread Nizar Benalla
> For context, I am writing tests to check for accurate use of `@since` tags in > documentation comments in source code. > We're following these rules for now: > > ### Rule 1: Introduction of New Elements > > - If an element is new in JDK N, with no equivalent in JDK N-1, it must > include `@si

Re: RFR: 8330954: Fix remaining `@since` tags in `java.base` [v2]

2024-05-06 Thread Nizar Benalla
> Please review this PR that aims to add all the remaining needed `@since` tags > in `java.base`, and group them into a single fix. > This is related to #18934 and my work around the `@since` checker feature. > Explicit `@since` tags are needed for some overriding methods for the purpose > of the