On Thu, 10 Feb 2022 14:39:50 GMT, Martin Bonato wrote:
>> Alexey Bakhtin has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Simplified isPrivateKeyValid
>
> Is there any chance to get this back-ported to 11u?
On Thu, 10 Feb 2022 18:19:41 GMT, Alexey Bakhtin wrote:
> Please review the patch for the JDK-8274524
>
> SSLSocket.close() could cause an intermittent hang of the socket read
> operation. It happens in case of SO_TIMEOUT is set to 0 (infinite timeout).
> SSLSocket.close()
> This is a second iteration of review. Previous PR was closed without
> integration: https://github.com/openjdk/jdk/pull/5760
Alexey Bakhtin has updated the pull request incrementally with one additional
commit since the last revision:
Change read timeout value for skip
On Fri, 11 Feb 2022 18:04:35 GMT, Xue-Lei Andrew Fan wrote:
>> Hi @XueleiFan,
>> Not quite sure What could be wrong with setting SO_TIMEOUT during the
>> socketClose() operation. We still close the socket and SO_TIMEOUT will be
>> restored just after skip() operation is completed. These changes
On Thu, 10 Feb 2022 23:59:40 GMT, Xue-Lei Andrew Fan wrote:
>> Please review the patch for the JDK-8274524
>>
>> SSLSocket.close() could cause an intermittent hang of the socket read
>> operation. It happens in case of SO_TIMEOUT is set to 0 (infinite timeout).
>> SSLSocket.close() reads from t
Please review the patch for the JDK-8274524
SSLSocket.close() could cause an intermittent hang of the socket read
operation. It happens in case of SO_TIMEOUT is set to 0 (infinite timeout).
SSLSocket.close() reads from the socket as part of the skip() operation to
prevent TCP Connection reset (s
On Wed, 9 Feb 2022 22:09:40 GMT, Xue-Lei Andrew Fan wrote:
>> Alexey Bakhtin has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix jcheck issues
>
> With the patch, the readLock is placed in handshakeLock, an
On Fri, 3 Dec 2021 06:14:49 GMT, Sibabrata Sahoo wrote:
>> This Test gets timeout during low cpu availability. It is modified to
>> support extended timeout period during JTREG execution.
>
> Sibabrata Sahoo has updated the pull request incrementally with one
> additional commit since the last
On Wed, 1 Dec 2021 19:29:36 GMT, Sibabrata Sahoo wrote:
>> Can you lower the `threadsFactor` or `duration`? Or set an upper limit for
>> `nTasks`?
>
>> Can you lower the `threadsFactor` or `duration`? Or set an upper limit for
>> `nTasks`?
>
> I can reduce the threadFactor and duration to clos
On Wed, 10 Nov 2021 17:28:18 GMT, Xue-Lei Andrew Fan wrote:
> Did you have a chance to analysis the potential deadlock issues between
> handshake lock, read lock, write lock and socket lock? The locks used in
> SSLSocketImpl is complicated. If I remember correctly, there are potential
> deadlo
On Wed, 3 Nov 2021 17:02:40 GMT, Alexey Bakhtin wrote:
>> Please review the patch for JDK-8274524
>>
>> The fix just adds locks around InputStream read and skip operations to
>> prevent concurrent read from socket.
>> sun/security/ssl jtreg tests passed
> Please review the patch for JDK-8274524
>
> The fix just adds locks around InputStream read and skip operations to
> prevent concurrent read from socket.
> sun/security/ssl jtreg tests passed
> api/javax_net/ssl/SSLSocket/setUseClientMode jck test passed
Alexey Bakhtin ha
> Please review the patch for JDK-8274524
>
> The fix just adds locks around InputStream read and skip operations to
> prevent concurrent read from socket.
> sun/security/ssl jtreg tests passed
> api/javax_net/ssl/SSLSocket/setUseClientMode jck test passed
Alexey Bakhtin ha
On Wed, 3 Nov 2021 16:46:49 GMT, Alexey Bakhtin wrote:
>> Please review the patch for JDK-8274524
>>
>> The fix just adds locks around InputStream read and skip operations to
>> prevent concurrent read from socket.
>> sun/security/ssl jtreg tests passed
On Fri, 23 Jul 2021 10:33:14 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 RS
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
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: https://git.openjdk.ja
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
t; key components can be applied to SunRSASign implementation.
> If not applied, implementation can try to select signer from other providers
>
> Regards
> Alexey
Alexey Bakhtin has updated the pull request incrementally with one additional
commit since the last revis
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
t; key components can be applied to SunRSASign implementation.
> If not applied, implementation can try to select signer from other providers
>
> Regards
> Alexey
Alexey Bakhtin has updated the pull request incrementally with one additional
commit since the last re
On Wed, 20 Oct 2021 17:22:38 GMT, Xue-Lei Andrew Fan wrote:
>> Alexey Bakhtin has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Refactoring isValid() for private and public keys
>
> It's a good
t; key components can be applied to SunRSASign implementation.
> If not applied, implementation can try to select signer from other providers
>
> Regards
> Alexey
Alexey Bakhtin has updated the pull request incrementally with one additional
commit since the last revision:
Refactor
On Sun, 3 Oct 2021 09:11:40 GMT, BenEfrati
wrote:
> Is this fix is planned for OpenJDK 8u312?
Hi @BenEfrati, No chance to go to OpenJDK 8u312. Maybe 8u322 if it will be
approved
-
PR: https://git.openjdk.java.net/jdk/pull/4887
On Thu, 30 Sep 2021 23:04:20 GMT, Clive Verghese wrote:
> Hi @alexeybakhtin,
>
> Thank you for the PR.
>
> I have a question regarding the lock, Would adding a
> `appInput.readLock.lock()` in `SSLSocketImpl:decode(ByteBuffer)` resolve this
> issue?
Hi Clive,
Thank you for your review. I thin
> Please review the patch for JDK-8274524
>
> The fix just adds locks around InputStream read and skip operations to
> prevent concurrent read from socket.
> sun/security/ssl jtreg tests passed
> api/javax_net/ssl/SSLSocket/setUseClientMode jck test passed
Alexey Bakhtin ha
Please review the patch for JDK-8274524
The fix just adds locks around InputStream read and skip operations to prevent
concurrent read from socket.
sun/security/ssl jtreg tests passed
api/javax_net/ssl/SSLSocket/setUseClientMode jck test passed
-
Commit messages:
- 8274524: SSLSock
On Thu, 23 Sep 2021 16:52:07 GMT, Alexey Bakhtin wrote:
> The code change handles KDC_ERR_SVC_UNAVAILABLE error code (29) received from
> KDC and resends the initial request to the next KDC in the list. It aligns
> error code handling with the MIT Kerberos implementation.
> sun/s
On Thu, 23 Sep 2021 19:31:32 GMT, Weijun Wang wrote:
>> The code change handles KDC_ERR_SVC_UNAVAILABLE error code (29) received
>> from KDC and resends the initial request to the next KDC in the list. It
>> aligns error code handling with the MIT Kerberos implementation.
>> sun/security/krb5 t
> The code change handles KDC_ERR_SVC_UNAVAILABLE error code (29) received from
> KDC and resends the initial request to the next KDC in the list. It aligns
> error code handling with the MIT Kerberos implementation.
> sun/security/krb5 tests passed
Alexey Bakhtin has updated the
The code change handles KDC_ERR_SVC_UNAVAILABLE error code (29) received from
KDC and resends the initial request to the next KDC in the list. It aligns
error code handling with the MIT Kerberos implementation.
sun/security/krb5 tests passed
-
Commit messages:
- 8274205: Handle KDC
On Fri, 23 Jul 2021 10:33:14 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 RS
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 applied to SunRSASig
On Thu, 8 Jul 2021 21:11:54 GMT, Alexey Bakhtin wrote:
> The original patch applies clean.
> Test passed.
This pull request has now been integrated.
Changeset: e1d3e73d
Author:Alexey Bakhtin
Committer: Vladimir Kempik
URL:
https://git.openjdk.java.net/jdk17/
The original patch applies clean.
Test passed.
-
Commit messages:
- Backport 6f171b9f0d28ad17b31a54bad894f38d19df6f73
Changes: https://git.openjdk.java.net/jdk17/pull/236/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=236&range=00
Issue: https://bugs.openjdk.java.n
On Thu, 17 Jun 2021 13:20:54 GMT, Alexey Bakhtin wrote:
> Please review the fix for JDK-8268965.
>
> The new jtreg test is added for the described issue.
> sun/security/ssl and javax/net/ssl tests are passed
This pull request has now been integrated.
Changeset: 6f171b9f
Autho
On Wed, 7 Jul 2021 17:22:07 GMT, Xue-Lei Andrew Fan wrote:
>> Alexey Bakhtin has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add read lock for inputRecord.deplete
>
> src/java.base/share/classes/sun/securi
> Please review the fix for JDK-8268965.
>
> The new jtreg test is added for the described issue.
> sun/security/ssl and javax/net/ssl tests are passed
Alexey Bakhtin has updated the pull request incrementally with one additional
commit since the last revision:
On Wed, 7 Jul 2021 10:15:19 GMT, Alexey Bakhtin wrote:
>> Please review the fix for JDK-8268965.
>>
>> The new jtreg test is added for the described issue.
>> sun/security/ssl and javax/net/ssl tests are passed
>
> Alexey Bakhtin has updated the pull request inc
> Please review the fix for JDK-8268965.
>
> The new jtreg test is added for the described issue.
> sun/security/ssl and javax/net/ssl tests are passed
Alexey Bakhtin has updated the pull request incrementally with one additional
commit since the last revision:
Add r
On Thu, 17 Jun 2021 13:20:54 GMT, Alexey Bakhtin wrote:
> Please review the fix for JDK-8268965.
>
> The new jtreg test is added for the described issue.
> sun/security/ssl and javax/net/ssl tests are passed
Hi Xuelei,
Thank you for your interest in this issue.
In this particular
Please review the fix for JDK-8268965.
The new jtreg test is added for the described issue.
sun/security/ssl and javax/net/ssl tests are passed
-
Commit messages:
- 8268965: TCP Connection Reset when connecting simple socket to SSL server
Changes: https://git.openjdk.java.net/jdk/p
On Fri, 23 Apr 2021 20:51:19 GMT, Alexey Bakhtin wrote:
> Hello All,
>
> Could you please review the fix for the JDK-8241248?
> The issue happens during the TLSv1.3 handshake without server stateless
> session resumption in case of server receives several parallel requests w
On Sat, 8 May 2021 19:48:39 GMT, Xue-Lei Andrew Fan wrote:
>> I'd like to keep my code as-is. We still need invalidate() if entry is not
>> valid (see remove() operation).
>
> Did you notice that entry.isValid() implementation has already call
> invalidate() if the entry is not valid?
I didn't
.server.enableSessionTicketExtension=false )
> javax/net/ssl and sun/security/ssl jtreg tests passed
>
> Regards
> Alexey
Alexey Bakhtin has updated the pull request incrementally with one additional
commit since the last revision:
Exclude duplicated operations i
On Sat, 8 May 2021 00:21:54 GMT, Xue-Lei Andrew Fan wrote:
>> Alexey Bakhtin has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add Cache.pull method
>
> src/java.base/share/classes/sun/security/ssl/PreShare
.server.enableSessionTicketExtension=false )
> javax/net/ssl and sun/security/ssl jtreg tests passed
>
> Regards
> Alexey
Alexey Bakhtin has updated the pull request incrementally with one additional
commit since the last revision:
Add comments and code cleanup
-
C
On Thu, 6 May 2021 19:15:27 GMT, Xue-Lei Andrew Fan wrote:
>> Unfortunately, simple pull() can not be used in this case. We have to check
>> if the session found in the cache can be rejoined with parameters received
>> in ClientHello and server context. Only rejoinable sessions should be
>> re
.server.enableSessionTicketExtension=false )
> javax/net/ssl and sun/security/ssl jtreg tests passed
>
> Regards
> Alexey
Alexey Bakhtin has updated the pull request incrementally with one additional
commit since the last revision:
Add Cache.pull method
-
Changes:
-
On Wed, 5 May 2021 03:41:27 GMT, Xue-Lei Andrew Fan wrote:
>> Thank you for the update.
>>
>> I also expect the code easy to read and maintain in the future. But please
>> go ahead for the integration if you don't want to make the update now. We
>> could file an enhancement later on.
>
>> @X
On Thu, 29 Apr 2021 15:58:28 GMT, Xue-Lei Andrew Fan wrote:
>> Yes, I’ve made a test that calculates total time spent by server to receive
>> "N" connections. Every server handshake is performed in a separate thread
>> The client starts "T" threads. Every thread sends one initial connection and
.server.enableSessionTicketExtension=false )
> javax/net/ssl and sun/security/ssl jtreg tests passed
>
> Regards
> Alexey
Alexey Bakhtin has updated the pull request incrementally with one additional
commit since the last revision:
Use ReentrantLock for session cache s
On Tue, 27 Apr 2021 16:00:33 GMT, Jamil Nimeh wrote:
> I think this looks good. Thank you.
> Since you've done all the work on this one, it seems fitting that you'd
> become the owner of the issue in JBS. Also this might be a noreg-hard
> candidate since the failure is intermittent and requires
On Tue, 27 Apr 2021 16:13:31 GMT, Xue-Lei Andrew Fan wrote:
>> Hello All,
>>
>> Could you please review the fix for the JDK-8241248?
>> The issue happens during the TLSv1.3 handshake without server stateless
>> session resumption in case of server receives several parallel requests with
>> the
Hi Jamil, Norman,
I’ve missed this thread discussing JDK-8241248 issue.
Recently I have suggested a fix for this issue :
https://github.com/openjdk/jdk/pull/3664
Regards
Alexey
> On 26 Apr 2021, at 11:31, Norman Maurer wrote:
>
> Sorry for the noise but is there any update ? The bug makes it “
Hello All,
Could you please review the fix for the JDK-8241248?
The issue happens during the TLSv1.3 handshake without server stateless session
resumption in case of server receives several parallel requests with the same
pre_shared_key.
The main idea of the fix is to remove resuming session fro
On Tue, 27 Oct 2020 12:27:52 GMT, Alexey Bakhtin wrote:
> Hi All,
>
> DES and DESede keys are supported by JKS/JCEKS but not supported by PKCS#12
> keystores.
> This issue prevents the migration of legacy applications to PKCS#12 keystore.
> For example, an application has
t is updated to verify new secret keys in
> the PKCS#12 keystore.
Alexey Bakhtin has updated the pull request incrementally with one additional
commit since the last revision:
Fix order of OIDs
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/877/files
- new: https
t is updated to verify new secret keys in
> the PKCS#12 keystore.
Alexey Bakhtin has updated the pull request incrementally with one additional
commit since the last revision:
DES oid is 1.3.14.3.2.7
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/877/files
- n
On Tue, 27 Oct 2020 16:12:14 GMT, Weijun Wang wrote:
>> At least BouncyCastle uses the same OIDs:
>> http://javadox.com/org.bouncycastle/bcprov-jdk15on/1.51/org/bouncycastle/asn1/oiw/OIWObjectIdentifiers.html
>
> Yes I can see the OIDs. I was just wondering if other vendors are also using
> the
On Tue, 27 Oct 2020 14:19:00 GMT, Weijun Wang wrote:
>> Hi All,
>>
>> DES and DESede keys are supported by JKS/JCEKS but not supported by PKCS#12
>> keystores.
>> This issue prevents the migration of legacy applications to PKCS#12
>> keystore. For example, an application has some old 3DES keys
Hi All,
DES and DESede keys are supported by JKS/JCEKS but not supported by PKCS#12
keystores.
This issue prevents the migration of legacy applications to PKCS#12 keystore.
For example, an application has some old 3DES keys that are required for
certain legacy features. Java PKCS12 keystore doe
On Mon, 21 Sep 2020 08:19:28 GMT, Alexey Bakhtin wrote:
> Hi,
>
> Plaese review JDK-8245527 fix which implements LDAP Channel Binding support
> for Java GSS/Kerberos.
> Initial review is available at core-devs:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-
On Tue, 22 Sep 2020 15:36:24 GMT, Daniel Fuchs wrote:
>> No, It is not used.
>> However, I'd like to leave it as is (it is mentioned in the documentation as
>> unsupported value).
>> Otherwise, TlsChannelBindingType enum will have one element only and should
>> be simplified/removed in all plac
On Tue, 22 Sep 2020 15:11:57 GMT, Weijun Wang wrote:
>> Alexey Bakhtin has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8245527: version.01
>
> src/jdk.security.jgss/share/classes/com/sun/security/sasl/gssk
" CB type from the list of possible channel
> binding types. The only supported type is
> "tls-server-end-point"
> CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311
>
> Thank you
> Alexey
Alexey Bakhtin has updated the pull request increm
On Tue, 22 Sep 2020 14:47:35 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Plaese review JDK-8245527 fix which implements LDAP Channel Binding support
>> for Java GSS/Kerberos.
>> Initial review is available at core-devs:
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html
On Tue, 22 Sep 2020 14:41:57 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Plaese review JDK-8245527 fix which implements LDAP Channel Binding support
>> for Java GSS/Kerberos.
>> Initial review is available at core-devs:
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html
Hi,
Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for
Java GSS/Kerberos.
Initial review is available at core-devs:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html
This version removes "tls-unique" CB type from the list of possible chann
best regards,
>> -- daniel
>> On 14/08/2020 14:18, Sean Mullan wrote:
>>> On 8/14/20 8:41 AM, Alexey Bakhtin wrote:
>>>> Hello Sean,
>>>>
>>>> Thank you for review.
>>>> I’ve changed wording and replaced @code with @systemProperty
OK
Updated for all properties in the module-info.java
Webrev at: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v16/
Regards
Alexey
> On 14 Aug 2020, at 16:18, Sean Mullan wrote:
>
> On 8/14/20 8:41 AM, Alexey Bakhtin wrote:
>> Hello Sean,
>> Thank you for review.
&g
state to "Proposed".
>> best regards,
>> -- daniel
>> [1] https://bugs.openjdk.java.net/browse/JDK-8247311
>> On 30/07/2020 10:17, Alexey Bakhtin wrote:
>>> Gentle ping
>>>
>>> Regards
>>> Alexey
signature.asc
Description: Message signed with OpenPGP
Hello Bernd,
The difference between Java8u TLSv1.3 backport and OpenJSSE is
TLS_CHACHA20_POLY1305_SHA256 cipher suite support.
I've found, that connection to google.com succeeds in case of ClientHello
includes Chacha20-Poly1305 in the list of supported cipher suites, even if
status request is d
Gentle ping
Regards
Alexey
> On 15 Jul 2020, at 14:18, Alexey Bakhtin wrote:
>
> Hello Daniel,
>
> I’ve updated CSR as you suggested and added kerberos ldap setup commands for
> the client host in the JDK-8245527
>
> Regards
> Alexey
signature.asc
Description: Message signed with OpenPGP
Hello Daniel,
I’ve updated CSR as you suggested and added kerberos ldap setup commands for
the client host in the JDK-8245527
Regards
Alexey
> On 14 Jul 2020, at 18:28, Daniel Fuchs wrote:
>
> Hi Alexey,
>
> On 10/07/2020 21:37, Alexey Bakhtin wrote:
>>
the test verbosity and reduce its code size.
Thank you for suggestion. Updated to use BaseLdapServer in the test
>
> LdapCBPropertiesTest.java:122 - could use no param Hastable constructor
Fixed
>
> I've also run your latest patch through our CI system and it showed no
> fail
Hello Sean, Daniel,
Thank you for review
I’ve added “com.sun.jndi.ldap.tls.cbtype” property into the module-info file
and updated synchronisation using CompletableFuture.
Also, I have added new test cases : successful and unsuccessful TLS handshake,
synchronous and asynchronous TLS handshake.
New
scussed already, but can you explain why the
>>> "com.sun.jndi.ldap.connect.timeout" property needs to be set in order to
>>> use this feature? That property is mostly used in tests to avoid long
>>> socket timeouts, etc.
>>>
>>> Why does
> I would suggest removing it. At least for the SASL GSS-API mech, it seems the
> GSSContext object will not be leaked and no one has a chance to call
> setChannelBinding again on it.
>
> There is no spec saying setChannelBinding() can only be called once, so I'd
> rather we don't enforce that
Hello All,
Thank you for review.
> 1. If the change in java.security.jgss/share/classes/module-info.java is
> unavoidable, can we create a sub-package for this single class so that we
> only need to export it?
As suggested by Max I’ve moved TlsChannelBindingImpl class into sub-package, so
mod
Hello Daniel,
Thank you for review.
I have updated LdapCBPropertiesTest according to your comments.
Updated webrev at http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v9/
Regards
Alexey
signature.asc
Description: Message signed with OpenPGP
Hello Daniel,
Thank you for review.
As you suggested I’ve added static factory methods to create TlsChannelBinding
class and changed connectionTimeout verification to "if (connectTimeout <= 0)"
Also, I’ve added simple regression test to verify Channel Binding parameters.
Please find updated we
Hello Sean,
The link to CSR for this feature :
https://bugs.openjdk.java.net/browse/JDK-8247311
Regards
Alexey
> On 9 Jun 2020, at 19:50, Sean Mullan wrote:
>
> On 6/9/20 12:40 PM, Xuelei Fan wrote:
>> About the prefix, it may follow RFC 5056 (See page 7, section 2.1).
>>o Specifications
ase/java.lang.reflect.Method.invoke(Method.java:564)
> at
> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:832)
>
>
> For information about CSR process you can start from this wiki page:
> h
-channel-binding-hash-aka-extended-protection-for-authentication
So, it is hard to say - is it a standard or Microsoft implementation specific
Regards
Alexey
> On 9 Jun 2020, at 18:35, Sean Mullan wrote:
>
> On 6/8/20 5:33 PM, Alexey Bakhtin wrote:
>> Hello Sean,
>> Yes, I
);
>> + // verify LDAP channel binding property
>> + if (cbType != null && connectTimeout == -1) {
>> + throw new NamingException(TlsChannelBinding.CHANNEL_BINDING_TYPE +
>> + " property requires com.sun.jndi.ldap.connect.timeout&q
ctions so
> our SQE can see if we can setup some internal tests. Then we can add
> noreg-hard with some justification to the test and go on.
>
> I cannot comment on LdapCtx.java, but the others look fine to me.
>
> Thanks,
> Max
>
>> On Jun 7, 2020, at 3:45 AM, Ale
yet. I did not find any suitable test case
that can be reused.
Thank you
Alexey
> On 6 Jun 2020, at 09:44, Weijun Wang wrote:
>
>
>
>> On Jun 6, 2020, at 2:41 PM, Weijun Wang wrote:
>>
>>
>>
>>> On Jun 5, 2020, at 11:03 PM, Alexey Bakhtin wr
CHANNEL_BINDING_TYPE + " property.");
> 2585 }
>
> is not correct - as IllegalArgumentException, IllegalStateException and
> UnsupportedOperationException will percolate up to the calling code, and
> are not documented at the public API level.
> These should really be
keep it
> internal then we also have the chance to modify the approach later.
>
> Thanks,
> Max
>
>
>> On Jun 5, 2020, at 2:15 AM, Alexey Bakhtin wrote:
>>
>> Hello,
>>
>> Could you please review new version of the patch:
>> http://cr.op
is independent with any application level info.
>
> From my reading of the code change, it looks like this cbData can be
> calculated on the LDAP side.
>
> Thanks,
> Max
>
>> On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote:
>>
>> Hello,
>>
>>
oth of them have default values set to '-1' which means that the LDAP stack
> would not set any timeouts for connect and/or reading operations.
>
> Could you, please, share the failures you're observing with no connect
> timeout set?
>
> Best,
> Aleksei
&g
ote:
>
>
>
>> On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote:
>>
>> The hash algorithm is selected on the base of the certificate
>> signature algorithm.
>> Also, the client should use SHA-256 algorithm, in case of the
>> certificate sign
> This could be configured as a SASL property and it would add the benefit that
> you don't need the instance specific if in the gssstub native code if you
> instead have two different types values?
>
> Gruss
> Bernd
>
> Von: security-dev im Auftrag von
> Alexey
C instead of GSS_C_AF_NULLADDR (line 194-195).
>
> Can you try and see if Window works with GSS_C_AF_NULLADDR? If yes, I'd
> prefer to not changing the default value for addresstype for the same reason
> which Michael has already stated.
>
> Thanks,
> Valerie
>
>
on level info.
>
> From my reading of the code change, it looks like this cbData can be
> calculated on the LDAP side.
>
> Thanks,
> Max
>
>> On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote:
>>
>> Hello,
>>
>> Could you please review
ave to have knowledge of channel binding
>> and extract the certificates from the SSLSocket to pass them to
>> the lower layer. Ideally this should rather be handled by the
>> SASL layers?
>>
>> best regards,
>>
>> -- daniel
>>
>>
>> On 25/05/2020 16:33, Alexey Bakhtin wrote:
>>> Updated webrev is available
>>> at:http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v1/
>>
signature.asc
Description: Message signed with OpenPGP
hannelBinding the type
> fo the adress. So will change my opinion a bit:
>
> No property for AD/non-AD is necessary, but handling of UNSPEC is
> required. JGSS shall remain at NULLADDR. The subtype
> UnspecEmptyInetAddress should be at least evaluated.
>
> Michael
>
/
Also, please see my comments below.
Regards
Alexey
> On 24 May 2020, at 02:38, Michael Osipov <1983-01...@gmx.net> wrote:
>
> Am 2020-05-21 um 09:35 schrieb Alexey Bakhtin:
>> Hello,
>>
>> Could you please review the following patch:
>>
>> JBS: htt
Hello,
Could you please review the following patch:
JBS: https://bugs.openjdk.java.net/browse/JDK-8245527
Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/
The Windows LDAP server with LdapEnforceChannelBinding=2 uses the
tls-server-end-point channel binding
(based on the TLS serv
1 - 100 of 115 matches
Mail list logo
