openldap-devel

openldap-devel@openldap.org

1416 discussions

contrib modules to promote to mainline for 2.5?
by Quanah Gibson-Mount 23 Apr '20

23 Apr '20

Are there any contrib modules that we should consider promoting to mainline for the 2.5 series? I.e., sha2, argon2 seem like potential options. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

6 11

Re: contrib modules to promote to mainline for 2.5?
by Quanah Gibson-Mount 22 Apr '20

22 Apr '20

--On Wednesday, April 22, 2020 1:04 PM -0700 Philip Guenther <pguenther(a)proofpoint.com> wrote: > Is there a ticket tracking this where the open question(s) for which a > response is needed can be seen? The obvious search of > https://bugs.openldap.org/buglist.cgi?quicksearch=bcrypt There wouldn't be, as it requires the author to contribute it as noted in: <https://github.com/wclarie/openldap-bcrypt/issues/1> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

MinGW status.
by Ryan Tandy 17 Apr '20

17 Apr '20

1. Why do I care about Windows? After seeing knowledgeable people say several times that building OpenLDAP on Windows worked fine for them [1][2][3], but failing my first attempts, I decided it should damn well work for me too! [1] https://bugs.openldap.org/show_bug.cgi?id=7878#c1 [2] https://bugs.openldap.org/show_bug.cgi?id=7878#c3 [3] https://www.openldap.org/lists/openldap-technical/201908/msg00033.html 2. Where are we now? Master branch is in OK shape now. A basic build with OpenSSL and default-ish backends/overlays succeeds. If built WITHOUT --enable-dynamic, it even passes the test suite, with one workaround [4]. If built WITH --enable-dynamic, there are various issues related to the libtool wrappers: the test processes don't exit when killed [5], ITS#2922 occurs, etc. Executing the binaries directly seems to work around most of it, but I still have an unexplained failure in test058. RE24 has the code fixes now (in 2.4.50), however, its older libtool and autoconf still contain bugs that have been fixed now in master. It doesn't produce DLLs due to a libtool bug [6], but the executables can be built with the static libs. The test suite needs configure rebuilt with a newer autoconf [7], plus all the same caveats as master. [4] --- a/tests/scripts/defines.sh +++ b/tests/scripts/defines.sh @@ -18 +18 @@ -TESTWD=`pwd` +TESTWD=`pwd -W` [5] https://sourceforge.net/p/mingw/bugs/845/ https://sourceforge.net/p/mingw/bugs/1783/ [6] haven't found a bug or commit link, but https://lists.defectivebydesign.org/archive/html/lmi/2011-06/msg00016.html discusses the same problem [7] http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commit;h=17ea0df46f819… If I've analyzed anything above incorrectly, please let me know! 3. Where to next? I'd like to write up some up-to-date instructions for building on Windows, but I'm not sure where I would post them before the FAQ site is replaced. When I linked with MSYS2's cyrus-sasl package, I encountered heap corruption errors. I haven't looked more closely at that yet. Since a native Windows CI host looks unlikely in the short term, I'd like to investigate getting cross builds [8] stable enough to add as a CI target. ITS#9087 is a first step in that direction. Obviously it wouldn't be able to run tests, but we could at least monitor compile failures. There are a few things to deal with, such as configure tests that currently run test programs (e.g. "working memcmp"), and providing dependency libraries (-lregex). [8] apt install gcc-mingw-w64-x86-64 cheers, Ryan

1 0

2.4 commit review
by Quanah Gibson-Mount 02 Apr '20

02 Apr '20

I think the following ITSes would be good to add for 2.4.50. Any objections? ITS#7074 - Fix olcDatabaseDummy init for windows ITS#9003 - Fix slapd-ldap(5) man page to note idassert-authzfrom policy difference ITS#9181 - Fix race on Windows mutex init ITS#9182 - pcache: fix private DB init Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 2

SASL channel-binding changes
by Isaac Boukris 01 Apr '20

01 Apr '20

Hi all, Following our discussion over cyrus-sasl PR 601 [1], I worked out a new wip patch: https://git.openldap.org/iboukris/openldap/-/commits/cbind_v3 It changes the sasl channel-binding to be passed optionally (none by default), controlled via ldap.conf / slapd.conf, and adds "tls-server-end-point" binding type which is compatible with Windows. In addition, I noticed the current "tls-unique" implementation in openldap doesn't pass the prefix of the channel-binding as defined in RFC 5056, quote: Specifications of channel bindings for any secure channels MUST provide for a single, canonical octet string encoding of the channel bindings. Under this framework, channel bindings MUST start with the channel binding unique prefix followed by a colon (ASCII 0x3A). So I fixed that too, by adding "tls-unique:" prefix as per RFC 5929 registration. Note that this won't be compatible with older versions of openldap (say for GS2 users, if any), so it is another reason to not send any bindings by default, to avoid mismatches. I've only tested the openssl client backend code so far (on top of cyrus-sasl PR 601), the rest is pretty much pseudo code for now. I plan to work out the other backends, and add some unit-tests showing the expected binding are being passed by both client and server (tips and help welcome). Thoughts? Refs [1]: https://github.com/cyrusimap/cyrus-sasl/pull/601 https://bugs.openldap.org/show_bug.cgi?id=9189 Thanks!

2 2

back-ndb: retire for 2.5?
by Quanah Gibson-Mount 24 Mar '20

24 Mar '20

The back-ndb backend has never been finished, and relies on partnership with a corporation that has no desire to continue the work since it acquired the original entity involved. I would suggest then that it be removed from the 2.5 release tree and left master only. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 6

Issue tracker review complete
by Quanah Gibson-Mount 23 Mar '20

23 Mar '20

I've gone through and looked at all of the open issues that were in the OpenLDAP product queue. The end result of this is that numerous duplicate issues, invalid issues, and issues where we never got any response after asking for more information have been closed out appropriately. As a part of this I've gone through and marked many of the bugs with target milestones and sometimes keywords. Any issues with a target milestone of 2.5.0 and a keyword of OL_2_5_REQ is an item that should likely be fixed for OpenLDAP 2.5. If it is not going to be fixed for 2.5, then we need to come to a decision on what release series we plan on fixing it in. I.e., I generally consider these high priority items. Often these are things we've put off doing for 2.4 due to disruption/incompatible API changes, etc, but are generally necessary for the overall improvement of OpenLDAP. A number of these issues already have patches. Some of them are documentation items that are likely not too hard to deal with, and I've self-assigned many of those. There are a total of 175 items in this list: <https://bugs.openldap.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CON…> Any issues with a target milestone of 2.5.0 but no keyword of OL_2_5_REQ are items that need further review by other team members. I put items in this category that seem of general interest, but may be more appropriate for a later release, or perhaps remain unscheduled at this time. There are 188 issues in this list: <https://bugs.openldap.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CON…> There is one open issue with the 2.4.50 milestone that I'll be taking care of. All other issues I've left unassigned. This does not mean they have no value, but they do not seem critical for the OpenLDAP 2.4.50 or 2.5 releases and can be re-examined at a later time. All of this should help anyone who has expressed a desire in the past to work with the project -- There is now a well sorted set of issues that need addressing. Some of these items are fairly straight forward, especially documentation updates. Feel free to sign up to gitlab, fork the repo, and submit merge requests for issues to be reviewed. Please add any merge request links to the related issue in the tracker as well. Overall, given the list of items in the first category, I'm not sure the 2.5-odd/even track is the best route. I'm personally leaning more towards 2.5, 2.6, 2.7, etc, where each of these releases is of a short duration. There seems to be enough work at this time to support more frequent minor version releases and that would allow us to sucessively improve the product. Having defined sets of issues for given target release milestones should help significantly as far as planning and resource allocation is concerned. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

back-sql: retire for 2.5?
by Quanah Gibson-Mount 23 Mar '20

23 Mar '20

One thing that came up repeatedly in going through the ITS system is issues with back-sql (A quick count gives me 23). Given that this backend has always been marked experimental and has numerous bugs, I would suggest that unless someone steps up who is willing to support it that it be removed from the 2.5 release series (i.e., make it master only until someone is willing to maintain it). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

CVS... should it stay or should it go now?
by Quanah Gibson-Mount 17 Mar '20

17 Mar '20

One of the things we did not migrate over from Gauss was the old CVS repository. However, there are references in the old -software archives (and possibly -technical as well), and existing bug reports, such as <https://bugs.openldap.org/show_bug.cgi?id=831#c6> which have links that will no longer work without the old CVS repository being present, although all of these changes of course do exist in the git repo, just with git change IDs. Is there anyone who feels it is worthwhile to preserve the old CVS repository so that these references can still be examined directly w/o having to parse through the git history to find them? If so, we can certainly restore the CVS repo on the new system. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

archiving test
by Quanah Gibson-Mount 12 Mar '20

12 Mar '20

just an archiving test, ignore :P -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
142
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel