openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#8963) Start TLS failed errors on back-ldap binds / short timeout, config option request
by hyc＠symas.com 31 Jan '19

31 Jan '19

janne.peltonen(a)helsinki.fi wrote: > Full_Name: Janne Peltonen > Version: 2.4.44 > OS: Red Hat Enterprise Linux 7 > URL: https://www.openldap.org/lists/openldap-technical/201901/msg00038.html > Submission from: (NULL) (2001:708:110:1820:3664:a9ff:fe04:7363) > > > Proxied BINDs on back-ldap sometimes create Start TLS failed errors on the > connection from proxy to backend, and the client of the proxy receives the error > 52. We had a look at the code, and it appears that in back-ldap/bind.c, the > timeout argument of the function ldap_back_start_tls always ends up as zero, so > the timeout tv.sec and tv.usec end up being set as 0 and 100000, respectively, > by the macro LDAP_BACK_TV_SET defined in back-ldap/back-ldap.h. This means that > the actual timeout waiting for starttls operation to complete will be 0.1 > seconds, which is sometimes too little if there are latencies. We did a > quick&dirty hack to just set tv.sec to 3 and tv.usec to 0, and were no longer > able to get any Start TLS failed errors on the proxy bind. > > We did find that the back-ldap has an "extended" timeout defined in > back-ldap/config.c - except that is commented out as "not implemented". Seems to > us that if that were implemented, you could set the timeout in your ldap > database section by something like "timeout extended=" and then you could have a > longer timeout. Thanks for the report. Note that if you simply set a "timeout" with no specific qualifiers, it would have worked for you as well. At this point, the "extended" timeout was meant for the other exops that back-ldap supports, e.g. whoami and passwordModify. Since 2.4 is feature frozen we are not going to implement the extended timeout feature here. Instead, I've changed the start_tls code to use the "bind" timeout, since it will always be used as part of a bind operation anyway. > > Steps to reproduce: > 1. Configure an openldap proxy-backend pair, the proxy using the "ldap" database > and using ldap urls to connect to the backend (using ldaps urls might actually > be a workaround). Configure the binds to be proxied to the backend, too. > 2. Create a script that creates multiple - say, 200 - simultaneous connections > to the proxy, using an ldaps url to connect to the proxy, and using the same DN > to bind as. (We haven't tried to connect to the frontend using ldap+starttls, > but I would suppose that would have a similar result, since the client > establishes TLS anyway before trying to bind to the proxy.) > 3. Observe some of the binds fail (we typically get 5-6 fails for 200 > simultaneous connection), with the client of the proxy getting a "Server is > unavailable: 52" type of error, and the proxy log containing lines such as > "conn=7716 op=0 RESULT tag=97 err=52 text=Start TLS failed" after the BIND from > the client. > > Possible workaround: Configure the proxy to use ldaps urls to the backend. > > Suggested fix: Implement the "extended" timeout type in back-ldap/config.c > timeout_table, so that people can set the StartTLS timeout to a larger value > than the default 0.1 seconds. > > References: discussion thread on the OpenLDAP-Technical mailing list. > > -- -- 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#8968) Async connect mode does not work on Solaris
by quanah＠symas.com 31 Jan '19

31 Jan '19

--On Wednesday, January 30, 2019 11:19 PM +0000 vsmith(a)interlinknetworks.com wrote: > Full_Name: Vernon Smith > Version: 2.4.47 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2601:40d:4300:679a:c0c9:ced:d06f:39a4) > > > I have managed to upgrade to version 2.4.47 libldap libraries using the > Linux OS and async connect mode works fine. But when I tried to upgrade > to 2.4.47 using Solaris OS and use async connect mode, no connections > could be established to the ldap server. The libldap code did not even > send the ldap request to the ldap server. The ldap debug trace showed it > just freeing the request and returned an unable to connect. I traced the > issue to the routine ldap_int_flush_request which checks the sock_errno > return code for EAGAIN but Solaris 10 returns ENOTCONN. This error code > seems to mean the same thing as EAGAIN. I changed the code to test for > either return code and the async connect works for both Linux and Solaris > now. Here is may patch. Thanks for the report, this is now fixed in master (and will be a part of the next RE24 release). Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8957)
by quanah＠symas.com 31 Jan '19

31 Jan '19

--On Wednesday, January 30, 2019 3:15 PM +0000 quanah(a)symas.com wrote: > --On Wednesday, January 30, 2019 1:44 AM -0500 Vernon Smith > <vsmith(a)interlinknetworks.com> wrote: > >> I Tried to upload it to the openldap ftp server but was not successful so >> I am trying the patch again here. Thanks for the report, this has been committed to git master (and will be part of the next RE24 release). Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8959) duplicate symbols
by quanah＠symas.com 31 Jan '19

31 Jan '19

--On Thursday, January 31, 2019 9:00 AM +0000 ruga(a)protonmail.com wrote: > This is a multi-part message in MIME format. Lets try this a different way. No one is disputing you've found an issue. However, as has been noted repeatedly, there's no indication that the issue you have found is caused by the OpenLDAP software. As has been demonstrated numerous times in this thread, the software builds correctly without issue, using the flags you provided, with both gcc and clang, on multiple OSes and compiler verions. I.e., it would appear the problem surfaces with either your very specific build environment or the very specific set of compiler tools that you've installed. As you've noted, your particular environment is able to compile other software without hitting this issue. That's great. That however does not mean that the issue you're encountering is a bug with the OpenLDAP software. The fact that other compiler chain combinations do not hit this problem would appear to back this up. At this point, the onus is on you to clearly and unequivocally demonstrate the issue is specific to OpenLDAP as the issue more appears to be on the toolchain side. And that happens as well. I once hit a problem that was due to a bug in GCC's optimization strategies with values > -O2 (I.e., -O3, -O4, etc). It only occurred with one particular piece of software I was compiling out of several hundred software packages. And only with that particular version of GCC. But it was also clearly *not* the fault of the software. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8575) Argon2 Password hashing contrib module
by simon＠slevermann.de 31 Jan '19

31 Jan '19

Hi, I have essentially given up on doing this, because I no longer work for the employer that had me work on this, and at the time I did, I never got the thing done. The code itself worked when I tried it, but it has the caveat of not being configurable. I never quite found out how to properly implement configuration of a module that isn't an overlay, so I never got that done. Feel free to adjust the existing code, it should be adaptable to libsodium relatively easily. Cheers, Simon Am 31.01.2019 um 16:17 schrieb Raphael Geissert: > Hi, > > Is there any progress on a libsodium-based module? Or is there any > chance that the current version be integrated as-is ("one is better > than none")? > > Regards,

1 0

Re: (ITS#8575) Argon2 Password hashing contrib module
by atomo64＠gmail.com 31 Jan '19

31 Jan '19

Hi, Is there any progress on a libsodium-based module? Or is there any chance that the current version be integrated as-is ("one is better than none")? Regards, -- Raphael Geissert

1 0

Re: (ITS#8959) duplicate symbols
by quanah＠symas.com 31 Jan '19

31 Jan '19

--On Thursday, January 31, 2019 8:13 AM +0000 hyc(a)symas.com wrote: > Still, nothing in the OpenLDAP build setup does this. You did it yourself, > most likely the same way you set "-D_FORTIFY_SOURCE=2" 3 times in your > CPPFLAGS. That was actually me when I inaverdently exported the variable more than once when playing with the flags. ;) Just to note. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8959) duplicate symbols
by ruga＠protonmail.com 31 Jan '19

31 Jan '19

This is a multi-part message in MIME format. --b1_ce770359f41de57b3c63a57268b4224b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 WW91IGFkZGVkIGl0IHRocmVlIHRpbWVzLCBieSBoYW5kLCBhcyBldmlkZW50IGluIHlvdXIgZm9s bG93dXAgMTIuCgpZb3Ugc2hvdWxkIGZpeCB5b3VyIE1ha2VmaWxlIGluc3RlYWQgb2YgYmxhbWlu ZyBsbHZtIG9yIG15IHBlcmZlY3RseSBmaW5lIHNldHRpbmcuCgpPbiBUaHUsIEphbiAzMSwgMjAx OSBhdCAwOToxMywgSG93YXJkIENodSA8aHljQHN5bWFzLmNvbT4gd3JvdGU6Cgo+IHJ1Z2FAcHJv dG9ubWFpbC5jb20gd3JvdGU6Cj4+IFRoaXMgaXMgYSBtdWx0aS1wYXJ0IG1lc3NhZ2UgaW4gTUlN RSBmb3JtYXQuCj4KPiBQbGVhc2Ugc3RvcCB1c2luZyBIVE1MIGVtYWlsLgo+Pgo+PiAtLWIxX2Q4 NjM3ZGJiMTIwYTUyOWY0ZjI2ZDQzZDRiMDg5Y2VlCj4+IENvbnRlbnQtVHlwZTogdGV4dC9wbGFp bjsgY2hhcnNldD1VVEYtOAo+PiBDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBiYXNlNjQKPj4K Pj4gU1dZZ1NTQmhaR1FnZEdobElDSXRkaUlnYjNCMGFXOXVJSFJ2SUdOc1lXNW5JR2x1SUM0dmJH bGljbUZ5YVdWekwwMWhhMlZtYVd4bAo+Cj4+IElmIEkgYWRkIHRoZSAiLXYiIG9wdGlvbiB0byBj bGFuZyBpbiAuL2xpYnJhcmllcy9NYWtlZmlsZSwgdGhlIHJlc3VsdGluZyBsb2cgc2hvd3MgdGhh dCB0aGUgbGlicmFyeSB3YXMgbGlua2VkIHR3aWNlLCBjYXVzaW5nIHN5bWJvbCBkdXBsaWNhdGlv bi4+Cj4+IFRoaXMgaG9sZHMgb24gbWFjb3MgMTAuMTMgd2l0aCBBcHBsZSB0b29sa2l0IDEwLjE0 IGFuZCB0aGUgb3JpZ2luYWwgbGx2bSA3LjAuMCB3aXRoIHRoZSBnaXZlbiBzZXR0aW5ncy4KPgo+ IFN0aWxsLCBub3RoaW5nIGluIHRoZSBPcGVuTERBUCBidWlsZCBzZXR1cCBkb2VzIHRoaXMuIFlv dSBkaWQgaXQgeW91cnNlbGYsCj4gbW9zdCBsaWtlbHkgdGhlIHNhbWUgd2F5IHlvdSBzZXQgIi1E X0ZPUlRJRllfU09VUkNFPTIiIDMgdGltZXMgaW4geW91ciBDUFBGTEFHUy4KPgo+IFRoaXMgSVRT IGlzIGNsb3NlZC4gVGhlcmUgaXMgbm8gT3BlbkxEQVAgU29mdHdhcmUgaXNzdWUgaGVyZSwgeW91 J3ZlIG1pc2NvbmZpZ3VyZWQKPiB5b3VyIGJ1aWxkLgo+Pgo+PiBPbiBNb24sIEphbiAyOCwgMjAx OSBhdCAxNzoxMSwgUXVhbmFoIEdpYnNvbi1Nb3VudCA8cXVhbmFoQHN5bWFzLmNvbT4gd3JvdGU6 Cj4+Cj4+PiAtLU9uIE1vbmRheSwgSmFudWFyeSAyOCwgMjAxOSAzOjM1IFBNICswMDAwIFJ1cGVy dCBHYWxsYWdoZXIKPj4+IDxydWdhQHByb3Rvbm1haWwuY29tPiB3cm90ZToKPj4+Cj4+Pj4gQXMg eW91IGNhbiBzZWUsIEkgYW0gdXNpbmcgdGhlIGRlZmF1bHQgQXBwbGUgbGlua2VyLCBhbmQgaGFy ZGVuZWQKPj4+PiBzZXR0aW5ncyBmb3IgdGhlIGNvbXBpbGVyLiBUcnkgdXNpbmcgdGhvc2Ugc2V0 dGluZ3MgeW91cnNlbGYsIGFuZCBzZWUKPj4+PiB3aGF0IGNvbWVzIG91dC4KPj4+Cj4+PiBJIHRl c3RlZCBvbiBGcmVlQlNEMTIgKHNpbmNlIGl0IHVzZXMgY2xhbmcgcmF0aGVyIHRoYW4gZ2NjKSB3 aXRoIHRoZQo+Pj4gZm9sbG93aW5nIGZsYWdzIGFuZCB0aGUgYnVpbGQgY29tcGxldGVkIHcvbyBp c3N1ZToKPj4+Cj4+PiBDRkxBR1M9IC1nIC1mc3RhY2stcHJvdGVjdG9yLWFsbCAtZm5vLW9taXQt ZnJhbWUtcG9pbnRlciAtZlBJQyAtZlBJRSAtTzIKPj4+IC1XZm9ybWF0IC1XZm9ybWF0LXNlY3Vy aXR5IC1XZXJyb3I9Zm9ybWF0LXNlY3VyaXR5Cj4+PiBMREZMQUdTPSAtV2wsLXoscmVscm8sLXos bm93IC1waWUKPj4+IENQUEZMQUdTPSAtRF9GT1JUSUZZX1NPVVJDRT0yIC1EX0ZPUlRJRllfU09V UkNFPTIgLURfRk9SVElGWV9TT1VSQ0U9Mgo+Cj4gLS0KPiAtLSBIb3dhcmQgQ2h1Cj4gQ1RPLCBT eW1hcyBDb3JwLiBodHRwOi8vd3d3LnN5bWFzLmNvbQo+IERpcmVjdG9yLCBIaWdobGFuZCBTdW4g aHR0cDovL2hpZ2hsYW5kc3VuLmNvbS9oeWMvCj4gQ2hpZWYgQXJjaGl0ZWN0LCBPcGVuTERBUCBo dHRwOi8vd3d3Lm9wZW5sZGFwLm9yZy9wcm9qZWN0Lw== --b1_ce770359f41de57b3c63a57268b4224b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 ICAgPGRpdj5Zb3UgYWRkZWQgaXQgdGhyZWUgdGltZXMsIGJ5IGhhbmQsIGFzIGV2aWRlbnQgaW4g eW91ciBmb2xsb3d1cCAxMi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PllvdSBzaG91bGQgZml4 IHlvdXIgTWFrZWZpbGUgaW5zdGVhZCBvZiBibGFtaW5nIGxsdm0gb3IgbXkgcGVyZmVjdGx5IGZp bmUgc2V0dGluZy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48 L2Rpdj5PbiBUaHUsIEphbiAzMSwgMjAxOSBhdCAwOToxMywgSG93YXJkIENodSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmh5Y0BzeW1hcy5jb20iIGNsYXNzPSIiPmh5Y0BzeW1hcy5jb208L2E+Jmd0OyB3 cm90ZTo8YmxvY2txdW90ZSBjbGFzcz0icHJvdG9ubWFpbF9xdW90ZSIgdHlwZT0iY2l0ZSI+ICBy dWdhQHByb3Rvbm1haWwuY29tIHdyb3RlOjxicj4mZ3Q7IFRoaXMgaXMgYSBtdWx0aS1wYXJ0IG1l c3NhZ2UgaW4gTUlNRSBmb3JtYXQuPGJyPjxicj5QbGVhc2Ugc3RvcCB1c2luZyBIVE1MIGVtYWls Ljxicj4mZ3Q7PGJyPiZndDsgLS1iMV9kODYzN2RiYjEyMGE1MjlmNGYyNmQ0M2Q0YjA4OWNlZTxi cj4mZ3Q7IENvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD1VVEYtODxicj4mZ3Q7IENv bnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IGJhc2U2NDxicj4mZ3Q7PGJyPiZndDsgU1dZZ1NTQmha R1FnZEdobElDSXRkaUlnYjNCMGFXOXVJSFJ2SUdOc1lXNW5JR2x1SUM0dmJHbGljbUZ5YVdWekww MWhhMlZtYVd4bDxicj48YnI+Jmd0OyBJZiBJIGFkZCB0aGUgIi12IiBvcHRpb24gdG8gY2xhbmcg aW4gLi9saWJyYXJpZXMvTWFrZWZpbGUsIHRoZSByZXN1bHRpbmcgbG9nIHNob3dzIHRoYXQgdGhl IGxpYnJhcnkgd2FzIGxpbmtlZCB0d2ljZSwgY2F1c2luZyBzeW1ib2wgZHVwbGljYXRpb24uJmd0 Ozxicj4mZ3Q7IFRoaXMgaG9sZHMgb24gbWFjb3MgMTAuMTMgd2l0aCBBcHBsZSB0b29sa2l0IDEw LjE0IGFuZCB0aGUgb3JpZ2luYWwgbGx2bSA3LjAuMCB3aXRoIHRoZSBnaXZlbiBzZXR0aW5ncy48 YnI+PGJyPlN0aWxsLCBub3RoaW5nIGluIHRoZSBPcGVuTERBUCBidWlsZCBzZXR1cCBkb2VzIHRo aXMuIFlvdSBkaWQgaXQgeW91cnNlbGYsPGJyPm1vc3QgbGlrZWx5IHRoZSBzYW1lIHdheSB5b3Ug c2V0ICItRF9GT1JUSUZZX1NPVVJDRT0yIiAzIHRpbWVzIGluIHlvdXIgQ1BQRkxBR1MuPGJyPjxi cj5UaGlzIElUUyBpcyBjbG9zZWQuIFRoZXJlIGlzIG5vIE9wZW5MREFQIFNvZnR3YXJlIGlzc3Vl IGhlcmUsIHlvdSd2ZSBtaXNjb25maWd1cmVkPGJyPnlvdXIgYnVpbGQuPGJyPiZndDs8YnI+Jmd0 OyBPbiBNb24sIEphbiAyOCwgMjAxOSBhdCAxNzoxMSwgUXVhbmFoIEdpYnNvbi1Nb3VudCAmbHQ7 cXVhbmFoQHN5bWFzLmNvbSZndDsgd3JvdGU6PGJyPiZndDs8YnI+Jmd0OyZndDsgLS1PbiBNb25k YXksIEphbnVhcnkgMjgsIDIwMTkgMzozNSBQTSArMDAwMCBSdXBlcnQgR2FsbGFnaGVyPGJyPiZn dDsmZ3Q7ICZsdDtydWdhQHByb3Rvbm1haWwuY29tJmd0OyB3cm90ZTo8YnI+Jmd0OyZndDs8YnI+ Jmd0OyZndDsmZ3Q7IEFzIHlvdSBjYW4gc2VlLCBJIGFtIHVzaW5nIHRoZSBkZWZhdWx0IEFwcGxl IGxpbmtlciwgYW5kIGhhcmRlbmVkPGJyPiZndDsmZ3Q7Jmd0OyBzZXR0aW5ncyBmb3IgdGhlIGNv bXBpbGVyLiBUcnkgdXNpbmcgdGhvc2Ugc2V0dGluZ3MgeW91cnNlbGYsIGFuZCBzZWU8YnI+Jmd0 OyZndDsmZ3Q7IHdoYXQgY29tZXMgb3V0Ljxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBJIHRlc3Rl ZCBvbiBGcmVlQlNEMTIgKHNpbmNlIGl0IHVzZXMgY2xhbmcgcmF0aGVyIHRoYW4gZ2NjKSB3aXRo IHRoZTxicj4mZ3Q7Jmd0OyBmb2xsb3dpbmcgZmxhZ3MgYW5kIHRoZSBidWlsZCBjb21wbGV0ZWQg dy9vIGlzc3VlOjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBDRkxBR1M9IC1nIC1mc3RhY2stcHJv dGVjdG9yLWFsbCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlciAtZlBJQyAtZlBJRSAtTzI8YnI+Jmd0 OyZndDsgLVdmb3JtYXQgLVdmb3JtYXQtc2VjdXJpdHkgLVdlcnJvcj1mb3JtYXQtc2VjdXJpdHk8 YnI+Jmd0OyZndDsgTERGTEFHUz0gLVdsLC16LHJlbHJvLC16LG5vdyAtcGllPGJyPiZndDsmZ3Q7 IENQUEZMQUdTPSAtRF9GT1JUSUZZX1NPVVJDRT0yIC1EX0ZPUlRJRllfU09VUkNFPTIgLURfRk9S VElGWV9TT1VSQ0U9Mjxicj48YnI+PGJyPi0tPGJyPiAgLS0gSG93YXJkIENodTxicj4gIENUTywg U3ltYXMgQ29ycC4gICAgICAgICAgIGh0dHA6Ly93d3cuc3ltYXMuY29tPGJyPiAgRGlyZWN0b3Is IEhpZ2hsYW5kIFN1biAgICAgaHR0cDovL2hpZ2hsYW5kc3VuLmNvbS9oeWMvPGJyPiAgQ2hpZWYg QXJjaGl0ZWN0LCBPcGVuTERBUCAgaHR0cDovL3d3dy5vcGVubGRhcC5vcmcvcHJvamVjdC88YnI+ PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2Pg== --b1_ce770359f41de57b3c63a57268b4224b--

1 0

Re: (ITS#8959) duplicate symbols
by hyc＠symas.com 31 Jan '19

31 Jan '19

ruga(a)protonmail.com wrote: > This is a multi-part message in MIME format. Please stop using HTML email. > > --b1_d8637dbb120a529f4f26d43d4b089cee > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: base64 > > SWYgSSBhZGQgdGhlICItdiIgb3B0aW9uIHRvIGNsYW5nIGluIC4vbGlicmFyaWVzL01ha2VmaWxl > If I add the "-v" option to clang in ./libraries/Makefile, the resulting log shows that the library was linked twice, causing symbol duplication.> > This holds on macos 10.13 with Apple toolkit 10.14 and the original llvm 7.0.0 with the given settings. Still, nothing in the OpenLDAP build setup does this. You did it yourself, most likely the same way you set "-D_FORTIFY_SOURCE=2" 3 times in your CPPFLAGS. This ITS is closed. There is no OpenLDAP Software issue here, you've misconfigured your build. > > On Mon, Jan 28, 2019 at 17:11, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > >> --On Monday, January 28, 2019 3:35 PM +0000 Rupert Gallagher >> <ruga(a)protonmail.com> wrote: >> >>> As you can see, I am using the default Apple linker, and hardened >>> settings for the compiler. Try using those settings yourself, and see >>> what comes out. >> >> I tested on FreeBSD12 (since it uses clang rather than gcc) with the >> following flags and the build completed w/o issue: >> >> CFLAGS= -g -fstack-protector-all -fno-omit-frame-pointer -fPIC -fPIE -O2 >> -Wformat -Wformat-security -Werror=format-security >> LDFLAGS= -Wl,-z,relro,-z,now -pie >> CPPFLAGS= -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 -- -- 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#8959) duplicate symbols
by ruga＠protonmail.com 30 Jan '19

30 Jan '19

This is a multi-part message in MIME format. --b1_d8637dbb120a529f4f26d43d4b089cee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SWYgSSBhZGQgdGhlICItdiIgb3B0aW9uIHRvIGNsYW5nIGluIC4vbGlicmFyaWVzL01ha2VmaWxl LCB0aGUgcmVzdWx0aW5nIGxvZyBzaG93cyB0aGF0IHRoZSBsaWJyYXJ5IHdhcyBsaW5rZWQgdHdp Y2UsIGNhdXNpbmcgc3ltYm9sIGR1cGxpY2F0aW9uLgoKVGhpcyBob2xkcyBvbiBtYWNvcyAxMC4x MyB3aXRoIEFwcGxlIHRvb2xraXQgMTAuMTQgYW5kIHRoZSBvcmlnaW5hbCBsbHZtIDcuMC4wIHdp dGggdGhlIGdpdmVuIHNldHRpbmdzLgoKT24gTW9uLCBKYW4gMjgsIDIwMTkgYXQgMTc6MTEsIFF1 YW5haCBHaWJzb24tTW91bnQgPHF1YW5haEBzeW1hcy5jb20+IHdyb3RlOgoKPiAtLU9uIE1vbmRh eSwgSmFudWFyeSAyOCwgMjAxOSAzOjM1IFBNICswMDAwIFJ1cGVydCBHYWxsYWdoZXIKPiA8cnVn YUBwcm90b25tYWlsLmNvbT4gd3JvdGU6Cj4KPj4gQXMgeW91IGNhbiBzZWUsIEkgYW0gdXNpbmcg dGhlIGRlZmF1bHQgQXBwbGUgbGlua2VyLCBhbmQgaGFyZGVuZWQKPj4gc2V0dGluZ3MgZm9yIHRo ZSBjb21waWxlci4gVHJ5IHVzaW5nIHRob3NlIHNldHRpbmdzIHlvdXJzZWxmLCBhbmQgc2VlCj4+ IHdoYXQgY29tZXMgb3V0Lgo+Cj4gSSB0ZXN0ZWQgb24gRnJlZUJTRDEyIChzaW5jZSBpdCB1c2Vz IGNsYW5nIHJhdGhlciB0aGFuIGdjYykgd2l0aCB0aGUKPiBmb2xsb3dpbmcgZmxhZ3MgYW5kIHRo ZSBidWlsZCBjb21wbGV0ZWQgdy9vIGlzc3VlOgo+Cj4gQ0ZMQUdTPSAtZyAtZnN0YWNrLXByb3Rl Y3Rvci1hbGwgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLWZQSUMgLWZQSUUgLU8yCj4gLVdmb3Jt YXQgLVdmb3JtYXQtc2VjdXJpdHkgLVdlcnJvcj1mb3JtYXQtc2VjdXJpdHkKPiBMREZMQUdTPSAt V2wsLXoscmVscm8sLXosbm93IC1waWUKPiBDUFBGTEFHUz0gLURfRk9SVElGWV9TT1VSQ0U9MiAt RF9GT1JUSUZZX1NPVVJDRT0yIC1EX0ZPUlRJRllfU09VUkNFPTIKPgo+IEluIGFueSBjYXNlLCBJ IHRoaW5rIHdlJ3ZlIHdlbGwgZXN0YWJsaXNoZWQgdGhlIHByb2JsZW0geW91J3JlIGhpdHRpbmcg aGFzCj4gemVybyB0byBkbyB3aXRoIE9wZW5MREFQIGluIGFuZCBvZiBpdHNlbGYuIFlvdSdsbCBu ZWVkIHRvIHRha2UgdGhpcyB1cAo+IGVsc2V3aGVyZS4KPgo+IC0tUXVhbmFoCj4KPiAtLQo+Cj4g UXVhbmFoIEdpYnNvbi1Nb3VudAo+IFByb2R1Y3QgQXJjaGl0ZWN0Cj4gU3ltYXMgQ29ycG9yYXRp b24KPiBQYWNrYWdlZCwgY2VydGlmaWVkLCBhbmQgc3VwcG9ydGVkIExEQVAgc29sdXRpb25zIHBv d2VyZWQgYnkgT3BlbkxEQVA6Cj4gPGh0dHA6Ly93d3cuc3ltYXMuY29tPg== --b1_d8637dbb120a529f4f26d43d4b089cee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 ICAgPGRpdj5JZiBJIGFkZCB0aGUgIi12IiBvcHRpb24gdG8gY2xhbmcgaW4gLi9saWJyYXJpZXMv TWFrZWZpbGUsIHRoZSByZXN1bHRpbmcgbG9nIHNob3dzIHRoYXQgdGhlIGxpYnJhcnkgd2FzIGxp bmtlZCB0d2ljZSwgY2F1c2luZyBzeW1ib2wgZHVwbGljYXRpb24uJm5ic3A7PC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj5UaGlzIGhvbGRzIG9uIG1hY29zIDEwLjEzIHdpdGggQXBwbGUgdG9vbGtp dCAxMC4xNCBhbmQgdGhlIG9yaWdpbmFsIGxsdm0gNy4wLjAgd2l0aCB0aGUgZ2l2ZW4gc2V0dGlu Z3MuJm5ic3A7PC9kaXY+IDxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2Pk9uIE1vbiwgSmFu IDI4LCAyMDE5IGF0IDE3OjExLCBRdWFuYWggR2lic29uLU1vdW50ICZsdDs8YSBocmVmPSJtYWls dG86cXVhbmFoQHN5bWFzLmNvbSIgY2xhc3M9IiI+cXVhbmFoQHN5bWFzLmNvbTwvYT4mZ3Q7IHdy b3RlOjxibG9ja3F1b3RlIGNsYXNzPSJwcm90b25tYWlsX3F1b3RlIiB0eXBlPSJjaXRlIj4gIC0t T24gTW9uZGF5LCBKYW51YXJ5IDI4LCAyMDE5IDM6MzUgUE0gKzAwMDAgUnVwZXJ0IEdhbGxhZ2hl cjxicj4mbHQ7cnVnYUBwcm90b25tYWlsLmNvbSZndDsgd3JvdGU6PGJyPjxicj4mZ3Q7IEFzIHlv dSBjYW4gc2VlLCBJIGFtIHVzaW5nIHRoZSBkZWZhdWx0IEFwcGxlIGxpbmtlciwgYW5kIGhhcmRl bmVkPGJyPiZndDsgc2V0dGluZ3MgZm9yIHRoZSBjb21waWxlci4gVHJ5IHVzaW5nIHRob3NlIHNl dHRpbmdzIHlvdXJzZWxmLCBhbmQgc2VlPGJyPiZndDsgd2hhdCBjb21lcyBvdXQuPGJyPjxicj5J IHRlc3RlZCBvbiBGcmVlQlNEMTIgKHNpbmNlIGl0IHVzZXMgY2xhbmcgcmF0aGVyIHRoYW4gZ2Nj KSB3aXRoIHRoZTxicj5mb2xsb3dpbmcgZmxhZ3MgYW5kIHRoZSBidWlsZCBjb21wbGV0ZWQgdy9v IGlzc3VlOjxicj48YnI+Q0ZMQUdTPSAtZyAtZnN0YWNrLXByb3RlY3Rvci1hbGwgLWZuby1vbWl0 LWZyYW1lLXBvaW50ZXIgLWZQSUMgLWZQSUUgLU8yPGJyPi1XZm9ybWF0IC1XZm9ybWF0LXNlY3Vy aXR5IC1XZXJyb3I9Zm9ybWF0LXNlY3VyaXR5PGJyPkxERkxBR1M9IC1XbCwteixyZWxybywteixu b3cgLXBpZTxicj5DUFBGTEFHUz0gLURfRk9SVElGWV9TT1VSQ0U9MiAtRF9GT1JUSUZZX1NPVVJD RT0yIC1EX0ZPUlRJRllfU09VUkNFPTI8YnI+PGJyPjxicj5JbiBhbnkgY2FzZSwgSSB0aGluayB3 ZSd2ZSB3ZWxsIGVzdGFibGlzaGVkIHRoZSBwcm9ibGVtIHlvdSdyZSBoaXR0aW5nIGhhczxicj56 ZXJvIHRvIGRvIHdpdGggT3BlbkxEQVAgaW4gYW5kIG9mIGl0c2VsZi4gIFlvdSdsbCBuZWVkIHRv IHRha2UgdGhpcyB1cDxicj5lbHNld2hlcmUuPGJyPjxicj4tLVF1YW5haDxicj48YnI+LS08YnI+ PGJyPlF1YW5haCBHaWJzb24tTW91bnQ8YnI+UHJvZHVjdCBBcmNoaXRlY3Q8YnI+U3ltYXMgQ29y cG9yYXRpb248YnI+UGFja2FnZWQsIGNlcnRpZmllZCwgYW5kIHN1cHBvcnRlZCBMREFQIHNvbHV0 aW9ucyBwb3dlcmVkIGJ5IE9wZW5MREFQOjxicj4mbHQ7aHR0cDovL3d3dy5zeW1hcy5jb20mZ3Q7 PGJyPjxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+ --b1_d8637dbb120a529f4f26d43d4b089cee--

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs