openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

regression from ITS#8042
by hyc＠openldap.org 29 Aug '15

29 Aug '15

Full_Name: Howard Chu Version: 2.4.41 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (73.15.219.210) Submitted by: hyc presentlist_find() can SEGV if called when si->si_presentlist is NULL.

1 0

Re: (ITS#8230) [PATCH] totp: bug fixes and improvements
by hyc＠symas.com 29 Aug '15

29 Aug '15

peter(a)adpm.de wrote: > Full_Name: Peter Marschall > Version: 2.4.42 > OS: Linux > URL: https://github.com/marschap/openldap/tree/contrib-totp > Submission from: (NULL) (92.211.7.6) > > > Hi, > > I have written some bugfixes & flexibilizations for the TOTP contrib module. > > You can find them in the github branch: > https://github.com/marschap/openldap/tree/contrib-totp > > It differs from today's master by these commits: > * https://github.com/marschap/openldap/commit/d67bffc4a361cecfce69fb4d14edb33… > contrib/passwd/totp: flexibilize decoding key > > In function totp_b32_pton() > - allow lowercase characters in encoded string too This patch is incorrect. You must guard toupper(), it is not guaranteed not to distort non-lowercase characters. if (islower(x)) x = toupper(x) > - allow padding to be omitted (totally, not only parts) Why? > In function chk_totp() determine the space required to hold the decoded > key by calling totp_b32_pton() with a NULL argument for the target. > > * https://github.com/marschap/openldap/commit/435976d4f2468946bd0c5081ce7e2ae… > contrib/passwd/totp: fix the big-endian case > > For the big-endian case, 'msg' wasn't set from 'tval' in generate(). This patch is wrong, as I commented on github. > * https://github.com/marschap/openldap/commit/04c15b7b1e44d4d3167577702a8b77c… > contrib/passwd/totp: fix decoding when padding is used > > In totp_b32_pton(), correctly count the number of '=' padding chars > at the end of the base-32 encoded string. > > Note: '*str++' evaluates *str first and increases str later! The current code correctly decodes known test data. What is your test case? > * https://github.com/marschap/openldap/commit/04c15b7b1e44d4d3167577702a8b77c… > contrib/passwd/totp: support compiling using nettle The proper way to add this support is to add macros to hide all of the differences in the initial ifdef block and not to add any additional ifdefs anywhere in the main body of the code. > > that change the file > contrib/slapd-modules/passwd/totp/slapd-totp.c | 67 > ++++++++++++++++++B%B++++++++++++++++++++++++++++++++++++------------ > > I'd appreciate if you include them into OpenLDAP. > > The referenced patch files are derived from OpenLDAP Software. > All of the modifications to OpenLDAP Software represented in the following > patch(es) were developedy y Peter Marschall <peter(a)adpm.de>. > I have not assigned rights and/or interest in this work to any party. > > The referenced modifications to OpenLDAP Software are subject to the following > notice: > Copyright 2015 Peter Marschall > Redistribution and use in source and binary forms, with or without > modification, > are permitted only as authorized by the OpenLDAP Public License. > > Thanks in advance > Peter > > -- -- 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#8230) [PATCH] totp: bug fixes and improvements
by peter＠adpm.de 29 Aug '15

29 Aug '15

Full_Name: Peter Marschall Version: 2.4.42 OS: Linux URL: https://github.com/marschap/openldap/tree/contrib-totp Submission from: (NULL) (92.211.7.6) Hi, I have written some bugfixes & flexibilizations for the TOTP contrib module. You can find them in the github branch: https://github.com/marschap/openldap/tree/contrib-totp It differs from today's master by these commits: * https://github.com/marschap/openldap/commit/d67bffc4a361cecfce69fb4d14edb33… contrib/passwd/totp: flexibilize decoding key In function totp_b32_pton() - allow lowercase characters in encoded string too - allow padding to be omitted (totally, not only parts) In function chk_totp() determine the space required to hold the decoded key by calling totp_b32_pton() with a NULL argument for the target. * https://github.com/marschap/openldap/commit/435976d4f2468946bd0c5081ce7e2ae… contrib/passwd/totp: fix the big-endian case For the big-endian case, 'msg' wasn't set from 'tval' in generate(). * https://github.com/marschap/openldap/commit/04c15b7b1e44d4d3167577702a8b77c… contrib/passwd/totp: fix decoding when padding is used In totp_b32_pton(), correctly count the number of '=' padding chars at the end of the base-32 encoded string. Note: '*str++' evaluates *str first and increases str later! * https://github.com/marschap/openldap/commit/04c15b7b1e44d4d3167577702a8b77c… contrib/passwd/totp: support compiling using nettle that change the file contrib/slapd-modules/passwd/totp/slapd-totp.c | 67 ++++++++++++++++++B%B++++++++++++++++++++++++++++++++++++------------ I'd appreciate if you include them into OpenLDAP. The referenced patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developedy y Peter Marschall <peter(a)adpm.de>. I have not assigned rights and/or interest in this work to any party. The referenced modifications to OpenLDAP Software are subject to the following notice: Copyright 2015 Peter Marschall Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. Thanks in advance Peter

1 0

Re: (ITS#8229) ldapsearch: report failed search results to stderr even when ldif == 0
by ryan＠nardis.ca 28 Aug '15

28 Aug '15

On Fri, Aug 28, 2015 at 11:23:50PM +0200, Hallvard Breien Furuseth wrote: >We should be wary of changing ldapsearch output, since >people parse it in scripts. Good point. Adding a stderr message to the existing stdout message would safer. Still not as safe as no change, of course. >I do find the output quirky and would have liked it different. >Maybe yet another option could clean it up, or an -o flag similar >to ldif-wrap. Yet another option... :)

1 0

(ITS#8229) ldapsearch: report failed search results to stderr even when ldif == 0
by ryan＠openldap.org 28 Aug '15

28 Aug '15

Full_Name: Ryan Tandy Version: master OS: Debian URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan Forwarded from a Debian bug report: <https://bugs.debian.org/474021> ldapsearch's error reporting currently does this: $ ldapsearch -x -b dc=nonexistent > /dev/null $ ldapsearch -x -b dc=nonexistent -L > /dev/null No such object (32) $ ldapsearch -x -b dc=nonexistent -LL > /dev/null No such object (32) $ ldapsearch -x -b dc=nonexistent -LLL > /dev/null No such object (32) The submitter would like it to report the failure to stderr in the default case as well. He suggested this change: - if( !ldif ) { - printf( "result: %d %s\n", err, ldap_err2string(err) ); - } else if ( err != LDAP_SUCCESS ) { - fprintf( stderr, "%s (%d)\n", ldap_err2string(err), err ); + if ( err != LDAP_SUCCESS %2%7{ + fprintf( stderr, "Search failed: %s (%d)\n", ldap_err2string(err), err ); + } + + if ( !ldif ) { + printf( "result: %d %s\n", err, ldap_err2string(err) ); } I would probably just flip the cases, and keep the "else" (i.e. not duplicate the output): - if( !ldif ) { - printf( _("result: %d %s\n"), err, ldap_err2string(err) ); - - } else if ( err != LDAP_SUCCESS ) { + if ( err != LDAP_SUCCESS ) { fprintf( stderr, "%s (%d)\n", ldap_r2ststring(err), err ); + } else if( !ldif ) { + printf( _("result: %d %s\n"), err, ldap_err2string(err) ); } Does either of these changes sound appropriate? The submitter also suggested sending the LDAP_SYNC Cancelled message to stderr: if ( cancel_msgid != -1 && cancel_msgid == ldap_msgid( msg ) ) { printf(_("Cancelled \n")); printf(_("cancel_msgid = %d\n"), cancel_msgid); I don't know that area very well, but at a glance it seems like stdout is probably more appropriate (so no change needed). Thanks.

1 0

Re: (ITS#8209) Broken MDB_CP_COMPACT threading
by h.b.furuseth＠usit.uio.no 28 Aug '15

28 Aug '15

More: MDB_CP_COMPACT would drop a new, empty main DB. (I.e. the main DB would lose its flags.) Compacting can verify that the written metapage claims enough DB pages. But not the opposite - it should not fail if it claims too many pages since that would mean we can't compact a DB which has suffered page leaks. We could detect that and re-write the metas at the end, if the user requests it and the file is seekable.

1 0

(ITS#8228) avoid clobbering a valid pid file
by ryan＠openldap.org 28 Aug '15

28 Aug '15

Full_Name: Ryan Tandy Version: master OS: Debian URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan Forwarding a feature request from <https://bugs.debian.org/375067>: It would be nice if slapd would notice an existing pid file pointing at a live process, and refuse to overwrite it. Starting slapd twice with the same pidfile is certainly user error, but it seems like it should be preventable.

1 0

RE: (ITS#8222) memory administration in ldap_parse_result()
by Lawrence.Newman＠alcatel-lucent.com 27 Aug '15

27 Aug '15

Providing an update: Not surprisingly, the actual memory leak was in our a= pplication software (error message allocated by ldap_parse_result() not fre= ed in unusual case). But our debugging/analysis tools continued to report = memory allocated but not freed even after the problem was fixed, and I beli= eve that was due to the issue I reported with how internal (library) memory= linked to the LDAP structure is allocated/freed by ldap_parse_result() (al= located while processing a response, but not freed until the next time the = connection associated with that LDAP structure is used). Larry Newman IHN 9H-401, x90882 lawrence.newman(a)alcatel-lucent.com -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org]=20 Sent: Tuesday, August 25, 2015 10:15 AM To: Newman, Lawrence H (Lawrence) Subject: Re: (ITS#8222) memory administration in ldap_parse_result() *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report = has been assigned the tracking number ITS#8222. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunte= ers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue repo= rt, you may do so by replying to this message. Note that any mail sent to = openldap-its(a)openldap.org with (ITS#8222) in the subject will automatically= be attached to the issue report. mailto:openldap-its@openldap.org?subject=3D(ITS#8222) You may follow the progress of this report by loading the following URL in = a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=3D8222 Please remember to retain your issue tracking number (ITS#8222) on any furt= her messages you send to us regarding this report. If you don't then you'l= l just waste our time and yours because we won't be able to properly track = the report. Please note that the Issue Tracking System is not intended to be used to se= ek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

Re: Re: (ITS#8223) Replication error when slave is down and insert on master are made
by quanah＠zimbra.com 27 Aug '15

27 Aug '15

--On Thursday, August 27, 2015 11:56 AM +0200 Frank Offermanns <Frank.Offermanns(a)caseris.de> wrote: > Hello, > > I have additional information. The problem is the entryCSN. > User 1, which got replicated has entryCSN: > 20150827083333.751721Z#000000#001#000000 > user 2, which got NOT replicated has entryCSN: > 20150827083333.119585Z#000000#001#000000, which seems to be in the past > user 3, replicated, 20150827083334.847604Z#000000#001#000000 > user 4, not replicated 20150827083334.228113Z#000000#001#000000, which > seems to be in the past > user 5, replicated 20150827083335.588191Z#000000#001#000000 > user 6, replicated 20150827083335.946835Z#000000#001#000000 > user 7 not replicated 20150827083335.282686Z#000000#001#000000, which > seems to be in the past > > So in previous posts I got the answer, that microseconds exact time > synchronization is only important with master master and concurrent > writes. But now it also seems to be important with delta-synrepl. > > So I suppose this ITS can be closed, since it is not a bug, but worked as > designed? > So how to get a good enough time synchronization with windows (since the > normal time synchronization of windows seems to be not enough)? > Of course, if you close the ITS I can ask this question again in the > technical list. Ah, yeah, all replication (delta-sync or regular syncrepl) absolutely requires tight time sync. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8227) syncprov should use more threads
by hyc＠openldap.org 27 Aug '15

27 Aug '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (70.87.222.79) Submitted by: hyc Currently a single background thread and output queue is used by syncprov to send persist messages to all consumers. A single slow consumer can block messages from being sent to other consumers. syncprov should be enhanced to use a separate queue and thread per consumer.

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