Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict
On Sat, 23 Jun 2018 at 11:35, PGNet Dev wrote: > > > Sure. Your attitude and threats are not helpful in this conversation though. > > Threats? WTF are you talking about? Talking about: > I'll have to decide whether I'm more interested in haproxy, or a consistently > 'modern/current' openssl api. Atm, I'm leaning to sticking with the openssl > api restriction(s). Not sure how I'd have to interpret this other than a passive-aggressive threat. > I was a having a constructive exchange with someone I thought was > interested in addressing an issue, and looking into what I might > contribute to address it. I just said: > And someone can step up and send a patch or it will > be updated further down the line, but you are making a big deal out of > it, which it really is not. If you want to contribute, that's great and welcomed. A little less confrontational and little more constructive language would certainly not hurt this conversation is what I'm saying. cheers, lukas
Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict
Sure. Your attitude and threats are not helpful in this conversation though. Threats? WTF are you talking about? I was a having a constructive exchange with someone I thought was interested in addressing an issue, and looking into what I might contribute to address it. Guess not. Good luck.
Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict
>> it's complicated to keep everything clean but any help is welcomed. > > Step 1 has been simply to understand the problem. Sure. Your attitude and threats are not helpful in this conversation though. > What I'm suggesting is that there's a possibility -- as per my other > post, still unclear to me -- that openssl 1.1.1, with which tls1.3 > support will officially 'arrive', will have tighter restrictions on use > of prior versions' APIs. I already told you: both OpenSSL 1.1.1 and TLSv1.3 work fine. While other projects fixed cosmetic API issues, we worked with the OpenSSL team to find solutions for catastrophic failures in OpenSSL 1.1.1 alpha and beta, so they can fix it before the 1.1.1 release: https://github.com/openssl/openssl/issues/5330 https://github.com/openssl/openssl/pull/6388 https://github.com/openssl/openssl/pull/6432 https://www.mail-archive.com/haproxy@formilux.org/msg29592.html https://github.com/openssl/openssl/issues/6541 The priority being fixing actual bugs and compatibility issues, not build issues that come up when OpenSSL is compiled with strict API's. > Will use of v<1.1.0 apis still be just deprecated? or dropped? And, in > either case, how will downstream apps -- e.g., haproxy -- deal with it. There is no change between 1.1.0 and 1.1.1 regarding the old API's (which I already implied in my earlier email). > Currently, apparently, haproxy doesn't deal with the legacy-free, > current Openssl api, at all. No, it does not. And someone can step up and send a patch or it will be updated further down the line, but you are making a big deal out of it, which it really is not. cheers, lukas
Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict
On 6/22/18 5:21 PM, William Lallemand wrote: Well, unfortunately haproxy is a very portable software which compiles with a huge number of openssl and boringssl versions, Sure. So are a lot of other apps. > it's complicated to keep everything clean but any help is welcomed. Step 1 has been simply to understand the problem. particularly with tls1.3-capable openssl 1.1.1 "ComingSoon(tm)", might be worth a review What are you suggesting there ? I'm not sure of following, is there a problem with tls1.3 in haproxy? What I'm suggesting is that there's a possibility -- as per my other post, still unclear to me -- that openssl 1.1.1, with which tls1.3 support will officially 'arrive', will have tighter restrictions on use of prior versions' APIs. Will use of v<1.1.0 apis still be just deprecated? or dropped? And, in either case, how will downstream apps -- e.g., haproxy -- deal with it. Currently, apparently, haproxy doesn't deal with the legacy-free, current Openssl api, at all. Which simply causes me some pause.
Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict
On 6/22/18 6:14 PM, Lukas Tribus wrote:> configuration, removing old interfaces. Drop it from your openssl > configuration, and it will work fine. > >> particularly with tls1.3-capable openssl 1.1.1 "ComingSoon(tm)", might be worth a review > > Haproxy 1.8 and -dev works fine with both openssl 1.1.1 and TLS 1.3. > 1.1.1 is API compatible with 1.1.0 and there is nothing else on the > roadmap as far as I know. A different OpenSSL API (1.2) will break all > applications *anyway*, regardless whether we all remove supposedly > obsolete interfaces today. On the other hand, likely the new API does > not have all interfaces required to replace the old functionality. > That's at least how it was with 1.1.0 (with things that where actually > removed in 1.1.0). > > The --api=1.1.0 is helpful to understand what the openssl developers > currently believe will be removed one day, but they change their > opinion all the time and a new braking API change is not even > announced at this point. That's why I suggest you don't worry about it > and compile openssl without the API restriction. No OS will ship the > openssl library with such options anyway. Have to consider this, then. The point -- or at least one of them -- of DIY'ing the openssl builds is to *not* have "deprecated" (unsupported? recommended against? whatever?) dependencies ... and an app stack built on top of them. What a distro/OS ships is of little interest, or concern. I find their packaging, particularly when it comes to security apps, often unncessarily bloated, and sometimes sloppy. To me, admittedly. So far, the 'reset' of my stack -- including e.g., but not limited to, nginx, mariadb, postfix, varnish, php, radicale, etc etc -- has no problems with the api=1.1.0 (no deprecated) openssl. Each of those projects has decided to accept/address the reality of current openssl release build options; specifically, the option to restrict use of deprecated apis. The 1st 'issue' I've hit is, apparently, haproxy. I'll have to decide whether I'm more interested in haproxy, or a consistently 'modern/current' openssl api. Atm, I'm leaning to sticking with the openssl api restriction(s). I'll need to dig further into OpenSSL 1.1.1's API ... sure, it's 1.1.0 compatible, but simply don't yet understand what the implications, if any, for deprecated APIs is. Ongoing support? Further deprecation notices? Dropped? Just unclear to me atm. What I'd prefer, not surprisingly, is an haproxy that'll handle the option. I understand there's change involved. Thanks.
Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict
Hello, right, your (second) build issue is caused by the --api=1.1.0 configuration, removing old interfaces. Drop it from your openssl configuration, and it will work fine. > particularly with tls1.3-capable openssl 1.1.1 "ComingSoon(tm)", might be > worth a review Haproxy 1.8 and -dev works fine with both openssl 1.1.1 and TLS 1.3. 1.1.1 is API compatible with 1.1.0 and there is nothing else on the roadmap as far as I know. A different OpenSSL API (1.2) will break all applications *anyway*, regardless whether we all remove supposedly obsolete interfaces today. On the other hand, likely the new API does not have all interfaces required to replace the old functionality. That's at least how it was with 1.1.0 (with things that where actually removed in 1.1.0). The --api=1.1.0 is helpful to understand what the openssl developers currently believe will be removed one day, but they change their opinion all the time and a new braking API change is not even announced at this point. That's why I suggest you don't worry about it and compile openssl without the API restriction. No OS will ship the openssl library with such options anyway. cheers, lukas
Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict
On Fri, Jun 22, 2018 at 05:04:39PM -0700, PGNet Dev wrote: > fyi, > > all the ssl 'magic' for haproxy appears to be in > > src/ssl_sock.c > > which references > >*Acknowledgement: >* We'd like to specially thank the Stud project authors for a very > clean >* and well documented code which helped us understand how the > OpenSSL API >* ought to be used in non-blocking mode. This is one difficult part > which >* is not easy to get from the OpenSSL doc, and reading the Stud code > made >* it much more obvious than the examples in the OpenSSL package. > Keep up >* the good works, guys ! >* >* Stud is an extremely efficient and scalable SSL/TLS proxy which > combines >* particularly well with haproxy. For more info about this project, > visit : >* https://github.com/bumptech/stud > > stud's not been updated in years, and per > > https://github.com/bumptech/stud > > Stud is now officially abandonware, thanks for playing. > Recommended alternative: https://github.com/varnish/hitch > > Stud's exemplar usage of the OpenSSL api is likely not the best reference for > modern openssl api usage. > This was written a long time ago during the first implementation of ssl in 2012. Before working on the SSL in HAProxy, some of us contributes to stud, but that was 6 years ago, you can easily imagine that the code evolved since then. It's not like we are using stud within haproxy. > Taking a look, instead, at the usage approach taken by recommended 'hitch', > > git clone https://github.com/varnish/hitch.git > cd hitch > > their much-simpler, openssl 1.1.0-ready implementation code is in, > > ./src/hssl_locks.c > > which notes, correctly > > /* >* OpenSSL 1.1 has a new threading implementation that no longer >* requires the application to set its own locking callbacks. >*/ > > and avoids reference to, and use of, the previously mentioned deprecated > symbols (cref: https://www.openssl.org/news/openssl-1.1.0-notes.html) > > it builds/installs > > ./bootstrap > ./configure \ > --prefix=/usr/local/hitch \ > SSL_CFLAGS="-I/usr/local/openssl/include" \ > SSL_LIBS="-L/usr/local/openssl11/lib64 > -Wl,-rpath,/usr/local/openssl11/lib64 -lssl" \ > CRYPTO_CFLAGS="-I/usr/local/openssl/include" \ > CRYPTO_LIBS="-L/usr/local/openssl11/lib64 > -Wl,-rpath,/usr/local/openssl11/lib64 -lcrypto" > make -j4 > make install > > with no errors, > > ldd /usr/local/hitch/sbin/hitch | egrep "ssl|crypto" > libssl.so.1.1 => /usr/local/openssl11/lib64/libssl.so.1.1 > (0x7f8c27cb6000) > libcrypto.so.1.1 => /usr/local/openssl11/lib64/libcrypto.so.1.1 > (0x7f8c2780d000) > > /usr/local/hitch/sbin/hitch --version > hitch 1.4.8 > Well, unfortunately haproxy is a very portable software which compiles with a huge number of openssl and boringssl versions, it's complicated to keep everything clean but any help is welcomed. > particularly with tls1.3-capable openssl 1.1.1 "ComingSoon(tm)", might be > worth a review > What are you suggesting there ? I'm not sure of following, is there a problem with tls1.3 in haproxy? -- William Lallemand
Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict
fyi, all the ssl 'magic' for haproxy appears to be in src/ssl_sock.c which references *Acknowledgement: * We'd like to specially thank the Stud project authors for a very clean * and well documented code which helped us understand how the OpenSSL API * ought to be used in non-blocking mode. This is one difficult part which * is not easy to get from the OpenSSL doc, and reading the Stud code made * it much more obvious than the examples in the OpenSSL package. Keep up * the good works, guys ! * * Stud is an extremely efficient and scalable SSL/TLS proxy which combines * particularly well with haproxy. For more info about this project, visit : * https://github.com/bumptech/stud stud's not been updated in years, and per https://github.com/bumptech/stud Stud is now officially abandonware, thanks for playing. Recommended alternative: https://github.com/varnish/hitch Stud's exemplar usage of the OpenSSL api is likely not the best reference for modern openssl api usage. Taking a look, instead, at the usage approach taken by recommended 'hitch', git clone https://github.com/varnish/hitch.git cd hitch their much-simpler, openssl 1.1.0-ready implementation code is in, ./src/hssl_locks.c which notes, correctly /* * OpenSSL 1.1 has a new threading implementation that no longer * requires the application to set its own locking callbacks. */ and avoids reference to, and use of, the previously mentioned deprecated symbols (cref: https://www.openssl.org/news/openssl-1.1.0-notes.html) it builds/installs ./bootstrap ./configure \ --prefix=/usr/local/hitch \ SSL_CFLAGS="-I/usr/local/openssl/include" \ SSL_LIBS="-L/usr/local/openssl11/lib64 -Wl,-rpath,/usr/local/openssl11/lib64 -lssl" \ CRYPTO_CFLAGS="-I/usr/local/openssl/include" \ CRYPTO_LIBS="-L/usr/local/openssl11/lib64 -Wl,-rpath,/usr/local/openssl11/lib64 -lcrypto" make -j4 make install with no errors, ldd /usr/local/hitch/sbin/hitch | egrep "ssl|crypto" libssl.so.1.1 => /usr/local/openssl11/lib64/libssl.so.1.1 (0x7f8c27cb6000) libcrypto.so.1.1 => /usr/local/openssl11/lib64/libcrypto.so.1.1 (0x7f8c2780d000) /usr/local/hitch/sbin/hitch --version hitch 1.4.8 particularly with tls1.3-capable openssl 1.1.1 "ComingSoon(tm)", might be worth a review
Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict
On 6/22/18 3:55 PM, Lukas Tribus wrote: > Hello, > > > > On Fri, 22 Jun 2018 at 22:09, PGNet Dev wrote: >>> - share the openssl config line and installation commands >> >> gcc --version >> gcc (SUSE Linux) 8.1.1 20180614 [gcc-8-branch revision 261584] >> which openssl >> /usr/local/openssl11/bin/openssl >> openssl version >> OpenSSL 1.1.0h 27 Mar 2018 >> openssl version -f > > I meant how did you install openssl in /usr/local/openssl11? What > exact config, configure and make commands? `openssl -f` provides the effective, relevant compile flags as built/installed by cd openssl-1.1.0h unset SHARED_LDFLAGS LDFLAGS LIBDEPS ZLIB_INCLUDE C_INCLUDE_PATH echo $CFLAGS -O3 -Wall -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fmessage-length=0 -grecord-gcc-switches -march=native -mtune=native make clean ./config \ --prefix=/usr/local/openssl11 \ --openssldir=/usr/local/openssl11 \ --libdir=lib64 \ --api=1.1.0 \ threads shared \ -Wl,-rpath=/usr/local/openssl11/lib64 -Wa,--noexecstack -Wl,-z,relro,-z,now -Wall -fno-common \ enable-ec_nistp_64_gcc_128 enable-rfc3779 enable-ecdsa \ no-comp no-zlib no-zlib-dynamic no-sctp no-idea no-mdc2 no-rc2 no-rc5 no-ssl3 no-weak-ssl-ciphers \ -DOPENSSL_NO_BUF_FREELISTS -DOPENSSL_NO_HEARTBEAT -DSSL_FORBID_ENULL -D_GNU_SOURCE -DPURIFY -DTERMIO make -j4 make install Works, as built above, with numerous other app builds/installs; as do a number of leaner, more restrictive builds. > Anyway I tried it myself, this is how I was successful: > > - openssl: config openssl with something like: make clean; ./config > --prefix=/home/lukas/libsslbuildpgnet/ > -Wl,-rpath=/home/lukas/libsslbuildpgnet/lib > - openssl: make && make install_sw > - haproxy: use SSL_INC and SSL_LIB properly (don't prefix it with -I > and -L), and append the rpath configuration to SSL_LIB, so in my case > that would be SSL_INC=/home/lukas/libsslbuildpgnet/include/ > SSL_LIB="/home/lukas/libsslbuildpgnet/lib > -Wl,-rpath,/home/lukas/libsslbuildpgnet/lib" Here, that still fails with the deprecated symbol checks. The build's clearly not picking up on the fact that openssl 1.1.0 is built with current api and no deprecated symbol usage. Can you provide _your_ built openssl's `openssl -f` output?
Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict
Hello, On Fri, 22 Jun 2018 at 22:09, PGNet Dev wrote: > > - share the openssl config line and installation commands > > gcc --version > gcc (SUSE Linux) 8.1.1 20180614 [gcc-8-branch revision 261584] > which openssl > /usr/local/openssl11/bin/openssl > openssl version > OpenSSL 1.1.0h 27 Mar 2018 > openssl version -f I meant how did you install openssl in /usr/local/openssl11? What exact config, configure and make commands? Anyway I tried it myself, this is how I was successful: - openssl: config openssl with something like: make clean; ./config --prefix=/home/lukas/libsslbuildpgnet/ -Wl,-rpath=/home/lukas/libsslbuildpgnet/lib - openssl: make && make install_sw - haproxy: use SSL_INC and SSL_LIB properly (don't prefix it with -I and -L), and append the rpath configuration to SSL_LIB, so in my case that would be SSL_INC=/home/lukas/libsslbuildpgnet/include/ SSL_LIB="/home/lukas/libsslbuildpgnet/lib -Wl,-rpath,/home/lukas/libsslbuildpgnet/lib" With that, it works for me: lukas@dev:~/haproxy-1.8$ ./haproxy -vv | grep -e HA -e "OpenSSL version" HA-Proxy version 1.8.9 2018/05/18 Built with OpenSSL version : OpenSSL 1.1.0h 27 Mar 2018 Running on OpenSSL version : OpenSSL 1.1.0h 27 Mar 2018 lukas@dev:~/haproxy-1.8$ ldd haproxy | grep -e ssl -e crypto libssl.so.1.1 => /home/lukas/libsslbuildpgnet/lib/libssl.so.1.1 (0x7f1621865000) libcrypto.so.1.1 => /home/lukas/libsslbuildpgnet/lib/libcrypto.so.1.1 (0x7f16213d6000) lukas@dev:~/haproxy-1.8$ In your initial attempt where you see 2 different version (one fips, one not) there is an build issue. You probably already have openssl 1.1 in your default directories, so haproxy finds that one and somehow compiles, but that's dangerous. cheers, lukas
Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict
On 6/22/18 12:21 PM, Lukas Tribus wrote:
> - share:
> grep OPENSSL_VERSION_TEXT /usr/include/openssl/opensslv.h
> grep OPENSSL_VERSION_TEXT /usr/local/include/openssl/opensslv.h
> grep OPENSSL_VERSION_TEXT /usr/local/openssl11/include/openssl/opensslv.h
grep OPENSSL_VERSION_TEXT /usr/include/openssl/opensslv.h
# define OPENSSL_VERSION_TEXT"OpenSSL 1.1.0h-fips 27 Mar 2018"
# define OPENSSL_VERSION_TEXT"OpenSSL 1.1.0h 27 Mar 2018"
grep OPENSSL_VERSION_TEXT /usr/local/include/openssl/opensslv.h
grep: /usr/local/include/openssl/opensslv.h: No such file or directory
grep OPENSSL_VERSION_TEXT /usr/local/openssl11/include/openssl/opensslv.h
# define OPENSSL_VERSION_TEXT"OpenSSL 1.1.0h-fips 27 Mar 2018"
# define OPENSSL_VERSION_TEXT"OpenSSL 1.1.0h 27 Mar 2018"
where
cat /usr/local/openssl11/include/openssl/opensslv.h
...
42 # define OPENSSL_VERSION_NUMBER 0x1010008fL
# ifdef OPENSSL_FIPS
# define OPENSSL_VERSION_TEXT"OpenSSL 1.1.0h-fips 27 Mar
2018"
# else
# define OPENSSL_VERSION_TEXT"OpenSSL 1.1.0h 27 Mar 2018"
# endif
...
> - don't build with PCRE for now
> - retry the SSL_INC/SSL_LIB approach (but without PCRE at all)
> - share the gcc lines of your original attempt (atleast one compile
> line and the linking)
unset LDFLAGS
make clean
make V=1 \
TARGET=linux2628 \
USE_SYSTEMD=1 \
USE_OPENSSL=1 \
ADDINC=" -I/usr/local/openssl11/include" \
ADDLIB=" -L/usr/local/openssl11/lib64 -Wl,-rpath,/usr/local/openssl11/lib64" \
ADDLIB="-ldl"
...
gcc -Iinclude -Iebtree -Wall -O2 -g -fno-strict-aliasing
-Wdeclaration-after-statement -fwrapv -fno-strict-overflow
-Wno-format-truncation -Wno-null-dereference -Wno-unused-label
-DCONFIG_HAP_LINUX_SPLICE -DTPROXY -DCONFIG_HAP_LINUX_TPROXY -DCONFIG_HAP_CRYPT
-DENABLE_POLL -DENABLE_EPOLL -DUSE_CPU_AFFINITY -DASSUME_SPLICE_WORKS
-DUSE_ACCEPT4 -DNETFILTER -DUSE_THREAD -DUSE_OPENSSL -DUSE_SYSCALL_FUTEX
-DUSE_SYSTEMD -I/usr/local/openssl11/include
-DCONFIG_HAPROXY_VERSION=\"1.8.10-ec17d7a\"
-DCONFIG_HAPROXY_DATE=\"2018/06/22\" -c -o src/ssl_sock.o src/ssl_sock.c
src/ssl_sock.c: In function ‘ssl_locking_function’:
src/ssl_sock.c:220:13: error: ‘CRYPTO_LOCK’ undeclared (first use in
this function); did you mean ‘CRYPTO_RWLOCK’?
if (mode & CRYPTO_LOCK) {
^~~
CRYPTO_RWLOCK
src/ssl_sock.c:220:13: note: each undeclared identifier is reported
only once for each function it appears in
src/ssl_sock.c:221:14: error: ‘CRYPTO_READ’ undeclared (first use in
this function); did you mean ‘CRYPTO_ONCE’?
if (mode & CRYPTO_READ)
^~~
CRYPTO_ONCE
src/ssl_sock.c: In function ‘ssl_locking_init’:
src/ssl_sock.c:238:43: warning: implicit declaration of function
‘CRYPTO_num_locks’; did you mean ‘CRYPTO_realloc’?
[-Wimplicit-function-declaration]
ssl_rwlocks = malloc(sizeof(HA_RWLOCK_T)*CRYPTO_num_locks());
^~~~
CRYPTO_realloc
src/ssl_sock.c:245:2: warning: implicit declaration of function
‘CRYPTO_set_id_callback’; did you mean ‘BIO_set_callback’?
[-Wimplicit-function-declaration]
CRYPTO_set_id_callback(ssl_id_function);
^~
BIO_set_callback
src/ssl_sock.c:246:2: warning: implicit declaration of function
‘CRYPTO_set_locking_callback’; did you mean ‘BIO_set_info_callback’?
[-Wimplicit-function-declaration]
CRYPTO_set_locking_callback(ssl_locking_function);
^~~
BIO_set_info_callback
src/ssl_sock.c: In function ‘ssl_sock_do_create_cert’:
src/ssl_sock.c:1693:23: warning: implicit declaration of function
‘X509_get_notBefore’; did you mean ‘X509_getm_notBefore’?
[-Wimplicit-function-declaration]
if (!X509_gmtime_adj(X509_get_notBefore(newcrt), (long)-60*60*24) ||
^~
X509_getm_notBefore
src/ssl_sock.c:1693:23: warning: passing argument 1 of
‘X509_gmtime_adj’ makes pointer from integer without a cast [-Wint-conversion]
if (!X509_gmtime_adj(X509_get_notBefore(newcrt), (long)-60*60*24) ||
^~
In file included from /usr/local/openssl11/include/openssl/pem.h:17,
from /usr/local/openssl11/include/openssl/ssl.h:55,
from src/ssl_sock.c:43:
/usr/local/openssl11/include/openssl/x509.h:479:12: note: expected
‘ASN1_TIME *’ {aka ‘struct asn1_string_st *’} but argument is of type ‘int’
ASN1_TIME
Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict
Hello, On Fri, 22 Jun 2018 at 20:45, PGNet Dev wrote: > with 'your' advised "actual paths", and from Makefile > > # OpenSSL is packaged in various forms and with various dependencies. > # In general -lssl is enough, but on some platforms, -lcrypto may be > needed, > # reason why it's added by default. Some even need -lz, then you'll > need to > # pass it in the "ADDLIB" variable if needed. If your SSL libraries > are not > # in the usual path, use SSL_INC=/path/to/inc and > SSL_LIB=/path/to/lib. > > build fails, referencing deprecated, pre openssl 1.1.0 symbols, What I suggested was: > make V=1 \ > TARGET=linux2628 \ > USE_SYSTEMD=1 \ > USE_OPENSSL=1 \ > ADDLIB=" -I/usr/local/openssl11/include" \ > ADDLIB=" -L/usr/local/openssl11/lib64 > -Wl,-rpath,/usr/local/openssl11/lib64" \ > ADDLIB="-ldl" Anyway please stop including PCRE while troubleshooting this build issue. It only complicates things. You can include it again when you fixed the openssl build issue. I suggest: - don't build with PCRE for now - use the ADDLIB approach like suggest above - retry the SSL_INC/SSL_LIB approach (but without PCRE at all) - share the gcc lines of your original attempt (atleast one compile line and the linking) - share the openssl config line and installation commands - share: grep OPENSSL_VERSION_TEXT /usr/include/openssl/opensslv.h grep OPENSSL_VERSION_TEXT /usr/local/include/openssl/opensslv.h grep OPENSSL_VERSION_TEXT /usr/local/openssl11/include/openssl/opensslv.h Also, if you just want to test a specific openssl version locally, you may just compile it statically, as per README: http://git.haproxy.org/?p=haproxy.git;a=blob;f=README;h=1b012cc5e9100c74c5143ff4d3b0625ca07f648f;hb=ba86c6c25bf252e44589ae2b4d51a67c4f47d244#l123 cheers, lukas
Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict
Hi,
On 6/22/18 10:57 AM, Lukas Tribus wrote:
> SSL_INC and SSL_LIB expect actual paths, not additional commands.
> Replaces both with ADDLIB. Also you don't need to specify -lssl
> -lcrypt, USE_OPENSSL does not for you.
Then a bit confused by what I'm seeing atm.
With 'my' current, if incorrect, flags
unset LDFLAGS
make clean
make V=1 -j4 \
TARGET=linux2628 \
USE_PCRE2=1 \
USE_PCRE2_JIT=1 \
USE_OPENSSL=1 \
SSL_INC=" -I/usr/local/openssl11/include" \
SSL_LIB=" -L/usr/local/openssl11/lib64
-Wl,-rpath,/usr/local/openssl11/lib64" \
PCRE2_INC=" -I/usr/local/include" \
PCRE2_LIB=" -L/usr/local/lib64 -Wl,-rpath,/usr/local/lib64"
./haproxy -v
HA-Proxy version 1.8.10-ec17d7a 2018/06/22
ldd ./haproxy | egrep "ssl|crypto|pcre"
libssl.so.1.1 => /usr/local/openssl11/lib64/libssl.so.1.1
(0x7f8debd8a000)
libcrypto.so.1.1 => /usr/local/openssl11/lib64/libcrypto.so.1.1
(0x7f8deb8ef000)
libpcre2-8.so.0 => /usr/local/lib64/libpcre2-8.so.0
(0x7f8deb666000)
libpcre2-posix.so.2 => /usr/local/lib64/libpcre2-posix.so.2
(0x7f8deb463000)
with 'your' advised "actual paths", and from Makefile
# OpenSSL is packaged in various forms and with various dependencies.
# In general -lssl is enough, but on some platforms, -lcrypto may be
needed,
# reason why it's added by default. Some even need -lz, then you'll
need to
# pass it in the "ADDLIB" variable if needed. If your SSL libraries are
not
# in the usual path, use SSL_INC=/path/to/inc and SSL_LIB=/path/to/lib.
build fails, referencing deprecated, pre openssl 1.1.0 symbols,
unset LDFLAGS
make clean
make V=1 -j4 \
TARGET=linux2628 \
USE_PCRE2=1 \
USE_PCRE2_JIT=1 \
USE_OPENSSL=1 \
SSL_INC="/usr/local/openssl11/include" \
SSL_LIB="/usr/local/openssl11/lib64" \
PCRE2_INC="/usr/local/include" \
PCRE2_LIB="/usr/local/lib64"
...
gcc -Iinclude -Iebtree -Wall -O2 -g -fno-strict-aliasing
-Wdeclaration-after-statement -fwrapv -fno-strict-overflow
-Wno-format-truncation -Wno-null-dereference -Wno-unused-label
-DCONFIG_HAP_LINUX_SPLICE -DTPROXY -DCONFIG_HAP_LINUX_TPROXY -DCONFIG_HAP_CRYPT
-DENABLE_POLL -DENABLE_EPOLL -DUSE_CPU_AFFINITY -DASSUME_SPLICE_WORKS
-DUSE_ACCEPT4 -DNETFILTER -DUSE_THREAD -DUSE_OPENSSL
-I/usr/local/openssl11/include -DUSE_SYSCALL_FUTEX -DUSE_PCRE2
-DPCRE2_CODE_UNIT_WIDTH=8 -I/usr/local/include -DUSE_PCRE2_JIT
-DCONFIG_HAPROXY_VERSION=\"1.8.10-ec17d7a\"
-DCONFIG_HAPROXY_DATE=\"2018/06/22\" -c -o src/ssl_sock.o src/ssl_sock.c
src/ssl_sock.c: In function ‘ssl_locking_function’:
src/ssl_sock.c:220:13: error: ‘CRYPTO_LOCK’ undeclared (first
use in this function); did you mean ‘CRYPTO_RWLOCK’?
if (mode & CRYPTO_LOCK) {
^~~
CRYPTO_RWLOCK
src/ssl_sock.c:220:13: note: each undeclared identifier is
reported only once for each function it appears in
src/ssl_sock.c:221:14: error: ‘CRYPTO_READ’ undeclared (first
use in this function); did you mean ‘CRYPTO_ONCE’?
if (mode & CRYPTO_READ)
^~~
CRYPTO_ONCE
src/ssl_sock.c: In function ‘ssl_locking_init’:
src/ssl_sock.c:238:43: warning: implicit declaration of
function ‘CRYPTO_num_locks’; did you mean ‘CRYPTO_realloc’?
[-Wimplicit-function-declaration]
ssl_rwlocks = malloc(sizeof(HA_RWLOCK_T)*CRYPTO_num_locks());
^~~~
CRYPTO_realloc
src/ssl_sock.c:245:2: warning: implicit declaration of function
‘CRYPTO_set_id_callback’; did you mean ‘BIO_set_callback’?
[-Wimplicit-function-declaration]
CRYPTO_set_id_callback(ssl_id_function);
^~
BIO_set_callback
src/ssl_sock.c:246:2: warning: implicit declaration of function
‘CRYPTO_set_locking_callback’; did you mean ‘BIO_set_info_callback’?
[-Wimplicit-function-declaration]
CRYPTO_set_locking_callback(ssl_locking_function);
^~~
BIO_set_info_callback
src/ssl_sock.c: In function ‘ssl_sock_do_create_cert’:
src/ssl_sock.c:1693:23: warning: implicit declaration of
function ‘X509_get_notBefore’; did you mean ‘X509_getm_notBefore’?
[-Wimplicit-function-declaration]
if (!X509_gmtime_adj(X509_get_notBefore(newcrt),
(long)-60*60*24) ||
Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict
Hello, > make V=1 \ > TARGET=linux2628 \ > USE_SYSTEMD=1 \ > USE_OPENSSL=1 \ > SSL_INC=" -I/usr/local/openssl11/include" \ > SSL_LIB=" -L/usr/local/openssl11/lib64 > -Wl,-rpath,/usr/local/openssl11/lib64" \ > ADDLIB="-ldl -lssl -lcrypto" SSL_INC and SSL_LIB expect actual paths, not additional commands. Replaces both with ADDLIB. Also you don't need to specify -lssl -lcrypt, USE_OPENSSL does not for you. Try: > make V=1 \ > TARGET=linux2628 \ > USE_SYSTEMD=1 \ > USE_OPENSSL=1 \ > ADDLIB=" -I/usr/local/openssl11/include" \ > ADDLIB=" -L/usr/local/openssl11/lib64 > -Wl,-rpath,/usr/local/openssl11/lib64" \ > ADDLIB="-ldl" You may not even need -ldl. Lukas
Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict
> One possible cause could be pcre-config reporting -I/usr and causing > -I/usr/inc to be included before the SSL_INC path. fwiw, here, at my shell/env pcre-config --libs --libs-posix --libs-cpp --cflags --cflags-posix -L/usr/local/lib64 -lpcre -L/usr/local/lib64 -lpcreposix -lpcre -L/usr/local/lib64 -lpcrecpp -lpcre -I/usr/local/include -I/usr/local/include pcre2-config --libs8 --libs-posix --cflags --cflags-posix -L/usr/local/lib64 -lpcre2-8 -L/usr/local/lib64 -lpcre2-posix -lpcre2-8 -I/usr/local/include -I/usr/local/include
Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict
> Now to track down what's sourcing that "libpcre.so.1 =>
> /usr/lib64/libpcre.so.1"
looks like it's getting pulled in by libselinux & libsystemd ...
for l in $(ldd ./haproxy | awk '{print $3}')
do
echo -e "LIB: ${l}"
ldd ${l} | grep libpcre
done
LIB: /lib64/libcrypt.so.1
LIB: /lib64/libdl.so.2
LIB: /lib64/libpthread.so.0
LIB: /usr/local/openssl11/lib64/libssl.so.1.1
LIB: /usr/local/openssl11/lib64/libcrypto.so.1.1
!!! LIB: /usr/lib64/libsystemd.so.0
!!! libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x7f8ceaf4)
LIB: /usr/local/lib64/libpcre2-8.so.0
LIB: /usr/local/lib64/libpcre2-posix.so.2
libpcre2-8.so.0 => /usr/local/lib64/libpcre2-8.so.0
(0x7fc22474f000)
LIB: /lib64/libc.so.6
LIB: /lib64/libresolv.so.2
!!! LIB: /lib64/libselinux.so.1
!!! libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x7f0d94f13000)
LIB: /usr/lib64/libcap.so.2
LIB: /lib64/librt.so.1
LIB: /usr/lib64/liblzma.so.5
LIB: /usr/lib64/liblz4.so.1
LIB: /usr/lib64/libgcrypt.so.20
LIB: /usr/lib64/libgpg-error.so.0
LIB: /usr/lib64/libpcre.so.1
whether or not that's causing the -vv 'artifact' or not, dunno yet
Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict
On 6/22/18 7:44 AM, Willy Tarreau wrote: > Did you try to disable or adjust the PCRE flags as I indicated in > previous e-mail to see if it's the side effect ? I have _now_ ... needed a few minutes. > One possible cause could be pcre-config reporting -I/usr and causing > -I/usr/inc to be included before the SSL_INC path. A quick test could consist > in building without PCRE to validate or invalidate that assumption. If it > fixes it, please retry with "PCREDIR=" so that it doesn't try to set > PCRE_INC/PCRE_LIB. There's certainly a pcre-related 'oddity' ... regardless of build with, or without, PCRE, it's linking *something* with pcre1 lib. Notice ... Built WITH pcre2's libs spec'd make V=1 \ TARGET=linux2628 \ USE_SYSTEMD=1 \ USE_PCRE2=1 \ USE_PCRE2_JIT=1 \ USE_OPENSSL=1 \ SSL_INC=" -I/usr/local/openssl11/include" \ SSL_LIB=" -L/usr/local/openssl11/lib64 -Wl,-rpath,/usr/local/openssl11/lib64" \ PCRE2_INC=" -I/usr/local/include" \ PCRE2_LIB=" -L/usr/local/lib64 -Wl,-rpath,/usr/local/lib64" \ ADDLIB="-ldl -lssl -lcrypto -lpcre2-posix -lpcre2-8" ldd ./haproxy | egrep -i "ssl|crypto|pcre" libssl.so.1.1 => /usr/local/openssl11/lib64/libssl.so.1.1 (0x7f1d575c8000) libcrypto.so.1.1 => /usr/local/openssl11/lib64/libcrypto.so.1.1 (0x7f1d5712d000) libpcre2-8.so.0 => /usr/local/lib64/libpcre2-8.so.0 (0x7f1d56c0f000) libpcre2-posix.so.2 => /usr/local/lib64/libpcre2-posix.so.2 (0x7f1d56a0c000) ??? libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x7f27070bd000) haproxy -vv ... Built with OpenSSL version : OpenSSL 1.1.0h-fips 27 Mar 2018 Running on OpenSSL version : OpenSSL 1.1.0h 27 Mar 2018 ... Built withOUT pcre2 make V=1 \ TARGET=linux2628 \ USE_SYSTEMD=1 \ USE_OPENSSL=1 \ SSL_INC=" -I/usr/local/openssl11/include" \ SSL_LIB=" -L/usr/local/openssl11/lib64 -Wl,-rpath,/usr/local/openssl11/lib64" \ ADDLIB="-ldl -lssl -lcrypto" ... Built without PCRE or PCRE2 support (using libc's regex instead) ... ldd ./haproxy | egrep -i "ssl|crypto|pcre" libssl.so.1.1 => /usr/local/openssl11/lib64/libssl.so.1.1 (0x7f34c9591000) libcrypto.so.1.1 => /usr/local/openssl11/lib64/libcrypto.so.1.1 (0x7f34c90f6000) ??? libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x7f0a0c9d9000) haproxy -vv Built with OpenSSL version : OpenSSL 1.1.0h-fips 27 Mar 2018 Running on OpenSSL version : OpenSSL 1.1.0h 27 Mar 2018 Now to track down what's sourcing that "libpcre.so.1 => /usr/lib64/libpcre.so.1"
Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict
On Fri, Jun 22, 2018 at 07:03:36AM -0700, PGNet Dev wrote: > Hi > > On 6/21/18 10:50 PM, Willy Tarreau wrote:> Well, first please ensure you're > building latest fixes and not and old > > version otherwise you'll expose yourself to all these known and now fixed > > bugs : > > oops, missed that! :-/ > > switching to 'latest' in branch, v1.8.9, still see the same in "-vv" output, > > ldd `which haproxy` | egrep "ssl|crypto" > libssl.so.1.1 => /usr/local/openssl11/lib64/libssl.so.1.1 > (0x7f6a21894000) > libcrypto.so.1.1 => /usr/local/openssl11/lib64/libcrypto.so.1.1 > (0x7f6a213f9000) > > > haproxy -vv > HA-Proxy version 1.8.9-83616ec 2018/05/18 > Copyright 2000-2018 Willy Tarreau > > Build options : > TARGET = linux2628 > CPU = generic > CC = gcc > CFLAGS = -O2 -g -fno-strict-aliasing > -Wdeclaration-after-statement -fwrapv -fno-strict-overflow > -Wno-format-truncation -Wno-null-dereference -Wno-unused-label > OPTIONS = USE_OPENSSL=1 USE_SYSTEMD=1 USE_PCRE2=1 > USE_PCRE2_JIT=1 > > Default settings : > maxconn = 2000, bufsize = 16384, maxrewrite = 1024, > maxpollevents = 200 > > Built with OpenSSL version : OpenSSL 1.1.0h-fips 27 Mar 2018 > Running on OpenSSL version : OpenSSL 1.1.0h 27 Mar 2018 > ... > > > Again, not sure if it's a 'real' problem, or just a report artifact. Did you try to disable or adjust the PCRE flags as I indicated in previous e-mail to see if it's the side effect ? Willy
Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict
Hi On 6/21/18 10:50 PM, Willy Tarreau wrote:> Well, first please ensure you're building latest fixes and not and old > version otherwise you'll expose yourself to all these known and now fixed > bugs : oops, missed that! :-/ switching to 'latest' in branch, v1.8.9, still see the same in "-vv" output, ldd `which haproxy` | egrep "ssl|crypto" libssl.so.1.1 => /usr/local/openssl11/lib64/libssl.so.1.1 (0x7f6a21894000) libcrypto.so.1.1 => /usr/local/openssl11/lib64/libcrypto.so.1.1 (0x7f6a213f9000) haproxy -vv HA-Proxy version 1.8.9-83616ec 2018/05/18 Copyright 2000-2018 Willy Tarreau Build options : TARGET = linux2628 CPU = generic CC = gcc CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -fno-strict-overflow -Wno-format-truncation -Wno-null-dereference -Wno-unused-label OPTIONS = USE_OPENSSL=1 USE_SYSTEMD=1 USE_PCRE2=1 USE_PCRE2_JIT=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200 Built with OpenSSL version : OpenSSL 1.1.0h-fips 27 Mar 2018 Running on OpenSSL version : OpenSSL 1.1.0h 27 Mar 2018 ... Again, not sure if it's a 'real' problem, or just a report artifact.
Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict
Hello, On Thu, Jun 21, 2018 at 06:26:18PM -0700, PGNet Dev wrote: > I'm building haproxy 1.8.0 from tarball source. Well, first please ensure you're building latest fixes and not and old version otherwise you'll expose yourself to all these known and now fixed bugs : http://www.haproxy.org/bugs/bugs-1.8.0.html > I'm linking against a specific, local build of openssl v1.1.0 > > Explicitly specifying SSL_INC & SSL_LIB with rpath, > > make \ >TARGET=linux2628 \ >USE_SYSTEMD=1 \ >USE_PCRE2=1 USE_PCRE2_JIT=1 \ >USE_OPENSSL=1 \ > SSL_INC=" -I/usr/local/openssl11/include" \ > SSL_LIB=" -L/usr/local/openssl11/lib64 > -Wl,-rpath,/usr/local/openssl11/lib64" \ > ADDLIB="-ldl -lssl -lcrypto" > make install > > it builds/installs with no error > > which haproxy > /usr/local/sbin/haproxy > > and the linked libs are as intended, > > ldd /usr/local/sbin/haproxy | egrep "ssl|crypto" > libssl.so.1.1 => /usr/local/openssl11/lib64/libssl.so.1.1 > (0x7f071de04000) > libcrypto.so.1.1 => /usr/local/openssl11/lib64/libcrypto.so.1.1 > (0x7f071d969000) > > but checking haproxy version, > > haproxy -vv > HA-Proxy version 1.8.0 2017/11/26 > Copyright 2000-2017 Willy Tarreau > > Build options : > TARGET = linux2628 > ... > OPTIONS = USE_OPENSSL=1 USE_SYSTEMD=1 USE_PCRE2=1 > USE_PCRE2_JIT=1 > ... > Built with OpenSSL version : OpenSSL 1.1.0h-fips 27 Mar 2018 > Running on OpenSSL version : OpenSSL 1.1.0h 27 Mar 2018 > OpenSSL library supports TLS extensions : yes > OpenSSL library supports SNI : yes > OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 > ... > > references the wrong "Built with" OpenSSL version, namely the system > installed version, > > /usr/bin/openssl version > OpenSSL 1.1.0h-fips 27 Mar 2018 > > instead of my specified build > > /usr/local/openssl11/bin/openssl version > OpenSSL 1.1.0h 27 Mar 2018 > > As the ldd linked libs look ok, I suspect this is just an artifact of the > version check making (incorrect) assumptions about runtime bin path ... > > *IS* it just an artifact? Or is it an indication of improper linking/use? I agree these ones look odd. I could easily understand that "-fips" would not be reported, but here seeing it really makes me think it's running with the system's lib instead. Just looking at the code, the "built with" version comes from a macro : OPENSSL_VERSION_TEXT. So it was found at build time in ssl.h or some such files. Thus I suspect that despite your SSL_INC path it found the other one. One possible cause could be pcre-config reporting -I/usr and causing -I/usr/inc to be included before the SSL_INC path. A quick test could consist in building without PCRE to validate or invalidate that assumption. If it fixes it, please retry with "PCREDIR=" so that it doesn't try to set PCRE_INC/PCRE_LIB. Regards, Willy
