Re: (ITS#8963) Start TLS failed errors on back-ldap binds / short timeout, config option request
by hyc＠symas.com
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/
4 years, 4 months
Re: (ITS#8968) Async connect mode does not work on Solaris
by quanah＠symas.com
--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>
4 years, 4 months
Re: (ITS#8957)
by quanah＠symas.com
--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>
4 years, 4 months
Re: (ITS#8959) duplicate symbols
by quanah＠symas.com
--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>
4 years, 4 months
Re: (ITS#8575) Argon2 Password hashing contrib module
by simon＠slevermann.de
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,
4 years, 4 months
Re: (ITS#8959) duplicate symbols
by quanah＠symas.com
--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>
4 years, 4 months
Re: (ITS#8959) duplicate symbols
by ruga＠protonmail.com
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--
4 years, 4 months
Re: (ITS#8959) duplicate symbols
by hyc＠symas.com
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/
4 years, 4 months
Re: (ITS#8959) duplicate symbols
by ruga＠protonmail.com
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--
4 years, 4 months
