asserts and manadatory build instructions (was ITS#8240)
by Michael Ströder
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 year, 7 months
RE24 testing call #1 (2.4.44) LMDB RE0.9 testing call #1 (0.9.18)
by Quanah Gibson-Mount
OpenLDAP 2.4.44 Engineering
Fixed slapd-bdb/hdb missing olcDbChecksum config attr (ITS#8337)
Fixed slapd-mdb cleanup after failed transaction (ITS#8360)
Fixed slapd-sql missing id_query/olcSqlIdQuery (ITS#8329)
Fixed slapo-accesslog callback initialization (ITS#8351)
Fixed slapo-ppolicy pwdMaxRecordedFailure must never be zero
(ITS#8327)
Fixed slapo-syncprov abandon processing (ITS#8354)
Documentation
admin24 Stop linking to Berkeley DB downloads (ITS#8362)
admin24 Update documentation for LMDB preference
LMDB 0.9.18 Release Engineering
Fix robust mutex detection on glibc 2.10-11 (ITS#8330)
Fix page_search_root assert on FreeDB (ITS#8336)
Fix MDB_APPENDDUP vs. rewrite(single item) (ITS#8334)
Fix mdb_copy of large files on Windows
Fix subcursor move after delete (ITS#8355)
Fix mdb_midl_shirnk off-by-one (ITS#8363)
Check for utf8_to_utf16 failures (ITS#7992)
Catch strdup failure in mdb_dbi_open
Build
Additional makefile var tweaks (ITS#8169)
Documentation
Add Getting Started page
Update WRITEMAP description
Thanks!
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
7 years, 4 months
Re: Dropping the MozNSS crypto bits from OpenLDAP
by Quanah Gibson-Mount
Hi Ludwig,
We have yet to even alpha 2.5, and then there will be betas and potential
RCs. I'd say we're overall at least a year out from an official 2.5
release.
--Quanah
--On Friday, January 15, 2016 3:02 PM +0100 Ludwig Krispenz
<lkrispen(a)redhat.com> wrote:
> Hi Quannah,
>
> not an objection to dropping it, but a question about timing.
> We are using the openldap client library in 389-ds and rely on the fact
> that they are linked to moznss. We are in the process to make our
> implementation/deployment independent of which crypto lib is used, but
> we are not yet there.
>
> What is the time frame of 2.5 ?
>
> Regards,
> Ludwig
>
> On 01/12/2016 12:58 AM, Quanah Gibson-Mount wrote:
>> Hi Jan,
>>
>> Now that the Crypto Consolidation project has been dropped by Fedora
>> (<https://fedoraproject.org/wiki/FedoraCryptoConsolidation>), is there
>> any objection to OpenLDAP dropping the MozNSS work going forward
>> (OpenLDAP 2.5+)? We already have noted we don't support people using
>> it, due to the security problems it creates, etc.
>>
>> Thanks,
>> Quanah
>>
>> --
>>
>> Quanah Gibson-Mount
>> Platform Architect
>> Zimbra, Inc.
>> --------------------
>> Zimbra :: the leader in open source messaging and collaboration
>>
>
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
7 years, 4 months
Slapd startup behavior when unable to bind to an interface
by Quanah Gibson-Mount
Currently, slapd will start up even if it can't bind to an interface, if
more than one potential interface is given where the bind is successful.
This was, as best as Howard can recall, done because of ipv4/ipv6 issues on
some systems.
However, it seems to me that it should at least be possible to specify to
slapd that you do not want it to start up unless binding to all interfaces
is successful.
This is fairly trivial to reproduce. As a non-privileged user, simply do:
-h "ldap:// ldapi://slapd.sock"
It will fail to bind to 389, but bind to the LDAPI socket anyway, and
continue the startup process. This gives a false result that slapd started
successfully, although clearly external clients will be unable to talk to
it.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
7 years, 4 months
Dropping the MozNSS crypto bits from OpenLDAP
by Quanah Gibson-Mount
Hi Jan,
Now that the Crypto Consolidation project has been dropped by Fedora
(<https://fedoraproject.org/wiki/FedoraCryptoConsolidation>), is there any
objection to OpenLDAP dropping the MozNSS work going forward (OpenLDAP
2.5+)? We already have noted we don't support people using it, due to the
security problems it creates, etc.
Thanks,
Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
7 years, 4 months
mm_last_pg+1 != filesize (was: openldap.git branch mdb.master updated. 209b56fead1afe8273db6c714c0a74a9c09b9cf6)
by Hallvard Breien Furuseth
On 21/12/15 03:39, openldap-commit2devel(a)OpenLDAP.org wrote:
> commit 209b56fead1afe8273db6c714c0a74a9c09b9cf6
> Author: Howard Chu <hyc(a)openldap.org>
> Date: Mon Dec 21 02:36:20 2015 +0000
>
> ITS#8324 fix for WRITEMAP
>
> We called FlushViewOfFile with (map,mapsize) which worked fine
> when we had allocated the entire map already. Now we have to make
> sure to only flush as much as was actually written. Add a numpgs
> argument to tell how much to flush in env_sync0().
Do env_sync() and commit() survive the test program from ITS#7886?
It creates a datafile which ends before mm_last_pg+1.
7 years, 5 months
