openldap-devel January 2020

openldap-devel@openldap.org

8 participants
7 discussions

asserts and manadatory build instructions (was ITS#8240)
by Michael Ströder 04 Nov '21

04 Nov '21

hyc(a)symas.com wrote in ITS#8240: > Our patch response was too hasty. There is no OpenLDAP bug here, the real > issue is production binaries being built with asserts enabled instead of > compiling with -DNDEBUG. That's an issue for packagers and distros to resolve. > Closing this ITS, not an OpenLDAP bug. Maybe I missed something. But this is the first time I've heard about -DNDEBUG being mandatory when compiling binary packages for production use. Does it have other effects? And what are general rules for assert statements in OpenLDAP code? In my own (Python) code assert statements are supposed to be only triggered if something goes wrong *internally* (type issues etc.). If somebody manages to trigger an assert statement with invalid input from "outside" I always consider this to be a serious bug revealing insufficient error handling even though e.g. web2ldap just logs the exception but won't crash. YMMV, but please clarify. I also wonder whether there are more mandatory rules for building packages and where I can find them. Please don't get me wrong: My inquiry is in good faith to avoid unnecessary ITS based on misunderstanding. Ciao, Michael.

1 1

New release policy for OpenLDAP
by Quanah Gibson-Mount 29 Jan '20

29 Jan '20

There's been ongoing discussion about making changes to the current release strategy with OpenLDAP. Traditionally we've (for the most part) kept new features out of the release branch and did our best to primarily focus on bug fixes only. There have clearly been exceptions when warranted (such as support for LMDB, etc). However, this policy has had the effect of keeping significant improvements from being made readily available to end users of the software. To address this, we're looking at implementing the following: Starting with OpenLDAP 2.5, the OpenLDAP project will use a new release process. Odd numbered releases will contain only bug fixes Even numbered releases will allow for minor new features This will allow for end users who want stability to focus on odd numbered releases while allowing those who need/want newer features to be able to make use of them. Constructive responses to the new release strategy welcome. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

7 16

Re: New release policy for OpenLDAP
by Hugh McMaster 28 Jan '20

28 Jan '20

On Wed, 29 Jan 2020 at 05:46, Quanah Gibson-Mount wrote: > But my point was, I think it’s a fallacy to tie software quality and > frequency of releases. I encounter way too much software today that > releases frequently, but what it releases is poorly (or not at all) QA'd, > etc. And it's a nightmare to deal with. I'd rather they slowed down and > got their software in better shape than constantly release, well, crap. No-one was suggesting a two-week release cycle (e.g. Wine) or three major releases a year (e.g. ICU). But there comes a point where simply releasing bug fixes (although very important for stability) for many years at a time delays the release of important other work. That’s what Howard wants to address with this change. Out of interest, what frequency of minor and patch release do believe is appropriate for this project? Hugh

1 0

Re: New release policy for OpenLDAP
by Gavin Henry 24 Jan '20

24 Jan '20

> Odd numbered releases will contain only bug fixes > Even numbered releases will allow for minor new features > > This will allow for end users who want stability to focus on odd numbered > releases while allowing those who need/want newer features to be able to > make use of them. > > Constructive responses to the new release strategy welcome. > Sounds good! Although odd numbers seems to feel like something risky, i.e. a new feature, whereas even numbers feel nice and comfy, boring and just bug fixes. Maybe just me! Gavin. -- Kind Regards, Gavin Henry.

1 1

OpenLDAP BoF session at FOSDEM?
by Michael Ströder 16 Jan '20

16 Jan '20

HI! Is anyone of the OpenLDAP devs around at FOSDEM this year? Would it make sense to apply for a BoF session room to discuss things face-to-face? Ciao, Michael.

3 2

2.4 commit review
by Quanah Gibson-Mount 11 Jan '20

11 Jan '20

A few commits stacking up, so would like to review them for inclusion in an eventual 2.4.49. I think all of the following look good for RE24, but wanted to confirm specifically on (a) the GnuTLS changes, (b) the cleaner error handling during connection setup, and (c) the Totp changes. OpenLDAP: ITS#9067 fix syntax evaluation of preferredDeliveryMethod ITS#8753 Set minimum GnuTLS version to 3.2.2 ITS#9071 Document "tls none" for back-ldap ITS#9069 Do not call gnutls_global_set_mutex() ITS#9077 slapo-unique Let the loop finish ITS#9095 insert missing commit at end of slapindex processing ITS#9091 drop attr mappings added in an aborted txn ITS#9100 relax domainScope check for absent value ITS#9112 cleaner error handling during connection setup Contrib: Totp: ITS#9055 Introduce a combined password scheme TotP: ITS#9055 Accept previous token LMDB: ITS#9068 fix backslash escaping Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

5 9

ldap0 does not work with RE24
by Michael Ströder 03 Jan '20

03 Jan '20

HI! It seems I'm experiencing a regression when running tests of python-ldap0 with current RE24 which does not fail with 2.4.48: test016_cancel (__main__.Test00_LDAPObject) ... munmap_chunk(): invalid pointer ERROR There was this change for ITS#9124. So I guess it's causing this regression. Could someone look into this? Ciao, Michael.

2 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel January 2020