November 2018 - openldap-bugs

Re: (ITS#8928) Reproducibility: Remove user, hostname, pwd from version string

by douglas.royds＠taitradio.com

URL: ftp://ftp.openldap.org/incoming/douglas-royds-181120.patch On 19/11/18 12:34 PM, Howard Chu wrote: > Thanks. According to this link, we shouldn't even need the date/time portion > of this patch. > > Under the section "Reading the Variable" we have >> gcc (>= 7, Debian >= 5.3.1-17, Debian >= 6.1.1-1) > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e3e8c48c4a494d9da741c1c... > > I.e., gcc itself will set __DATE__ and __TIME__ accordingly if SOURCE_DATE_EPOCH is set. > > I'm inclined to just tweak WHOWHERE and let gcc handle the rest. Once again, good point. I have removed the date and time changes from the patch, and only kept the WHOWHERE change, still using the existence of a SOURCE_DATE_EPOCH to decide whether to fix the string or not.

4 years, 10 months

1
0
0 / 0

Re: (ITS#8928) Reproducibility: Remove user, hostname, pwd from version string

by hyc＠symas.com

douglas.royds(a)taitradio.com wrote: > On 17/11/18 11:42 AM, Howard Chu wrote: > >> douglas.royds(a)taitradio.com wrote: >>> URL: ftp://ftp.openldap.org/incoming/douglas-royds-181026.patch >>> >>> This updated patch also sets the date and time strings to the >>> SOURCE_DATE_EPOCH. >> Are you intending a SOURCE_DATE_EPOCH to be a Unix time value? I.e., an integer? >> This value format needs to be documented. >> >> Unfortunately, your use of date -d is nonportable, it appears that only the GNU tools >> understand this option. It will fail on other platforms like *BSD, Solaris, that aren't >> using a GNU userland. >> >> Why can't you simply provide an already formatted date & time that can be used >> directly, instead of needing to be reformatted here? > > > URL: ftp://ftp.openldap.org/incoming/douglas-royds-181119.patch > > Good point about BSD, my mistake. I have modified the patch to support > BSD platforms as well, though I don't have access to a BSD platform to > test it. > > I have added a code comment with a link to the SOURCE_DATE_EPOCH > specification: https://reproducible-builds.org/specs/source-date-epoch/ > > A more human-readable description and tips for its use can be found > here: https://reproducible-builds.org/docs/source-date-epoch/ Thanks. According to this link, we shouldn't even need the date/time portion of this patch. Under the section "Reading the Variable" we have > gcc (>= 7, Debian >= 5.3.1-17, Debian >= 6.1.1-1) https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e3e8c48c4a494d9da741c1c... I.e., gcc itself will set __DATE__ and __TIME__ accordingly if SOURCE_DATE_EPOCH is set. I'm inclined to just tweak WHOWHERE and let gcc handle the rest. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

4 years, 10 months

1
0
0 / 0

Re: (ITS#8928) Reproducibility: Remove user, hostname, pwd from version string

by douglas.royds＠taitradio.com

On 17/11/18 11:42 AM, Howard Chu wrote: > douglas.royds(a)taitradio.com wrote: >> URL: ftp://ftp.openldap.org/incoming/douglas-royds-181026.patch >> >> This updated patch also sets the date and time strings to the >> SOURCE_DATE_EPOCH. > Are you intending a SOURCE_DATE_EPOCH to be a Unix time value? I.e., an integer? > This value format needs to be documented. > > Unfortunately, your use of date -d is nonportable, it appears that only the GNU tools > understand this option. It will fail on other platforms like *BSD, Solaris, that aren't > using a GNU userland. > > Why can't you simply provide an already formatted date & time that can be used > directly, instead of needing to be reformatted here? URL: ftp://ftp.openldap.org/incoming/douglas-royds-181119.patch Good point about BSD, my mistake. I have modified the patch to support BSD platforms as well, though I don't have access to a BSD platform to test it. I have added a code comment with a link to the SOURCE_DATE_EPOCH specification: https://reproducible-builds.org/specs/source-date-epoch/ A more human-readable description and tips for its use can be found here: https://reproducible-builds.org/docs/source-date-epoch/

4 years, 10 months

1
0
0 / 0

Re: (ITS#8936) SASL/SCRAM-SHA-1 bind returns other(80) instead of invalidCredentials (49) in case of wrong password

by quanah＠symas.com

--On Sunday, November 18, 2018 7:20 PM +0100 Michael Str=C3=B6der=20 <michael(a)stroeder.com> wrote: >> since they're working on getting the 2.1.27 release out anytime now >> and this should likely be fixed as a part of that release. > It seems they cut the release yesterday: > > ftp://ftp.cyrusimap.org/cyrus-sasl/ Nice, they said they were going to cut another RC first. Guess that went=20 out the window:=20 <https://lists.andrew.cmu.edu/pipermail/cyrus-devel/2018-November/004383.htm= l> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 years, 10 months

1
0
0 / 0

Re: (ITS#8936) SASL/SCRAM-SHA-1 bind returns other(80) instead of invalidCredentials (49) in case of wrong password

by michael＠stroeder.com

On 11/18/18 7:13 PM, Quanah Gibson-Mount wrote: > --On Sunday, November 18, 2018 5:48 PM +0000 hyc(a)symas.com wrote: >> Sounds like this is an issue for the Cyrus SASL project. Their plugin is >> returning a SASL_BADPROT error code on all failures, instead of a more >> meaningful code like SASL_BADAUTH. > > I opened <https://github.com/cyrusimap/cyrus-sasl/issues/545> Thanks. > since they're working on getting the 2.1.27 release out anytime now > and this should likely be fixed as a part of that release. It seems they cut the release yesterday: ftp://ftp.cyrusimap.org/cyrus-sasl/ Nevermind, I'm not using SASL password mechs for anything serious. Just stumbled across this while implementing a regression test for bad password in ldap0 module which explicitly checks that invalidCredentials(49) is returned. Ciao, Michael.

4 years, 10 months

1
0
0 / 0

Re: (ITS#8936) SASL/SCRAM-SHA-1 bind returns other(80) instead of invalidCredentials (49) in case of wrong password

by quanah＠symas.com

--On Sunday, November 18, 2018 5:48 PM +0000 hyc(a)symas.com wrote: > Sounds like this is an issue for the Cyrus SASL project. Their plugin is > returning a SASL_BADPROT error code on all failures, instead of a more > meaningful code like SASL_BADAUTH. I opened <https://github.com/cyrusimap/cyrus-sasl/issues/545> since they're working on getting the 2.1.27 release out anytime now and this should likely be fixed as a part of that release. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 years, 10 months

1
0
0 / 0

Re: (ITS#8936) SASL/SCRAM-SHA-1 bind returns other(80) instead of invalidCredentials (49) in case of wrong password

by hyc＠symas.com

michael(a)stroeder.com wrote: > Full_Name: > Version: 2.4.46 > OS: openSUSE Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.240.182.29) > > > SASL bind with SCRAM-SHA-1 does not return invalidCredentials (49) in case of a > wrong password being used while DIGEST-MD5 and other password mechs works as > expected. > > This might lead to different error handling in client applications if the user > input a wrong password. > > This proves SCRAM-SHA-1 is enabled and working: > > $ ldapwhoami -Y SCRAM-SHA-1 -U test42 -w test123 > SASL/SCRAM-SHA-1 authentication started > SASL username: test42 > SASL SSF: 0 > dn:uid=test42,ou=testing,dc=stroeder,dc=de > > But wrong password returns other(80) as result code: > > $ ldapwhoami -Y SCRAM-SHA-1 -U test42 -w wrong > SASL/SCRAM-SHA-1 authentication started > ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) > additional info: SASL(-5): bad protocol / cancel: StoredKey mismatch > > Now testing DIGEST-MD5: > > $ ldapwhoami -Y DIGEST-MD5 -U test42 -w test123 > SASL/DIGEST-MD5 authentication started > SASL username: test42 > SASL SSF: 128 > SASL data security layer installed. > dn:uid=test42,ou=testing,dc=stroeder,dc=de > > Wrong password returns invalidCredentials(49) as expected: > > $ ldapwhoami -Y DIGEST-MD5 -U test42 -w wrong > SASL/DIGEST-MD5 authentication started > ldap_sasl_interactive_bind_s: Invalid credentials (49) > additional info: SASL(-13): authentication failure: client response doesn't > match what we generated (tried bogus) Sounds like this is an issue for the Cyrus SASL project. Their plugin is returning a SASL_BADPROT error code on all failures, instead of a more meaningful code like SASL_BADAUTH. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

4 years, 10 months

1
0
0 / 0

Re: (ITS#8937) Possibly wrong MDB_DUPFIXED flag check

by hyc＠symas.com

juerg.bircher(a)gmail.com wrote: > Full_Name: Juerg Bircher > Version: LMDB master > OS: macOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (178.83.86.107) > > > In mdb_cursor_put the flag MDB_DUPFIXED is checked on line 7628 as follows: > > if ((mc->mc_db->md_flags & (MDB_DUPSORT|MDB_DUPFIXED)) > == MDB_DUPFIXED) > np->mp_flags |= P_LEAF2; > > Should it not be like this: > if (mc->mc_db->md_flags & MDB_DUPFIXED) > np->mp_flags |= P_LEAF2; No, the code is correct. > According to the documentation: > * <li>#MDB_DUPFIXED > * This flag may only be used in combination with #MDB_DUPSORT. That is documentation for users of the API. It does not dictate what LMDB does internally. > So the expression (mc->mc_db->md_flags & (MDB_DUPSORT|MDB_DUPFIXED)) == > MDB_DUPFIXED) would never match. False. There's no bug here. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

4 years, 10 months

1
0
0 / 0

(ITS#8937) Possibly wrong MDB_DUPFIXED flag check

by juerg.bircher＠gmail.com

Full_Name: Juerg Bircher Version: LMDB master OS: macOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (178.83.86.107) In mdb_cursor_put the flag MDB_DUPFIXED is checked on line 7628 as follows: if ((mc->mc_db->md_flags & (MDB_DUPSORT|MDB_DUPFIXED)) == MDB_DUPFIXED) np->mp_flags |= P_LEAF2; Should it not be like this: if (mc->mc_db->md_flags & MDB_DUPFIXED) np->mp_flags |= P_LEAF2; According to the documentation: * <li>#MDB_DUPFIXED * This flag may only be used in combination with #MDB_DUPSORT. So the expression (mc->mc_db->md_flags & (MDB_DUPSORT|MDB_DUPFIXED)) == MDB_DUPFIXED) would never match.

4 years, 10 months

1
0
0 / 0

(ITS#8936) SASL/SCRAM-SHA-1 bind returns other(80) instead of invalidCredentials (49) in case of wrong password

by michael＠stroeder.com

Full_Name: Version: 2.4.46 OS: openSUSE Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.240.182.29) SASL bind with SCRAM-SHA-1 does not return invalidCredentials (49) in case of a wrong password being used while DIGEST-MD5 and other password mechs works as expected. This might lead to different error handling in client applications if the user input a wrong password. This proves SCRAM-SHA-1 is enabled and working: $ ldapwhoami -Y SCRAM-SHA-1 -U test42 -w test123 SASL/SCRAM-SHA-1 authentication started SASL username: test42 SASL SSF: 0 dn:uid=test42,ou=testing,dc=stroeder,dc=de But wrong password returns other(80) as result code: $ ldapwhoami -Y SCRAM-SHA-1 -U test42 -w wrong SASL/SCRAM-SHA-1 authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-5): bad protocol / cancel: StoredKey mismatch Now testing DIGEST-MD5: $ ldapwhoami -Y DIGEST-MD5 -U test42 -w test123 SASL/DIGEST-MD5 authentication started SASL username: test42 SASL SSF: 128 SASL data security layer installed. dn:uid=test42,ou=testing,dc=stroeder,dc=de Wrong password returns invalidCredentials(49) as expected: $ ldapwhoami -Y DIGEST-MD5 -U test42 -w wrong SASL/DIGEST-MD5 authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: client response doesn't match what we generated (tried bogus)

4 years, 10 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2018