- openldap-bugs - openldap.org

Re: (ITS#9069) Stop setting custom GnuTLS mutex functions
by hyc＠symas.com 28 Aug '19

28 Aug '19

Ryan Tandy wrote: > On Wed, Aug 28, 2019 at 01:34:31PM +0100, Howard Chu wrote: >> This is not a safe assumption on Windows, unfortunately. While libldap uses native >> Windows mutexes on Windows, a lot of code built using gcc/g++ uses a posixthreads >> emulation library for thread and mutex support, and the user-visible structures are >> not compatible with native mutexes. (I've found this to be a significant problem >> for g++ std::mutex, std::thread, etc.) > > Thanks for mentioning that. GnuTLS also uses native Windows threads when building for Windows (including mingw-ish environments), so it should still be OK; but > I'd better go and figure out a smoke test on Windows too. > > How does this work on the OpenSSL side? For 1.1.0+ it sounds like the same situation, with OpenSSL using the Windows native API as well. > > Does "incompatible" just mean that a single mutex object can't be shared between the two APIs? (I don't think that would be an issue for our case.) Or is it > something stronger like a pthreads mutex not being able to synchronize native threads, or outright not being able to use both interfaces in a single process? > Passing a native structure to the posixthreads interface (and vice versa) will crash the program (or worse - silently corrupt memory without crashing the program....) -- -- 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

Re: (ITS#9069) Stop setting custom GnuTLS mutex functions
by ryan＠nardis.ca 28 Aug '19

28 Aug '19

On Wed, Aug 28, 2019 at 01:34:31PM +0100, Howard Chu wrote: >This is not a safe assumption on Windows, unfortunately. While libldap uses native >Windows mutexes on Windows, a lot of code built using gcc/g++ uses a posixthreads >emulation library for thread and mutex support, and the user-visible structures are >not compatible with native mutexes. (I've found this to be a significant problem >for g++ std::mutex, std::thread, etc.) Thanks for mentioning that. GnuTLS also uses native Windows threads when building for Windows (including mingw-ish environments), so it should still be OK; but I'd better go and figure out a smoke test on Windows too. How does this work on the OpenSSL side? For 1.1.0+ it sounds like the same situation, with OpenSSL using the Windows native API as well. Does "incompatible" just mean that a single mutex object can't be shared between the two APIs? (I don't think that would be an issue for our case.) Or is it something stronger like a pthreads mutex not being able to synchronize native threads, or outright not being able to use both interfaces in a single process?

1 0

Re: (ITS#9069) Stop setting custom GnuTLS mutex functions
by hyc＠symas.com 28 Aug '19

28 Aug '19

ryan(a)openldap.org wrote: > Full_Name: Ryan Tandy > Version: master > OS: Debian > URL: https://github.com/rtandy/openldap/compare/openldap:master...rtandy:remove-… > Submission from: (NULL) (70.66.128.207) > Submitted by: ryan > > > The GnuTLS documentation > <https://gnutls.org/manual/html_node/Core-TLS-API.html#gnutls_005fglobal_005…> > states: > >> Do not call this function from a library, or preferably from any application > unless really needed to. > Additionally, the custom mutex functions are never reset, so if libldap is > unloaded (for example via dlclose()) after calling this, its code may be > unmapped and the application could crash when GnuTLS calls the mutex functions. > > On typical systems, GnuTLS system mutexes are probably the same as what libldap > uses anyway. This is not a safe assumption on Windows, unfortunately. While libldap uses native Windows mutexes on Windows, a lot of code built using gcc/g++ uses a posixthreads emulation library for thread and mutex support, and the user-visible structures are not compatible with native mutexes. (I've found this to be a significant problem for g++ std::mutex, std::thread, etc.) > > IPR: > > The attached patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following patch were > developed by Ryan Tandy <ryan(a)nardis.ca>. I have not assigned rights and/or > interest in this work to any party. > > I, Ryan Tandy, hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose with or > without attribution and/or other notice. > > -- -- 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

Re: (ITS#9069) Stop setting custom GnuTLS mutex functions
by ondra＠mistotebe.net 28 Aug '19

28 Aug '19

On Wed, Aug 28, 2019 at 01:04:25AM +0000, ryan(a)openldap.org wrote: > The GnuTLS documentation states: >> Do not call this function from a library, or preferably from any application >> unless really needed to. > > I disobeyed that guidance in commit 829027945, because I wasn't sure that > GnuTLS's own threading support would cover all the platforms libldap does. This > choice caused some bugs, e.g. <https://bugs.debian.org/803197> and > <https://www.openldap.org/its/?findid=8797>. > > I don't know how to find out for sure whether anyone builds libldap with GnuTLS > on a system where it lacks native mutexes. I think at this point I would rather > fix the known broken cases, over the risk of potentially breaking a theoretical > setup I'm not sure actually exists. > > Therefore: I now propose applying this change for 2.5. A similar change (making tlso_thr_init a no-op) has been introduced in ITS#8533 when compiling with OpenSSL 1.1.0+, so I gather it should be fine for GnuTLS as well. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

(ITS#9069) Stop setting custom GnuTLS mutex functions
by ryan＠openldap.org 28 Aug '19

28 Aug '19

Full_Name: Ryan Tandy Version: master OS: Debian URL: https://github.com/rtandy/openldap/compare/openldap:master...rtandy:remove-… Submission from: (NULL) (70.66.128.207) Submitted by: ryan The GnuTLS documentation <https://gnutls.org/manual/html_node/Core-TLS-API.html#gnutls_005fglobal_005…> states: > Do not call this function from a library, or preferably from any application unless really needed to. I disobeyed that guidance in commit 829027945, because I wasn't sure that GnuTLS's own threading support would cover all the platforms libldap does. This choice caused some bugs, e.g. <https://bugs.debian.org/803197> and <https://www.openldap.org/its/?findid=8797>. I don't know how to find out for sure whether anyone builds libldap with GnuTLS on a system where it lacks native mutexes. I think at this point I would rather fix the known broken cases, over the risk of potentially breaking a theoretical setup I'm not sure actually exists. Therefore: I now propose applying this change for 2.5. I made this change as a distro patch in Debian 10 (buster), and no Debian or Ubuntu users have reported any regressions so far. I also did some local testing with slapd and slapd-mtread on the GnuTLS versions shipped in the last few releases of Debian. I have not tested any non-Linux platforms yet. For completeness, I should probably try this on at least FreeBSD and Solaris. I kind of assume GnuTLS system mutexes are going to work anywhere LMDB already does. Rationale for the change, from the commit message: Since GnuTLS moved to implicit initialization on library load, calling this function deinitializes GnuTLS and then re-initializes it. When GnuTLS uses /dev/urandom as an entropy source (getrandom() not available, or older versions of GnuTLS), and the application closed all file descriptors at startup, this could result in GnuTLS opening /dev/urandom over one of the application's file descriptors when re-initialized. Additionally, the custom mutex functions are never reset, so if libldap is unloaded (for example via dlclose()) after calling this, its code may be unmapped and the application could crash when GnuTLS calls the mutex functions. On typical systems, GnuTLS system mutexes are probably the same as what libldap uses anyway. IPR: The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Ryan Tandy <ryan(a)nardis.ca>. I have not assigned rights and/or interest in this work to any party. I, Ryan Tandy, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#8753) Public key pinning support in libldap
by ryan＠nardis.ca 27 Aug '19

27 Aug '19

The gnutls_digest_get_id function was added in GnuTLS 3.2.2: https://gitlab.com/gnutls/gnutls/blob/gnutls_3_2_2/NEWS That was released in 2013, so I think it's OK to depend on it by now. Please consider applying this patch to update the configure.in check: https://github.com/openldap/openldap/compare/master...rtandy:its8753-gnutls… Currently master fails to compile with older GnuTLS (e.g. on Debian 7/wheezy) after configure succeeded.

1 0

(ITS#9068) mdb_load corrupts escaped backslash
by hyc＠openldap.org 26 Aug '19

26 Aug '19

Full_Name: Howard Chu Version: 0.9.24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.233.39.186) Submitted by: hyc When reloading a printable dump (from mdb_dump -p), actual backslashes in the input (represented as '\\') will be corrupted. This has been broken since mdb_load was written in 2004.

1 0

Re: (ITS#9067) preferredDeliveryMethod syntax evaluation incorrect
by hyc＠symas.com 26 Aug '19

26 Aug '19

bremer(a)univention.de wrote: > Full_Name: Julia Bremer > Version: 2.4.45 > OS: debian / UCS 4.4 > URL: http://updates.software-univention.de/download/temp/openldap/fix-syntax-eva… > Submission from: (NULL) (82.198.197.8) > > > Trying to set the value of the attribute preferredDeliveryMethod to a sequence > of items, separated by " $ ", e.g "telephone $ videotex" fails with > > ldap_modify: Invalid syntax (21) > additional info: preferredDeliveryMethod: value #0 invalid per syntax > > even though the syntax is correct according to the RFC4517 > (Syntax 1.3.6.1.4.1.1466.115.121.1.14). > https://tools.ietf.org/html/rfc4517#section-3.3.5 > > This is due to an error in the method deliveryMethodValidate in > servers/slapd/schema_init.c which causes the function to check the string > backwards after a space character occurs. > The attached patch fixes this, so that the syntax is validated correctly. Thanks for the report, committed to master. Looks like this code has never been used since Kurt wrote it in 2004. I've tested it locally now but would ask whether you have time to also add a check into the test suite. Thanks. > > > Univention hereby place the following modifications to OpenLDAP Software (and > only these modifications) into the public domain. Hence, these modifications may > be freely used and/or redistributed for any purpose with or without attribution > and/or other notice. > > -- -- 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#9067) preferredDeliveryMethod syntax evaluation incorrect
by bremer＠univention.de 26 Aug '19

26 Aug '19

Full_Name: Julia Bremer Version: 2.4.45 OS: debian / UCS 4.4 URL: http://updates.software-univention.de/download/temp/openldap/fix-syntax-eva… Submission from: (NULL) (82.198.197.8) Trying to set the value of the attribute preferredDeliveryMethod to a sequence of items, separated by " $ ", e.g "telephone $ videotex" fails with ldap_modify: Invalid syntax (21) additional info: preferredDeliveryMethod: value #0 invalid per syntax even though the syntax is correct according to the RFC4517 (Syntax 1.3.6.1.4.1.1466.115.121.1.14). https://tools.ietf.org/html/rfc4517#section-3.3.5 This is due to an error in the method deliveryMethodValidate in servers/slapd/schema_init.c which causes the function to check the string backwards after a space character occurs. The attached patch fixes this, so that the syntax is validated correctly. Univention hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#9066) Missing custom attrs after restart slapd
by quanah＠symas.com 22 Aug '19

22 Aug '19

--On Thursday, August 22, 2019 12:08 PM +0000 juanma171(a)yahoo.es wrote: > Full_Name: JuanMa > Version: 2.4.45 > OS: Ubuntu 18.04.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.176.151.51) > > > Afeter creating custom attrs, I can see in ldap browser, but after > restart sldap daemon, custom attrs are missing (sorry, bad english) > OLC mode and mdb database Hello, That is not the correct way to modify the schema or add new attributes. Please use the openldap-technical(a)openldap.org list for help. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#1505) Missing custom attrs after restart slapd
by juanma171＠yahoo.es 22 Aug '19

22 Aug '19

Full_Name: JuanMa Version: 2.4.45 OS: Ubuntu 18.04.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.176.151.51) Afeter creating custom attrs, I can see in ldap browser, but after restart sldap daemon, custom attrs are missing (sorry, bad english) OLC mode and mdb database LDIF for attr: dn: cn=schema,cn=config changetype: modify add: olcAttributeTypes olcAttributeTypes: ( 1.3.6.1.4.1.8876.2.1.1 NAME 'mOL-APIKey' DESC 'API Key' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64512} SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.8876.2.1.2 NAME 'mOL-APISecretKey' DESC 'API Secret Key' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64512} SINGLE-VALUE ) after restart slapd: ldapsearch -x -LLL -b cn=Subschema -s base '(objectClass=subschema)' attributeTypes | grep mOL-APIKey doesn't show anything

1 0

(ITS#9065) slapo-ppolicy(5) man page refers to wrong attribute
by quanah＠openldap.org 19 Aug '19

19 Aug '19

Full_Name: Quanah Gibson-Mount Version: 2.4.48 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) The slapo-ppolicy(5) man page has this statement in the description of pwdGraceUseTime: If too many grace logins have been used (please refer to the pwdGraceLoginLimit password policy attribute), However, there is no such attribute as "pwdGraceLoginLimit". It is instead pwdGraceAuthnLimit

1 0

Re: (ITS#9064) client tools not recognizing BINDDN from ldap.conf
by quanah＠symas.com 18 Aug '19

18 Aug '19

--On Sunday, August 18, 2019 12:19 AM +0000 fabrice.ducos(a)gmail.com wrote: > In my ldap.conf The ldap.conf(5) man page clearly states that the BINDDN variable is a USER ONLY option. That means it will only be honored if it appears in the ~user/.ldaprc file. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9064) client tools not recognizing BINDDN from ldap.conf
by fabrice.ducos＠gmail.com 18 Aug '19

18 Aug '19

Full_Name: Fabrice Ducos Version: 2.4.48 OS: OSX 10.14.6 Mojave URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (90.110.219.170) I have installed OpenLDAP 2.4.48 from sources with SASL support. For the moment, I am not using SASL. I have created a small toy directory with a few records. I have got no problem reading it with the local utilities (slap cat, etc). Now I am in the course of playing with the client tools. In my ldap.conf, I have got the following directives: URI ldap://localhost BASE dc=myrealm,dc=mydomain,dc=org BINDDN cn=root,ou=users,dc=myrealm,dc=mydomain,dc=org (root is the name I gave to my the rootdn account in slapd.conf) The ldap.conf file has been put at the right place under /usr/local/etc/openldap When I perform the following command: ldapsearch -x -W -D 'cn=root,ou=users,dc=myrealm,dc=mydomain,dc=org' (with -x to force a simple binding) I get the results I expect from the directory, starting from BASE (no need for a -b option). However, when I test: ldapsearch -x -W (with -D), I would expect to get the same result, the binding DN being set up from ldap.conf BINDDN. However, it fails: Enter LDAP Password: ldap_bind: Invalid credentials (49) (this is not a problem of password, otherwise it would also fail in the first test; I use the same password in both). I put the example files under incoming/binddn_2019-08-18 on your ftp server. The passwords are unencrypted in these sample files (encryption of passwords in another topic), but it doesn't explain why the root password from slapd.conf is recognised with -W -D and not with -W alone. Thank for your assistance.

1 0

Re: (ITS#9037) observing crash in mdb_cursor_put()
by vporof＠mozilla.com 15 Aug '19

15 Aug '19

That's good to know. Since we're completely in the dark on how to produce a reliable test case that exercises this crash, the hope was that fuzzing could inch us towards a solution. There's also the problem that we're observing these crashes on Windows 7 and x86-64 (at least for now), as evidenced by this report: = https://crash-stats.mozilla.org/signature/?signature=3Dmdb_cursor_put&_col= umns=3Dplatform&_columns=3Dcpu_arch&_sort=3D-date&page=3D1#reports Fuzzing on that platform is quite a bit more difficult since tooling is=20= lacklustre. Furthermore, we can't really try fuzzing under WSL and=20 Windows 10, since LMDB also doesn't actually work well under WSL, due to mmap on a 0-length file failing with ENOEXEC, also complicating things: https://github.com/microsoft/WSL/issues/3451 I'm not clear if Robins George (OP) observed this crash on a different platform, perhaps they can confirm? If fuzzing isn't a worthwhile exploration avenue, any suggestions for=20 what kind of tests might exercise a crash like this?

1 0

Re: (ITS#9037) observing crash in mdb_cursor_put()
by hyc＠symas.com 14 Aug '19

14 Aug '19

hyc(a)symas.com wrote: > vporof(a)mozilla.com wrote: >> It might be possible that even though RKV was built in debug mode, the >> backing sys crate isn't building LMDB itself this way. On a very first >> glance it looks like this is the case, always going for opt level 2: >> https://github.com/danburkert/lmdb-rs/blob/master/lmdb-sys/build.rs#L23 >> >> I'll have a closer look at the build process and see what's going on. >> >> Can you share your build process that resulted in LMDB debug functions >> being optimized away? Did you build using the fuzzer via `cargo afl`? >> Something else? > > I deleted the lmdb-rkv-sys-* directories from target/debug/build, edited > .cargo/registry/src/github.com-1ecc6299db9ec823/lmdb-rkv-sys-0.8.6/lmdb/libraries/liblmdb/mdb.c > and added #define MDB_DEBUG 3 at the top of the file, then reran the cargo build command. > > RUSTFLAGS="-Clink-arg=-fuse-ld=gold" cargo afl build -v Not really sure it's worth spending time on these fuzzer results. Basically you're feeding corrupted database files into LMDB, and it is hitting an assert because it sees that the structure is corrupted. Working as designed, in other words. -- -- 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

Re: (ITS#9037) observing crash in mdb_cursor_put()
by hyc＠symas.com 14 Aug '19

14 Aug '19

vporof(a)mozilla.com wrote: > It might be possible that even though RKV was built in debug mode, the > backing sys crate isn't building LMDB itself this way. On a very first > glance it looks like this is the case, always going for opt level 2: > https://github.com/danburkert/lmdb-rs/blob/master/lmdb-sys/build.rs#L23 > > I'll have a closer look at the build process and see what's going on. > > Can you share your build process that resulted in LMDB debug functions > being optimized away? Did you build using the fuzzer via `cargo afl`? > Something else? I deleted the lmdb-rkv-sys-* directories from target/debug/build, edited .cargo/registry/src/github.com-1ecc6299db9ec823/lmdb-rkv-sys-0.8.6/lmdb/libraries/liblmdb/mdb.c and added #define MDB_DEBUG 3 at the top of the file, then reran the cargo build command. RUSTFLAGS="-Clink-arg=-fuse-ld=gold" cargo afl build -v -- -- 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

Re: (ITS#9037) observing crash in mdb_cursor_put()
by vporof＠mozilla.com 14 Aug '19

14 Aug '19

It might be possible that even though RKV was built in debug mode, the backing sys crate isn't building LMDB itself this way. On a very first glance it looks like this is the case, always going for opt level 2: https://github.com/danburkert/lmdb-rs/blob/master/lmdb-sys/build.rs#L23 I'll have a closer look at the build process and see what's going on. Can you share your build process that resulted in LMDB debug functions being optimized away? Did you build using the fuzzer via `cargo afl`? Something else?

1 0

Re: (ITS#9037) observing crash in mdb_cursor_put()
by hyc＠symas.com 14 Aug '19

14 Aug '19

vporof(a)mozilla.com wrote: > Thanks for getting back! > > The files at https://github.com/mozkeeler/rkv-fuzz/tree/trunk/crashes > are fuzzed variants of the input data seeded from the mdb input here: > They're generated when running the `american fuzzy lop` fuzzer: > http://lcamtuf.coredump.cx/afl/. It appears that rust is doing link-time optimization and deleting LMDB debug functions from the resulting binary. I'm not familiar with how the rust build system works, can we get it to stop doing this? -- -- 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

Re: (ITS#9037) observing crash in mdb_cursor_put()
by vporof＠mozilla.com 14 Aug '19

14 Aug '19

Thanks for getting back! The files at https://github.com/mozkeeler/rkv-fuzz/tree/trunk/crashes are fuzzed variants of the input data seeded from the mdb input here: They're generated when running the `american fuzzy lop` fuzzer: http://lcamtuf.coredump.cx/afl/. Victor

1 0

Re: (ITS#9037) observing crash in mdb_cursor_put()
by hyc＠symas.com 14 Aug '19

14 Aug '19

vporof(a)mozilla.com wrote: > Quick update on this. > > Potentially useful to the efforts here, Dana Keeler has implemented a = > fuzzing harness for RKV (our typed Rust interface to LMDB): = > https://github.com/mozkeeler/rkv-fuzz > > We weren't able to trigger the `mdb_cursor_put` crashes reported at = > https://crash-stats.mozilla.org/signature/?signature=3Dmdb_cursor_put#repo= > rts, though we did end up finding a few others: = > https://github.com/mozkeeler/rkv-fuzz/tree/trunk/crashes What kinds of files are these, in the crashes directory? > > Howard, do any of those look familiar and potentially related? > > Victor > > > > > -- -- 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

Re: (ITS#9037) observing crash in mdb_cursor_put()
by vporof＠mozilla.com 14 Aug '19

14 Aug '19

Quick update on this. Potentially useful to the efforts here, Dana Keeler has implemented a = fuzzing harness for RKV (our typed Rust interface to LMDB): = https://github.com/mozkeeler/rkv-fuzz We weren't able to trigger the `mdb_cursor_put` crashes reported at = https://crash-stats.mozilla.org/signature/?signature=3Dmdb_cursor_put#repo= rts, though we did end up finding a few others: = https://github.com/mozkeeler/rkv-fuzz/tree/trunk/crashes Howard, do any of those look familiar and potentially related? Victor

1 0

RE: [External] Re: (ITS#9062) Please have /build/mkdep respect TMPDIR if set
by zagarc＠oclc.org 13 Aug '19

13 Aug '19

--_000_BYAPR06MB4311BFD5C8DDA97A03E2D86AA1D20BYAPR06MB4311namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Thank you! Chris From: Quanah Gibson-Mount <quanah(a)symas.com> Sent: Tuesday, August 13, 2019 8:06 AM To: Zagar (Contractor),Chris <zagarc(a)oclc.org>; openldap-its(a)OpenLDAP.org Subject: [External] Re: (ITS#9062) Please have /build/mkdep respect TMPDIR = if set --On Sunday, August 11, 2019 7:34 PM +0000 zagarc(a)oclc.org<mailto:zagarc@oc= lc.org> wrote: > Would you please consider changing this to: > > TMP=3D${TMPDIR-/tmp}/mkdep$$ Thanks for the report, this is fixed in OpenLDAP master. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com<http://www.symas.com>> --_000_BYAPR06MB4311BFD5C8DDA97A03E2D86AA1D20BYAPR06MB4311namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Thank you!<o:p></o:p> <o:p> </o:p> Chris<o:p></o:p> <o:p> </o:p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in = 0in 0in"> From: Quanah Gibson-Mount <quanah(a)symas.co= m> Sent: Tuesday, August 13, 2019 8:06 AM To: Zagar (Contractor),Chris <zagarc(a)oclc.org>rg>; openldap-its@O= penLDAP.org Subject: [External] Re: (ITS#9062) Please have /build/mkdep respect = TMPDIR if set<o:p></o:p> </div> </div> <o:p> </o:p> --On Sunday, August 11, 2019 7:34 PM +0000 <a href=3D"mailto:zagarc@ocl= c.org">zagarc(a)oclc.org</a> wrote: > Would you please consider changing this to: > > TMP=3D${TMPDIR-/tmp}/mkdep$$ Thanks for the report, this is fixed in OpenLDAP master. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <<a href=3D"http://www.symas.com">http://www.symas.com</a>><o:p></o:p= > </div> </body> </html> --_000_BYAPR06MB4311BFD5C8DDA97A03E2D86AA1D20BYAPR06MB4311namp_--

1 0

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by gv＠members.scinet.supercomputing.org 13 Aug '19

13 Aug '19

On Wed, Jul 31, 2019 at 04:14:48PM -0400, Greg Veldman wrote: > v3 of the patch is available, which includes hashing functions > and documents the expected input format when using those functions. > I don't have the updated module on any of my servers yet, but > running slappasswd from my build directory does seem to yield > the same results as the non-password versions: Hi, Sorry to press the issue again, but with the hash functions implemented is there anything else preventing this patch from being merged? Thanks. -- Greg Veldman

1 0

Re: (ITS#9037) observing crash in mdb_cursor_put()
by vporof＠mozilla.com 13 Aug '19

13 Aug '19

Apologies for the previous botched message, I was unfamiliar with the formatting rules for this list. To reiterate: Since the link to the crash stats from my earlier reply now expired, here's an up to date place to see all recent crash reports involving `mdb_cursor_put`: https://crash-stats.mozilla.org/signature/?signature=mdb_cursor_put#reports Victor

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs