openldap-devel January 2018

openldap-devel@openldap.org

9 participants
9 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

Beginner projects
by Lawrence, Andy 21 Apr '18

21 Apr '18

Hi, Me and one of my colleagues are interested in contributing to OpenLDAP. Do you have any interesting projects that new comers such as myself could work on? With best regards, Dr Andrew Lawrence Siemens Rail Automation Holdings Limited MO MM R&D UK IXL 17 Langley Park Way Chippenham SN15 1GG, United Kingdom mailto:andrew.lawrence@siemens.com www.siemens.com/rail-automation<http://www.siemens.com/rail-automation> www.siemens.com/ingenuityforlife<https://siemens.com/ingenuityforlife> www.siemens.com/ingenuityforlife Siemens Rail Automation Holdings Limited - registered office: Faraday House, Sir William Siemens Square, Frimley Camberley GU16 8QD. Registered No. 00016033

3 5

Jitterbugs to Bugzilla migration dev instance for testing
by Quanah Gibson-Mount 31 Jan '18

31 Jan '18

For the last several months I've been working on migrating the OpenLDAP project infrastructure to new systems. The server housing git-master was the first to be migrated, and was done late last year. The final server to be migrated is a bit more challenging, as it contains all of the public facing aspects of the project (ftp, git (RO), ITS (jitterbugs), FAQ, wiki, mailman, etc). As a part of the transition to the new hardware, the plan is to retire jitterbugs and migrate it to bugzilla. As a part of this process, I've been working on a development instance so I could work out the details of how I anticipate the migrated bug system to look. I would like to invite list members to look at the new system and provide feedback. It can be found at: <https://quanah.ddns.net/bugzilla> Please note that the dev system is not hooked up to an MTA, so any time it reports that it is sending an email it is not doing so (Instead it writes to a file on disk that I can use to ensure that the generated emails are correct). If you want to know what sort of email was generated by an action, let me know and I will look it up. Also note that the code to do the initial import has to pick a single email address to record as the person who created the bug (and all follow ups). In part because none of those accounts exist in the DB. I've ensured that the "From" information is preserved, and as time allows and accounts are created, I will work on updating the underlying database to correct the information on who filed the old bug reports. New bug reports will of course be tied to the actual account of the individual who files them. So for all currently existing bugs, I am recorded as the individual who filed the bug report. ----------- Difference highlights ----------- a) Integration with GitHub authentication When someone arrives at the splash screen, they have a choice -- They can either create a new local account (via the "New Account" link), or they can click the "Sign in" button to create an account that is linked via GitHub. I will be working on customizing this front page so that it's more apparent that you can create an account using the "Sign in" button, as that's not clear right now. b) product/component design Bugzilla is organized around the concept of Products and components that make up that product. The jitterbugs system really had no organizing concept. In the process of migrating, I've reworked the jitterbugs categories into components of related products where applicable, and "type" based categories are now migrated to an appropriate severity type. The Bugzilla instance has the following Products: JLDAP (Components: JDBC, JLDAP) LMDB (Component: liblmdb) OpenLDAP (Components: backends, build, contrib, documentation, libraries, overlays, slapd) Website (Component: website) Jitterbugs was comprised of the following categories: Build (Now OpenLDAP/build) Contrib (Now OpenLDAP/contrib) Development (Now a severity of "development") Documentation (Now OpenLDAP/documentation) Historical (Not tracked as a separate item, unnecessary) Incoming (Not tracked as a separate item, unnecessary) Software Bugs (Not tracked as a separate item, unnecessary) Software Enhancements (Now a severity of "enhancement") Web (Now Website/website) The re-organization allows a better ability to track bugs while retaining useful type information. With the product/component focus, reports can now be better directed into the appropriate location. c) Groups support -- Bugzilla has an excellent concept of groups, and the ability to give different groups different permissions. This could allow, for example, a group of privileged users who have the capability to help triage bugs. Currently there is only a single group for the developers, while any other account is a "normal" user account. The ability to have groups allows us to make it possible for people to file "private" bugs that are easily found by the development group, including the ability for those bugs to go to a developers only list. The way the system is currently set up, it will (fake) email a private list for all private bugs & private comments, and (fake) mail all public bugs/comments to openldap-its(a)openldap.org. This allows us to preserve the long time functionality of public notifications via openldap-its(a)openldap.org while adding the ability for the dev team to immediately be updated to new private bugs & comments. d) Milestones -- Bugzilla allows the creation and use of milestones. This is extremely helpful for both the developers and end users, as it becomes possible to easily query these milestones for information on such things as what was in a release, what will be in the next release, and what is slated for future development. For example, the "Search" link can be used to generate the following queries: All bugs released with OpenLDAP 2.4.45: <https://quanah.ddns.net/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_st atus=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFI ED&product=OpenLDAP&query_format=advanced&resolution=---&resolution=FIXED&r esolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSF ORME&resolution=PARTIAL&resolution=SUSPENDED&resolution=FEEDBACK&resolution =TEST&target_milestone=2.4.45> All bugs currently scheduled for OpenLDAP 2.4.46: <https://quanah.ddns.net/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_st atus=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFI ED&product=OpenLDAP&query_format=advanced&resolution=---&resolution=FIXED&r esolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSF ORME&resolution=PARTIAL&resolution=SUSPENDED&resolution=FEEDBACK&resolution =TEST&target_milestone=2.4.46> All bugs currently scheduled for inclusion with the OpenLDAP 2.5 initial release: <https://quanah.ddns.net/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_st atus=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFI ED&product=OpenLDAP&query_format=advanced&resolution=---&resolution=FIXED&r esolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSF ORME&resolution=PARTIAL&resolution=SUSPENDED&resolution=FEEDBACK&resolution =TEST&target_milestone=OpenLDAP_2_5> Note that this is all work I've entered by hand, so various bugs may be missing from the above queries. e) versions -- Bugzilla has a clear concept of versions for each product. This means now that people can select (when filing a bug) what version they are reporting against. You could always enter this information in by hand in jitterbugs, but the major difference here now is that it is possible to use this to generate queries. So you could, for example, do a search to find all bugs reported against 2.4.43. <https://quanah.ddns.net/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_st atus=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFI ED&list_id=124&product=OpenLDAP&query_format=advanced&resolution=---&resolu tion=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resol ution=WORKSFORME&resolution=PARTIAL&resolution=SUSPENDED&resolution=FEEDBAC K&resolution=TEST&version=2.4.43> f) bug states -- Jitterbugs was fairly limited in the state options that could be chosen (Open, Active, Suspended, Feedback, Test, Release, Partial, Closed). This was certainly customizable (and had been customized beyond the defaults), but lacks a level of granularity available with Bugzilla. With Bugzilla, there is always a primary state, and potentially a secondary state. These states are: UNCONFIRMED -> Newly filed bug that has not been acted upon by the project. All bug reports start in this state CONFIRMED -> Someone in the project has confirmed this is a valid report. IN_PROGRESS -> Someone in the project is actively working on the report. RESOLVED -> Issue has some type of secondary resolution. These are: FIXED -> Issue is fixed and integrated into the release branch for the next upcoming release INVALID -> Bug report is invalid WONTFIX -> There are no plans to fix this report (Generally to be used with bug reports for historic releases) DUPLICATE -> Duplicate of an existing bug (Which is entered as a part of the process. See <https://quanah.ddns.net/bugzilla/show_bug.cgi?id=8765> for an example) WORKSFORME -> Developer(s) unable to reproduce the problem report PARTIAL -> Some of the work in the bug was completed. Other work is still pending. My long term goal is to move all unfinished work for all of the resolved/partial bugs into new bugs to be tracked separately, and then close these out with a See Also reference (More on "See Also" further down) SUSPENDED -> Developer(s) have suspended working on this issue FEEDBACK -> Developer(s) are soliciting feedback from the reporter before continuing to work on the issue TEST -> Developer(s) have committed VERIFIED -> Issue is considered complete. It has the same secondary resolutions as RESOLVED. One slight difference noted below FIXED -> Issue is fixed, and is part of a released version of OpenLDAP Note that for the bugs that have been imported, some of these states may not be accurate due to the limitations of how items can be mapped. g) attachment support -- Currently we require people to upload patches, etc, to the OpenLDAP FTP site. Bugzilla allows attachments to be made directly as a part of submitting or updating a bug. This should allow the FTP server to only be used for large files (such as core dumps), and mostly retired. It also makes it simpler to ensure patches are kept with bug reports (We've lost patches people have provided in the past via URLs that no longer exist). It is possible to make attachments "private" as well, to help protect sensitive data. h) git integration -- One of the things on my to-do list post migration is to set up git integration. This means that when a developer makes a commit that references an existing bug report, that commit will automatically be added as a comment to the bug. This will make it easy for people who are interested in what the fix to an issue was to find said commit and examine the change(s). i) Potential future plans -- Mozilla has developed an addon service for Bugzilla that allows GitHub PR reports to be attached to open bug reports (https://github.com/mozilla/github-bugzilla-pr-linker ). I could see how this would be useful to have, as many people do their development work on GitHub and are annoyed at the process of having to directly provide a patch to the project. For developers, I'm also looking at a utility that allows those in the development group to manipulate bugs via the git command line (https://github.com/mozilla/git-bz-moz/blob/master/git-bz.txt). My goal is to have this working prior to a migration occurring. j) Major differences -- Currently correspondance between those who report a bug and the project team is done via email, using TO or CC the openldap-its(a)openldap.org email list. This has been problematic over the course of time, whether from Spam getting into the system (largely mitigated now via making the list moderated), replies not making it into the ITS system due to a failure to CC the openldap-its(a)openldap.org email list, or people who reported the issue never receiving a reply (thus not knowing the issue was being worked on) because the reply was only sent to the openldap-its(a)openldap.org email list. It is possible to setup an email->BZ gateway, but the format is a bit arcane, and I'd like to avoid that if possible. I would love to get feedback from those folks on the list as to their thoughts about this. k) URL field -- Bugzilla has a URL field that can be filled out to point to a URL containing additional relevant information. (Example: <https://quanah.ddns.net/bugzilla/show_bug.cgi?id=8766>) l) See Also field -- With Bugzilla, it is possible to provide references to other related bugzilla bug reports, including in Bugzilla instances run by other organizations. Examples: <https://quanah.ddns.net/bugzilla/show_bug.cgi?id=6138> (See Also's to related bugs in the OpenLDAP BZ) <https://quanah.ddns.net/bugzilla/show_bug.cgi?id=6304> (See Also to RedHat's BZ) Thanks for your time, and I look forward to the feedback. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 1

Beginner project: password quality checker
by Howard Chu 19 Jan '18

19 Jan '18

A simple password quality checker module for the ppolicy overlay - search for the given password in a list of already-breached passwords. You can get a starting list here https://www.troyhunt.com/introducing-306-million-freely-downloadable-pwned-… -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

VC exop and LDAPWhoAmI?
by Ondřej Kuzník 19 Jan '18

19 Jan '18

Trying to get SASL bind support into the Load Balancer now and a bit stuck when it comes to figuring out what the resulting authorisation identity is (SASL or LDAP say it's backend specific) for use with the proxyauthz control. Passing the binds on is the simple one, we can just send an LDAPWhoAmI after a successful result and we're set. If the backends support the VC extended operation, we want to use that, since that doesn't necessarily tie up a connection for each active bind. In that case, there is no way to get the authzId out. What is the best way to amend the VC spec? I would think adding another optional boolean field "return authzid" might be preferable. Setting it would have the server return a new field in the response containing the authorisation identity (maybe letting the server return it anyway, but that mightn't do good things to backward compatibility). A new control might be another option, that control could then be attached to bind requests as well I guess to obviate the need to send LDAPWhoAmI afterwards. This might be of use for applications that have a similar usecase: use VC Exop and then attach the proxyauthz control to operations performed on each of its client's behalf. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 1

RE: Beginner projects
by Lawrence, Andy 17 Jan '18

17 Jan '18

You have used the deprecated -h option. Would it really be beneficial to fix this? Best wishes, Andrew -----Original Message----- From: Alexandre Rosenberg [mailto:arekkusu@r42.ch] Sent: 10 January 2018 09:29 To: Lawrence, Andy (MO MM R&D UK IXL) Subject: Re: Beginner projects Hi, Just a user and not really in a position to tell you what to work on. Still, I think looking at the pending ITS/bug might be be nice. Shameless plug of my (easily reproducible) bug report: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8618 Best, Alex On 01/09/2018 11:58 PM, Lawrence, Andy wrote: > Hi, > > > > Me and one of my colleagues are interested in contributing to OpenLDAP. Do you have any interesting projects that new comers such as myself could work on? > > > > With best regards, > Dr Andrew Lawrence > > Siemens Rail Automation Holdings Limited MO MM R&D UK IXL > 17 Langley Park Way > Chippenham SN15 1GG, United Kingdom > mailto:andrew.lawrence@siemens.com > www.siemens.com/rail-automation<http://www.siemens.com/rail-automation > > > www.siemens.com/ingenuityforlife<https://siemens.com/ingenuityforlife> > www.siemens.com/ingenuityforlife > Siemens Rail Automation Holdings Limited - registered office: Faraday > House, Sir William Siemens Square, Frimley Camberley GU16 8QD. > Registered No. 00016033 > > > >

2 2

Re: Jitterbugs to Bugzilla migration dev instance for testing
by Gavin Henry 16 Jan '18

16 Jan '18

Great work! Will have a look around.

1 0

RE: Beginner projects
by Lawrence, Andy 15 Jan '18

15 Jan '18

Does OpenLDAP contain an XML parser? Cheers, Andrew -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: 14 January 2018 18:39 To: Lawrence, Andy (MO MM R&D UK IXL) Subject: Re: Beginner projects Lawrence, Andy wrote: > What is involved in the project "Add DSML capabilities to command line tools". Does this basically involve modifying ldapsearch so that it can produce the results in the DSML XML format and ldapmodify so it can take this format as input? Yes, sounds like it. By the way, please ask these questions on the -devel mailing list so that other people can chime in. > > Andrew > > -----Original Message----- > From: Howard Chu [mailto:hyc@symas.com] > Sent: 14 January 2018 10:52 > To: Lawrence, Andy (MO MM R&D UK IXL) > Subject: Re: Beginner projects > > Lawrence, Andy wrote: >> Hi Howard, >> >> I have been looking at the todo file. >> >> Re the small project "Recode linked-list structs to use <ldap_queue.h> macros", is ldaplist the struct being replaced by the new macros? > > Actually I would ignore that project. I'm not a fan of the ldap_queue.h macros; that was one of Kurt's ideas. >> >> Thanks, >> Andrew >> >> -----Original Message----- >> From: Howard Chu [mailto:hyc@symas.com] >> Sent: 09 January 2018 15:52 >> To: Lawrence, Andy (MO MM R&D UK IXL); openldap-devel(a)openldap.org >> Subject: Re: Beginner projects >> >> Lawrence, Andy wrote: >>> Hi, >> >> Hello, >>> >>> Me and one of my colleagues are interested in contributing to >>> OpenLDAP. Do you have any interesting projects that new comers such as myself could work on? >> >> There's a list in the source tree in doc/devel/todo. You can follow >> the pointers there to other possibilities. Pick whatever looks >> interesting to you and jump in ;) >>> >>> With best regards, >>> Dr Andrew Lawrence >>> >>> Siemens Rail Automation Holdings Limited MO MM R&D UK IXL >>> 17 Langley Park Way >>> Chippenham SN15 1GG, United Kingdom >>> mailto:andrew.lawrence@siemens.com >>> www.siemens.com/rail-automation >>> <http://www.siemens.com/rail-automation> >>> www.siemens.com/ingenuityforlife >>> <https://siemens.com/ingenuityforlife> >>> www.siemens.com/ingenuityforlife >>> Siemens Rail Automation Holdings Limited - registered office: >>> Faraday House, Sir William Siemens Square, Frimley Camberley GU16 8QD. >>> Registered No. 00016033 >>> >> >> > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

release 2.4.46?
by Michael Ströder 10 Jan '18

10 Jan '18

HI! BTW: Happy New Year. What are currently the plans for releasing 2.4.46? It's hanging in branch RE24 for quite while now. Ciao, Michael.

5 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel January 2018