openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#8927) slapo-ppolicy is destructive to delta-sync replication
by quanah＠symas.com 12 Oct '18

12 Oct '18

--On Thursday, October 11, 2018 9:25 PM +0000 quanah(a)openldap.org wrote: > When the second action is performed (c), all consumers will go into > REFRESH mode: There appears to be a serious bug in ppolicy. If I look at the accesslog data that was written out, the "pwdFailureTime" attribute is cleared on two different entries instead of just the user entry that had its password reset. I.e., pwdFailureTime is cleared on the user AND the DN of the manager entry that made the change. dn: reqStart=20181012145703.000000Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20181012145703.000000Z reqEnd: 20181012145703.000001Z reqType: modify reqSession: 1003 reqAuthzID: cn=ldaproot,dc=example,dc=com reqDN: uid=user1,ou=user,dc=example,dc=com reqResult: 0 reqMod: pwdFailureTime:+ 20181012145703.125562Z reqMod: entryCSN:= 20181012145703.125803Z#000000#001#000000 reqMod: modifiersName:= cn=ldaproot,dc=example,dc=com reqMod: modifyTimestamp:= 20181012145703Z reqEntryUUID: ac657c60-e60a-412d-b015-522fc451e89a entryUUID: d2b4a16c-627a-1038-9d4c-dbb80effb9f4 creatorsName: cn=accesslog createTimestamp: 20181012145703Z entryCSN: 20181012145703.125803Z#000000#001#000000 modifiersName: cn=accesslog modifyTimestamp: 20181012145703Z dn: reqStart=20181012145706.000000Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20181012145706.000000Z reqEnd: 20181012145706.000001Z reqType: modify reqSession: 1003 reqAuthzID: cn=ldaproot,dc=example,dc=com reqDN: cn=idmgmt,ou=user,ou=service,dc=example,dc=com reqResult: 0 reqMod: pwdFailureTime:- reqMod: entryCSN:= 20181012145706.147871Z#000000#001#000000 reqMod: modifiersName:= cn=ldaproot,dc=example,dc=com reqMod: modifyTimestamp:= 20181012145706Z reqEntryUUID: bf72bf9a-6079-102b-83cd-8572a998cec3 entryUUID: d4822668-627a-1038-9d4d-dbb80effb9f4 creatorsName: cn=accesslog createTimestamp: 20181012145706Z entryCSN: 20181012145706.147871Z#000000#001#000000 modifiersName: cn=accesslog modifyTimestamp: 20181012145706Z dn: reqStart=20181012145706.000002Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20181012145706.000002Z reqEnd: 20181012145706.000003Z reqType: modify reqSession: 1003 reqAuthzID: cn=idmgmt,ou=user,ou=service,dc=example,dc=com reqDN: uid=user1,ou=user,dc=example,dc=com reqResult: 0 reqMod: userPassword:= {SSHA}y8UHEPuMnrOwrZnufP3XrG7ofbHKRpT0 reqMod: pwdChangedTime:= 20181012145706Z reqMod: pwdFailureTime:- reqMod: entryCSN:= 20181012145706.171028Z#000000#001#000000 reqMod: modifiersName:= cn=idmgmt,ou=user,ou=service,dc=example,dc=com reqMod: modifyTimestamp:= 20181012145706Z reqEntryUUID: ac657c60-e60a-412d-b015-522fc451e89a entryUUID: d4845d20-627a-1038-9d4e-dbb80effb9f4 creatorsName: cn=accesslog createTimestamp: 20181012145706Z entryCSN: 20181012145706.171028Z#000000#001#000000 modifiersName: cn=accesslog modifyTimestamp: 20181012145706Z --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8926) glue records + syncrepl
by frederic.goudal＠bordeaux-inp.fr 11 Oct '18

11 Oct '18

> Le 11 oct. 2018 =C3=A0 18:32, Howard Chu <hyc(a)symas.com> a =C3=A9crit = : >=20 > goudal(a)bordeaux-inp.fr wrote: >> Full_Name: Fr.d.ric Goudal >>=20 >> Solution=20 >> -remove by hand the dn: uid=3Dfoo,ou=3Dbar,dc=3Dmy,dc=3Ddomain, = that remove the >> glue object >> - create by hand the ou=3Dbar,dc=3Dmy,dc=3Ddomain >>=20 >> What IMHO slapd should do : >> - either check that it does not add an object before its parent = objects >=20 > No. This behavior is already documented in the Syncrepl specification. >=20 >> - either convert the glue object to the correct object when the real = creation is >> needed. >=20 > The slapd consumer already does this when running on a local database. = It would > require Manage privileges when running through back-ldap. Check your = back-ldap configuration. Well=E2=80=A6 I=E2=80=99v read 5 time the documentation on my setup, = never seen the manage privilege mentioned anywhere=E2=80=A6 Even in the example given for the backend configuration the acls don=E2=80= =99t mention this =C2=AB manage =C2=BB privilege : =46rom page : = https://www.openldap.org/doc/admin24/replication.html#Syncrepl # Give the replica DN unlimited read access. This ACL may need to be # merged with other ACL statements. access to * by dn.base=3D"cn=3Dreplicator,dc=3Dsuretecsystems,dc=3Dcom" = write by * break access to dn.base=3D"" by * read access to dn.base=3D"cn=3DSubschema" by * read access to dn.subtree=3D"cn=3DMonitor" by dn.exact=3D"uid=3Dadmin,dc=3Dsuretecsystems,dc=3Dcom" = write by users read by * none access to * by self write by * read Wel.. I can accept it=E2=80=99s a documentation bug=E2=80=A6but where is = the correct documentation ? f.g.

1 0

Re: (ITS#8926) glue records + syncrepl
by frederic.goudal＠bordeaux-inp.fr 11 Oct '18

11 Oct '18

> Le 11 oct. 2018 =C3=A0 18:32, Howard Chu <hyc(a)symas.com> a =C3=A9crit = : >=20 > goudal(a)bordeaux-inp.fr wrote: >> Full_Name: Fr.d.ric Goudal >>=20 >> Solution=20 >> -remove by hand the dn: uid=3Dfoo,ou=3Dbar,dc=3Dmy,dc=3Ddomain, = that remove the >> glue object >> - create by hand the ou=3Dbar,dc=3Dmy,dc=3Ddomain >>=20 >> What IMHO slapd should do : >> - either check that it does not add an object before its parent = objects >=20 > No. This behavior is already documented in the Syncrepl specification. >=20 >> - either convert the glue object to the correct object when the real = creation is >> needed. >=20 > The slapd consumer already does this when running on a local database. = It would > require Manage privileges when running through back-ldap. Check your = back-ldap configuration. Well=E2=80=A6 I=E2=80=99v read 5 time the documentation on my setup, = never seen the manage privilege mentioned anywhere=E2=80=A6 Even in the example given for the backend configuration the acls don=E2=80= =99t mention this =C2=AB manage =C2=BB privilege : =46rom page : = https://www.openldap.org/doc/admin24/replication.html#Syncrepl # Give the replica DN unlimited read access. This ACL may need to = be # merged with other ACL statements. access to * by dn.base=3D"cn=3Dreplicator,dc=3Dsuretecsystems,dc=3Dcom" = write by * break access to dn.base=3D"" by * read access to dn.base=3D"cn=3DSubschema" by * read access to dn.subtree=3D"cn=3DMonitor" by dn.exact=3D"uid=3Dadmin,dc=3Dsuretecsystems,dc=3Dcom" = write by users read by * none access to * by self write by * read Wel.. I can accept it=E2=80=99s a documentation bug=E2=80=A6but where is = the correct documentation ? f.g.

1 0

(ITS#8927) slapo-ppolicy is destructive to delta-sync replication
by quanah＠openldap.org 11 Oct '18

11 Oct '18

Full_Name: Quanah Gibson-Mount Version: 2.4.46 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) While investigating a report of an issue with slapo-ppolicy in an MMR environment, I've found that ppolicy is destructive in a delta-sync replicated environment. The root cause of course is that there is no guidance on how to handle how replication works with ppolicy, a deficiency that must be addressed before any final draft is completed. Reproduction case: a) Set up a delta-sync replicated environment with slapo-ppolicy enabled and a default policy of: pwdAttribute: userPassword pwdLockout: TRUE pwdLockoutDuration: 1800 pwdMaxFailure: 100 pwdFailureCountInterval: 300 b) Bind as a user to master1 with an invalid password c) perform an ldap v3 password modify against master1 as an administrative user and reset the password for the user in step b When the second action is performed (c), all consumers will go into REFRESH mode: Oct 11 11:44:37 anvil2 slapd[5791]: syncrepl_null_callback : error code 0x10 Oct 11 11:44:37 anvil2 slapd[5791]: slap_graduate_commit_csn: removing 0x7faf10106000 20181011184437.093014Z#000000#001#000000 Oct 11 11:44:37 anvil2 slapd[5791]: syncrepl_message_to_op: rid=001 be_modify uid=user1,ou=user,dc=example,dc=com (16) Oct 11 11:44:37 anvil2 slapd[5791]: do_syncrep2: rid=001 delta-sync lost sync on (reqStart=20181011184437.000001Z,cn=accesslog), switching to REFRESH As noted in ITS#8125, going into REFRESH mode can cause data loss.

1 0

Re: (ITS#8924) Installed openldap2.4.46 and openssl1.1.1, the client and server still used TLS1.2 to negotiated
by quanah＠symas.com 11 Oct '18

11 Oct '18

--On Thursday, October 11, 2018 3:52 PM +0800 moyanan <nanmor(a)126.com> wrote: > I set the parameter in client: TLS_PROTOCOL_MIN 3.4, the client still > start a client hello with TLS1.2, i doubt that the parameter not work in > my configuration. > here is my ldap.conf: Hi Nancy, I would suggest reading the man page for ldap.conf(5): <http://www.openldap.org/software/man.cgi?query=ldap.conf&apropos=0&sektion=…> Some of the settings in the ldap.conf you provided do not seem valid. Again, I'd confirm what SSL library the ldapsearch you're using is linked to. (I.e., ldd /path/to/ldapsearch). I only see TLS 1.3 negotiated by default in my build setup where both slapd and the ldap* tools are linked to OpenSSL 1.1.1. Per the ldap.conf(5) man page, the TLS_PROTOCOL_MIN parameter is ignored by GnuTLS, which makes me wonder if you're using a GnuTLS linked ldapsearch binary. The ldap.conf file I'm using simply sets TLS_REQCERT never and no other options configured. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8926) glue records + syncrepl
by hyc＠symas.com 11 Oct '18

11 Oct '18

goudal(a)bordeaux-inp.fr wrote: > Full_Name: Fr.d.ric Goudal > Version: 2.4.46 > OS: ubuntu 18.14 LTS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (147.210.204.135) > > > The global setup is the following : > - 1 master ldap (2.4.40) > - 1 hidden slave on the master ldap, same suffix, ldap backend > - 1 ldap backend on a distant server (2.4.46) > > When starting synchronisation the following event are happening : > - for some reason the sync process ask for creating > dn:uid=foo,ou=bar,dc=my,dc=domaine BEFORE the creation of > dn : ou=bar,dc=my,dc=domain > > - on the backend the following entries are created in that order > - dn:ou=bar,dc=my,dc=domain with the object class glue > - dn: uid=foo,ou=bar,dc=my,dc=domain > > Than... the sync tries to create ou=bar,dc=my,dc=domain with the correct > objectClass : organizationalUnit > But, as the object exists on the backend ldap, creation fails, and > synchronization stops. > > Solution > -remove by hand the dn: uid=foo,ou=bar,dc=my,dc=domain, that remove the > glue object > - create by hand the ou=bar,dc=my,dc=domain > > What IMHO slapd should do : > - either check that it does not add an object before its parent objects No. This behavior is already documented in the Syncrepl specification. > - either convert the glue object to the correct object when the real creation is > needed. The slapd consumer already does this when running on a local database. It would require Manage privileges when running through back-ldap. Check your back-ldap configuration. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8926) glue records + syncrepl
by goudal＠bordeaux-inp.fr 11 Oct '18

11 Oct '18

Full_Name: Fr.d.ric Goudal Version: 2.4.46 OS: ubuntu 18.14 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (147.210.204.135) The global setup is the following : - 1 master ldap (2.4.40) - 1 hidden slave on the master ldap, same suffix, ldap backend - 1 ldap backend on a distant server (2.4.46) When starting synchronisation the following event are happening : - for some reason the sync process ask for creating dn:uid=foo,ou=bar,dc=my,dc=domaine BEFORE the creation of dn : ou=bar,dc=my,dc=domain - on the backend the following entries are created in that order - dn:ou=bar,dc=my,dc=domain with the object class glue - dn: uid=foo,ou=bar,dc=my,dc=domain Than... the sync tries to create ou=bar,dc=my,dc=domain with the correct objectClass : organizationalUnit But, as the object exists on the backend ldap, creation fails, and synchronization stops. Solution -remove by hand the dn: uid=foo,ou=bar,dc=my,dc=domain, that remove the glue object - create by hand the ou=bar,dc=my,dc=domain What IMHO slapd should do : - either check that it does not add an object before its parent objects - either convert the glue object to the correct object when the real creation is needed. f

1 0

(ITS#8925) Please remove the entry for mirror.switch.ch from the Download page
by switchmirror＠switch.ch 11 Oct '18

11 Oct '18

Full_Name: Thomas Lenggenhager Version: 2.4.9 OS: Solaris URL: Submission from: (NULL) (2001:620:0:44:12dd:b1ff:fed3:e027) I already sent twice a message to info(a)openldap.org, but no action or answer received. So I try it on this channel. Please drop the reference to SWITCH (Switzerland, mirror.switch.ch) on the Download web page: http://www.openldap.org/software/download/ Here the message I sent: ------------ The SWITCHmirror service hosted on mirror.switch.ch will be decommissioned soon. Could you please remove the entry for mirror.switch.ch from your list of mirror sites and notify us once accomplished? Thereafter, we will stop the mirroring of this package and drop it from our repository. PS: See http://mirror.switch.ch for details on the decommissioning. BTW: I noticed that the Austrian mirror on gd.tuwien.ac.at has completely disappeared, there is no DNS entry for it anymore.

1 0

Re: (ITS#8924) Installed openldap2.4.46 and openssl1.1.1, the client and server still used TLS1.2 to negotiated
by nanmor＠126.com 10 Oct '18

10 Oct '18

--Apple-Mail=_A57FFFE0-FA22-44A6-A24D-07E9ADC17D6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Quanah, I=E2=80=99m afraid that the message will be encoded so that you can not = see, so send again.=20 After I set a parameter in server: TLSProtocolMin 3.4, restart the ldap = server, it works that the server will not negotiated with lower TLS = version. I set the parameter in client: TLS_PROTOCOL_MIN 3.4, the client still = start a client hello with TLS1.2, i doubt that the parameter not work in = my configuration. here is my ldap.conf: ssl start_tls TLS_CACERTDIR /usr/local/etc/openldap/cacerts TLS_CACERT /usr/local/etc/openldap/cacerts/cacert.pem TLS_REQCERT never TLS_PROTOCOL_MIN 3.4 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never SASL_NOCANON on BASE cn=3Dlocalhost debug 9 local4.* /var/log/ldap.log I used "openssl s_client -connect mydomain.com:636 = <http://mydomain.com:636/> -tls1_3" to connect the same server from = the same client, it will used TLS1.3 successfully. I think the openssl = for TLS1.3 works well.=20 How can I make sure our client and server link to the openssl ? And = could you please show your configuration about TLS in ldap.conf and = slap.conf to me, if you are convenient.=20 Thanks a lot. best regards=20 nancy > On Oct 9, 2018, at 9:56 PM, Quanah Gibson-Mount <quanah(a)symas.com> = wrote: >=20 > --On Tuesday, October 09, 2018 10:02 AM +0000 nanmor(a)126.com wrote: >=20 >> We can get the result, but from Wireshark result, we find that they = used >> TLS1.2 to negotiated. >=20 > I do not find this to be the case with OpenLDAP 2.4.46. >=20 >> The openSSL is support for TLS1.3,however openldap-2.4.46 is still = used >> TLS1.2 by default. Need some parameters to specify TLS1.3 in openldap >> configuration? >=20 > Nope. >=20 >> By the way, I have tested that other application can negotiated with >> TLS1.3 by default when the client and server both use openssl-1.1.1. >=20 > That is the behavior I see. >=20 > OpenLDAP 2.4.46 linked to OpenSSL 1.1.1 for both the client and = server: >=20 > 5bbcb282 connection_read(14): checking for input on id=3D1001 > TLS trace: SSL_accept:TLSv1.3 early data > TLS trace: SSL_accept:SSLv3/TLS read finished > TLS trace: SSL_accept:SSLv3/TLS write session ticket > TLS trace: SSL_accept:SSLv3/TLS write session ticket >=20 > Perhaps the ldapsearch you picked up was not the one linked to OpenSSL = 1.1.1. >=20 > You may also want to read the slapd.conf(5) or slapd-config(5) man = pages on how to set a minimum required TLS protocol version. >=20 > Regards, > Quanah >=20 > -- >=20 > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> --Apple-Mail=_A57FFFE0-FA22-44A6-A24D-07E9ADC17D6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><div = style=3D"font-family: Arial; font-size: 14px;" class=3D"">Hi = Quanah,</div><div style=3D"font-family: Arial; font-size: 14px;" = class=3D""><br class=3D""></div><div style=3D"font-family: Arial; = font-size: 14px;" class=3D"">I=E2=80=99m afraid that the message will be = encoded so that you can not see, so send again. </div><div = style=3D"font-family: Arial; font-size: 14px;" class=3D""><br = class=3D""></div><div style=3D"font-family: Arial; font-size: 14px;" = class=3D"">After I set a parameter in server:  TLSProtocolMin 3.4, = restart the ldap server, it works that the server will not negotiated = with lower TLS version.<br class=3D""></div><div style=3D"font-family: = Arial; font-size: 14px;" class=3D"">I set the parameter in client: = TLS_PROTOCOL_MIN 3.4, the client still start a client hello with TLS1.2, = i doubt that the parameter not work in my configuration.</div><div = style=3D"font-family: Arial; font-size: 14px;" class=3D"">here is my = ldap.conf:</div><div style=3D"font-family: Arial; font-size: 14px;" = class=3D""><br class=3D"">ssl start_tls<br class=3D"">TLS_CACERTDIR  = /usr/local/etc/openldap/cacerts<br class=3D"">TLS_CACERT = /usr/local/etc/openldap/cacerts/cacert.pem<br class=3D"">TLS_REQCERT = never<br class=3D"">TLS_PROTOCOL_MIN 3.4<br = class=3D"">#SIZELIMIT      12<br = class=3D"">#TIMELIMIT      15<br = class=3D"">#DEREF          = never<br class=3D"">SASL_NOCANON    on<br class=3D"">BASE = cn=3Dlocalhost<br class=3D"">debug 9<br = class=3D"">local4.*         &= nbsp;  /var/log/ldap.log</div><div style=3D"font-family: Arial; = font-size: 14px;" class=3D"">I used "openssl s_client -connect <a = href=3D"http://mydomain.com:636" = class=3D"">mydomain.com:636</a> -tls1_3"   to connect the same = server from the same client, it will used TLS1.3 successfully. I think = the openssl for TLS1.3 works well. <br class=3D""></div><div = style=3D"font-family: Arial; font-size: 14px;" class=3D""><br = class=3D""></div><div style=3D"font-family: Arial; font-size: 14px;" = class=3D"">How can I make sure our client and server link to the openssl = ?  And could you please  show your configuration about TLS in = ldap.conf and slap.conf to me, if you are convenient. <br = class=3D""></div><div style=3D"font-family: Arial; font-size: 14px;" = class=3D""><br class=3D""></div><div style=3D"font-family: Arial; = font-size: 14px;" class=3D"">Thanks a lot.</div><div style=3D"font-family:= Arial; font-size: 14px;" class=3D""><br class=3D""></div><div = style=3D"font-family: Arial; font-size: 14px;" class=3D"">best = regards <br class=3D""></div><div style=3D"font-family: Arial; = font-size: 14px;" class=3D"">nancy<br class=3D""></div><br = style=3D"font-family: Arial; font-size: 14px;" class=3D""><div = style=3D"font-family: Arial; font-size: 14px; position: relative; zoom: = 1;" class=3D""></div><div id=3D"divNeteaseMailCard" style=3D"font-family: = Arial; font-size: 14px;" class=3D""></div><div><br class=3D""><blockquote = type=3D"cite" class=3D""><div class=3D"">On Oct 9, 2018, at 9:56 PM, = Quanah Gibson-Mount <<a href=3D"mailto:quanah@symas.com" = class=3D"">quanah(a)symas.com</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">--On = Tuesday, October 09, 2018 10:02 AM +0000 <a href=3D"mailto:nanmor@126.com"= class=3D"">nanmor(a)126.com</a> wrote:<br class=3D""><br = class=3D""><blockquote type=3D"cite" class=3D"">We can get the result, = but from Wireshark result, we find that they used<br class=3D"">TLS1.2 = to negotiated.<br class=3D""></blockquote><br class=3D"">I do not find = this to be the case with OpenLDAP 2.4.46.<br class=3D""><br = class=3D""><blockquote type=3D"cite" class=3D"">The openSSL is support = for TLS1.3,however openldap-2.4.46 is still used<br class=3D"">TLS1.2 by = default. Need some parameters to specify TLS1.3 in openldap<br = class=3D"">configuration?<br class=3D""></blockquote><br = class=3D"">Nope.<br class=3D""><br class=3D""><blockquote type=3D"cite" = class=3D"">By the way, I have tested that other application can = negotiated with<br class=3D"">TLS1.3 by default when the client and = server both use openssl-1.1.1.<br class=3D""></blockquote><br = class=3D"">That is the behavior I see.<br class=3D""><br = class=3D"">OpenLDAP 2.4.46 linked to OpenSSL 1.1.1 for both the client = and server:<br class=3D""><br class=3D"">5bbcb282 connection_read(14): = checking for input on id=3D1001<br class=3D"">TLS trace: = SSL_accept:TLSv1.3 early data<br class=3D"">TLS trace: = SSL_accept:SSLv3/TLS read finished<br class=3D"">TLS trace: = SSL_accept:SSLv3/TLS write session ticket<br class=3D"">TLS trace: = SSL_accept:SSLv3/TLS write session ticket<br class=3D""><br = class=3D"">Perhaps the ldapsearch you picked up was not the one linked = to OpenSSL 1.1.1.<br class=3D""><br class=3D"">You may also want to read = the slapd.conf(5) or slapd-config(5) man pages on how to set a minimum = required TLS protocol version.<br class=3D""><br class=3D"">Regards,<br = class=3D"">Quanah<br class=3D""><br class=3D"">--<br class=3D""><br = class=3D"">Quanah Gibson-Mount<br class=3D"">Product Architect<br = class=3D"">Symas Corporation<br class=3D"">Packaged, certified, and = supported LDAP solutions powered by OpenLDAP:<br class=3D""><<a = href=3D"http://www.symas.com" class=3D"">http://www.symas.com</a>><br = class=3D""></div></div></blockquote></div><br class=3D""></body></html>= --Apple-Mail=_A57FFFE0-FA22-44A6-A24D-07E9ADC17D6A--

1 0

Re:Re: (ITS#8924) Installed openldap2.4.46 and openssl1.1.1, the client and server still used TLS1.2 to negotiated
by nanmor＠126.com 09 Oct '18

09 Oct '18

------=_Part_53823_903760140.1539140876552 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 SGkgUXVhbmFoLAoKCkFmdGVyIEkgc2V0IGEgcGFyYW1ldGVyIGluIHNlcnZlcjogIFRMU1Byb3Rv Y29sTWluIDMuNCwgcmVzdGFydCB0aGUgbGRhcCBzZXJ2ZXIsIGl0IHdvcmtzIHRoYXQgdGhlIHNl cnZlciB3aWxsIG5vdCBuZWdvdGlhdGVkIHdpdGggbG93ZXIgVExTIHZlcnNpb24uCgpJIHNldCB0 aGUgcGFyYW1ldGVyIGluIGNsaWVudDogVExTX1BST1RPQ09MX01JTiAzLjQsIHRoZSBjbGllbnQg c3RpbGwgc3RhcnQgYSBjbGllbnQgaGVsbG8gd2l0aCBUTFMxLjIsIGkgZG91YnQgdGhhdCB0aGUg cGFyYW1ldGVyIG5vdCB3b3JrIGluIG15IGNvbmZpZ3VyYXRpb24uCmhlcmUgaXMgbXkgbGRhcC5j b25mOgoKc3NsIHN0YXJ0X3RscwpUTFNfQ0FDRVJURElSICAvdXNyL2xvY2FsL2V0Yy9vcGVubGRh cC9jYWNlcnRzClRMU19DQUNFUlQgL3Vzci9sb2NhbC9ldGMvb3BlbmxkYXAvY2FjZXJ0cy9jYWNl cnQucGVtClRMU19SRVFDRVJUIG5ldmVyClRMU19QUk9UT0NPTF9NSU4gMy40CiNTSVpFTElNSVQg ICAgICAxMgojVElNRUxJTUlUICAgICAgMTUKI0RFUkVGICAgICAgICAgIG5ldmVyClNBU0xfTk9D QU5PTiAgICBvbgpCQVNFIGNuPWxvY2FsaG9zdApkZWJ1ZyA5CmxvY2FsNC4qICAgICAgICAgICAg L3Zhci9sb2cvbGRhcC5sb2cKSSB1c2VkICJvcGVuc3NsIHNfY2xpZW50IC1jb25uZWN0IG15ZG9t YWluLmNvbTo2MzYgLXRsczFfMyIgICB0byBjb25uZWN0IHRoZSBzYW1lIHNlcnZlciBmcm9tIHRo ZSBzYW1lIGNsaWVudCwgaXQgd2lsbCB1c2VkIFRMUzEuMyBzdWNjZXNzZnVsbHkuIEkgdGhpbmsg dGhlIG9wZW5zc2wgZm9yIFRMUzEuMyB3b3JrcyB3ZWxsLgoKCgpIb3cgY2FuIEkgbWFrZSBzdXJl IG91ciBjbGllbnQgYW5kIHNlcnZlciBsaW5rIHRvIHRoZSBvcGVuc3NsID8gIEFuZCBjb3VsZCB5 b3UgcGxlYXNlICBzaG93IHlvdXIgY29uZmlndXJhdGlvbiBhYm91dCBUTFMgaW4gbGRhcC5jb25m IGFuZCBzbGFwLmNvbmYgdG8gbWUsIGlmIHlvdSBhcmUgY29udmVuaWVudC4KCgoKVGhhbmtzIGEg bG90LgoKCmJlc3QgcmVnYXJkcwoKbmFuY3kKCgoKCkF0IDIwMTgtMTAtMDkgMjE6NTY6MjMsICJR dWFuYWggR2lic29uLU1vdW50IiA8cXVhbmFoQHN5bWFzLmNvbT4gd3JvdGU6Cj4tLU9uIFR1ZXNk YXksIE9jdG9iZXIgMDksIDIwMTggMTA6MDIgQU0gKzAwMDAgbmFubW9yQDEyNi5jb20gd3JvdGU6 Cj4KPj4gV2UgY2FuIGdldCB0aGUgcmVzdWx0LCBidXQgZnJvbSBXaXJlc2hhcmsgcmVzdWx0LCB3 ZSBmaW5kIHRoYXQgdGhleSB1c2VkCj4+IFRMUzEuMiB0byBuZWdvdGlhdGVkLgo+Cj5JIGRvIG5v dCBmaW5kIHRoaXMgdG8gYmUgdGhlIGNhc2Ugd2l0aCBPcGVuTERBUCAyLjQuNDYuCj4KPj4gVGhl IG9wZW5TU0wgaXMgc3VwcG9ydCBmb3IgVExTMS4zLGhvd2V2ZXIgb3BlbmxkYXAtMi40LjQ2IGlz IHN0aWxsIHVzZWQKPj4gVExTMS4yIGJ5IGRlZmF1bHQuIE5lZWQgc29tZSBwYXJhbWV0ZXJzIHRv IHNwZWNpZnkgVExTMS4zIGluIG9wZW5sZGFwCj4+IGNvbmZpZ3VyYXRpb24/Cj4KPk5vcGUuCj4K Pj4gQnkgdGhlIHdheSwgSSBoYXZlIHRlc3RlZCB0aGF0IG90aGVyIGFwcGxpY2F0aW9uIGNhbiBu ZWdvdGlhdGVkIHdpdGgKPj4gVExTMS4zIGJ5IGRlZmF1bHQgd2hlbiB0aGUgY2xpZW50IGFuZCBz ZXJ2ZXIgYm90aCB1c2Ugb3BlbnNzbC0xLjEuMS4KPgo+VGhhdCBpcyB0aGUgYmVoYXZpb3IgSSBz ZWUuCj4KPk9wZW5MREFQIDIuNC40NiBsaW5rZWQgdG8gT3BlblNTTCAxLjEuMSBmb3IgYm90aCB0 aGUgY2xpZW50IGFuZCBzZXJ2ZXI6Cj4KPjViYmNiMjgyIGNvbm5lY3Rpb25fcmVhZCgxNCk6IGNo ZWNraW5nIGZvciBpbnB1dCBvbiBpZD0xMDAxCj5UTFMgdHJhY2U6IFNTTF9hY2NlcHQ6VExTdjEu MyBlYXJseSBkYXRhCj5UTFMgdHJhY2U6IFNTTF9hY2NlcHQ6U1NMdjMvVExTIHJlYWQgZmluaXNo ZWQKPlRMUyB0cmFjZTogU1NMX2FjY2VwdDpTU0x2My9UTFMgd3JpdGUgc2Vzc2lvbiB0aWNrZXQK PlRMUyB0cmFjZTogU1NMX2FjY2VwdDpTU0x2My9UTFMgd3JpdGUgc2Vzc2lvbiB0aWNrZXQKPgo+ UGVyaGFwcyB0aGUgbGRhcHNlYXJjaCB5b3UgcGlja2VkIHVwIHdhcyBub3QgdGhlIG9uZSBsaW5r ZWQgdG8gT3BlblNTTCAKPjEuMS4xLgo+Cj5Zb3UgbWF5IGFsc28gd2FudCB0byByZWFkIHRoZSBz bGFwZC5jb25mKDUpIG9yIHNsYXBkLWNvbmZpZyg1KSBtYW4gcGFnZXMgb24gCj5ob3cgdG8gc2V0 IGEgbWluaW11bSByZXF1aXJlZCBUTFMgcHJvdG9jb2wgdmVyc2lvbi4KPgo+UmVnYXJkcywKPlF1 YW5haAo+Cj4tLQo+Cj5RdWFuYWggR2lic29uLU1vdW50Cj5Qcm9kdWN0IEFyY2hpdGVjdAo+U3lt YXMgQ29ycG9yYXRpb24KPlBhY2thZ2VkLCBjZXJ0aWZpZWQsIGFuZCBzdXBwb3J0ZWQgTERBUCBz b2x1dGlvbnMgcG93ZXJlZCBieSBPcGVuTERBUDoKPjxodHRwOi8vd3d3LnN5bWFzLmNvbT4K ------=_Part_53823_903760140.1539140876552 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+SGkgUXVhbmFoLDwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+QWZ0ZXIgSSBzZXQgYSBwYXJhbWV0ZXIgaW4gc2VydmVyOiZuYnNwOyBUTFNQcm90b2NvbE1p biAzLjQsIHJlc3RhcnQgdGhlIGxkYXAgc2VydmVyLCBpdCB3b3JrcyB0aGF0IHRoZSBzZXJ2ZXIg d2lsbCBub3QgbmVnb3RpYXRlZCB3aXRoIGxvd2VyIFRMUyB2ZXJzaW9uLjxicj48L2Rpdj48ZGl2 Pkkgc2V0IHRoZSBwYXJhbWV0ZXIgaW4gY2xpZW50OiBUTFNfUFJPVE9DT0xfTUlOIDMuNCwgdGhl IGNsaWVudCBzdGlsbCBzdGFydCBhIGNsaWVudCBoZWxsbyB3aXRoIFRMUzEuMiwgaSBkb3VidCB0 aGF0IHRoZSBwYXJhbWV0ZXIgbm90IHdvcmsgaW4gbXkgY29uZmlndXJhdGlvbi48L2Rpdj48ZGl2 PmhlcmUgaXMgbXkgbGRhcC5jb25mOjwvZGl2PjxkaXY+PGJyPnNzbCBzdGFydF90bHM8YnI+VExT X0NBQ0VSVERJUiZuYnNwOyAvdXNyL2xvY2FsL2V0Yy9vcGVubGRhcC9jYWNlcnRzPGJyPlRMU19D QUNFUlQgL3Vzci9sb2NhbC9ldGMvb3BlbmxkYXAvY2FjZXJ0cy9jYWNlcnQucGVtPGJyPlRMU19S RVFDRVJUIG5ldmVyPGJyPlRMU19QUk9UT0NPTF9NSU4gMy40PGJyPiNTSVpFTElNSVQmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTI8YnI+I1RJTUVMSU1JVCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAxNTxicj4jREVSRUYmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbmV2ZXI8YnI+U0FTTF9OT0NBTk9OJm5ic3A7Jm5ic3A7 Jm5ic3A7IG9uPGJyPkJBU0UgY249bG9jYWxob3N0PGJyPmRlYnVnIDk8YnI+bG9jYWw0LiombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgL3Zhci9sb2cvbGRhcC5sb2c8L2Rpdj48ZGl2PkkgdXNlZCAib3BlbnNzbCBzX2NsaWVu dCAtY29ubmVjdCBteWRvbWFpbi5jb206NjM2IC10bHMxXzMiICZuYnNwOyB0byBjb25uZWN0IHRo ZSBzYW1lIHNlcnZlciBmcm9tIHRoZSBzYW1lIGNsaWVudCwgaXQgd2lsbCB1c2VkIFRMUzEuMyBz dWNjZXNzZnVsbHkuIEkgdGhpbmsgdGhlIG9wZW5zc2wgZm9yIFRMUzEuMyB3b3JrcyB3ZWxsLiA8 YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Ib3cgY2FuIEkgbWFrZSBzdXJlIG91ciBjbGll bnQgYW5kIHNlcnZlciBsaW5rIHRvIHRoZSBvcGVuc3NsID8mbmJzcDsgQW5kIGNvdWxkIHlvdSBw bGVhc2UmbmJzcDsgc2hvdyB5b3VyIGNvbmZpZ3VyYXRpb24gYWJvdXQgVExTIGluIGxkYXAuY29u ZiBhbmQgc2xhcC5jb25mIHRvIG1lLCBpZiB5b3UgYXJlIGNvbnZlbmllbnQuIDxicj48L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2PlRoYW5rcyBhIGxvdC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 PmJlc3QgcmVnYXJkcyA8YnI+PC9kaXY+PGRpdj5uYW5jeTxicj48L2Rpdj48YnI+PGRpdiBzdHls ZT0icG9zaXRpb246cmVsYXRpdmU7em9vbToxIj48L2Rpdj48ZGl2IGlkPSJkaXZOZXRlYXNlTWFp bENhcmQiPjwvZGl2PjxwcmU+PGJyPkF0IDIwMTgtMTAtMDkgMjE6NTY6MjMsICJRdWFuYWggR2li c29uLU1vdW50IiAmbHQ7cXVhbmFoQHN5bWFzLmNvbSZndDsgd3JvdGU6CiZndDstLU9uIFR1ZXNk YXksIE9jdG9iZXIgMDksIDIwMTggMTA6MDIgQU0gKzAwMDAgbmFubW9yQDEyNi5jb20gd3JvdGU6 CiZndDsKJmd0OyZndDsgV2UgY2FuIGdldCB0aGUgcmVzdWx0LCBidXQgZnJvbSBXaXJlc2hhcmsg cmVzdWx0LCB3ZSBmaW5kIHRoYXQgdGhleSB1c2VkCiZndDsmZ3Q7IFRMUzEuMiB0byBuZWdvdGlh dGVkLgomZ3Q7CiZndDtJIGRvIG5vdCBmaW5kIHRoaXMgdG8gYmUgdGhlIGNhc2Ugd2l0aCBPcGVu TERBUCAyLjQuNDYuCiZndDsKJmd0OyZndDsgVGhlIG9wZW5TU0wgaXMgc3VwcG9ydCBmb3IgVExT MS4zLGhvd2V2ZXIgb3BlbmxkYXAtMi40LjQ2IGlzIHN0aWxsIHVzZWQKJmd0OyZndDsgVExTMS4y IGJ5IGRlZmF1bHQuIE5lZWQgc29tZSBwYXJhbWV0ZXJzIHRvIHNwZWNpZnkgVExTMS4zIGluIG9w ZW5sZGFwCiZndDsmZ3Q7IGNvbmZpZ3VyYXRpb24/CiZndDsKJmd0O05vcGUuCiZndDsKJmd0OyZn dDsgQnkgdGhlIHdheSwgSSBoYXZlIHRlc3RlZCB0aGF0IG90aGVyIGFwcGxpY2F0aW9uIGNhbiBu ZWdvdGlhdGVkIHdpdGgKJmd0OyZndDsgVExTMS4zIGJ5IGRlZmF1bHQgd2hlbiB0aGUgY2xpZW50 IGFuZCBzZXJ2ZXIgYm90aCB1c2Ugb3BlbnNzbC0xLjEuMS4KJmd0OwomZ3Q7VGhhdCBpcyB0aGUg YmVoYXZpb3IgSSBzZWUuCiZndDsKJmd0O09wZW5MREFQIDIuNC40NiBsaW5rZWQgdG8gT3BlblNT TCAxLjEuMSBmb3IgYm90aCB0aGUgY2xpZW50IGFuZCBzZXJ2ZXI6CiZndDsKJmd0OzViYmNiMjgy IGNvbm5lY3Rpb25fcmVhZCgxNCk6IGNoZWNraW5nIGZvciBpbnB1dCBvbiBpZD0xMDAxCiZndDtU TFMgdHJhY2U6IFNTTF9hY2NlcHQ6VExTdjEuMyBlYXJseSBkYXRhCiZndDtUTFMgdHJhY2U6IFNT TF9hY2NlcHQ6U1NMdjMvVExTIHJlYWQgZmluaXNoZWQKJmd0O1RMUyB0cmFjZTogU1NMX2FjY2Vw dDpTU0x2My9UTFMgd3JpdGUgc2Vzc2lvbiB0aWNrZXQKJmd0O1RMUyB0cmFjZTogU1NMX2FjY2Vw dDpTU0x2My9UTFMgd3JpdGUgc2Vzc2lvbiB0aWNrZXQKJmd0OwomZ3Q7UGVyaGFwcyB0aGUgbGRh cHNlYXJjaCB5b3UgcGlja2VkIHVwIHdhcyBub3QgdGhlIG9uZSBsaW5rZWQgdG8gT3BlblNTTCAK Jmd0OzEuMS4xLgomZ3Q7CiZndDtZb3UgbWF5IGFsc28gd2FudCB0byByZWFkIHRoZSBzbGFwZC5j b25mKDUpIG9yIHNsYXBkLWNvbmZpZyg1KSBtYW4gcGFnZXMgb24gCiZndDtob3cgdG8gc2V0IGEg bWluaW11bSByZXF1aXJlZCBUTFMgcHJvdG9jb2wgdmVyc2lvbi4KJmd0OwomZ3Q7UmVnYXJkcywK Jmd0O1F1YW5haAomZ3Q7CiZndDstLQomZ3Q7CiZndDtRdWFuYWggR2lic29uLU1vdW50CiZndDtQ cm9kdWN0IEFyY2hpdGVjdAomZ3Q7U3ltYXMgQ29ycG9yYXRpb24KJmd0O1BhY2thZ2VkLCBjZXJ0 aWZpZWQsIGFuZCBzdXBwb3J0ZWQgTERBUCBzb2x1dGlvbnMgcG93ZXJlZCBieSBPcGVuTERBUDoK Jmd0OyZsdDtodHRwOi8vd3d3LnN5bWFzLmNvbSZndDsKPC9wcmU+PC9kaXY+PGJyPjxicj48c3Bh biB0aXRsZT0ibmV0ZWFzZWZvb3RlciI+PHA+Jm5ic3A7PC9wPjwvc3Bhbj4= ------=_Part_53823_903760140.1539140876552--

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs