seems, our CI for boringssl is broken. I see "openssl" there https://travis-ci.com/github/haproxy/haproxy/jobs/397911591#L1102-L1103
вс, 11 окт. 2020 г. в 15:06, László Soós <[email protected]>: > Hi Willy, All, > > Starting from 2.1.9 compilation fails with: > > src/ssl_sock.c:1231:39: warning: 'struct certificate_ocsp' declared inside > parameter list will not be visible outside of this definition or declaration > 1231 | static void ssl_sock_free_ocsp(struct certificate_ocsp *ocsp) > | ^~~~~~~~~~~~~~~~ > src/ssl_sock.c: In function 'ssl_sock_free_ocsp': > src/ssl_sock.c:1236:6: error: dereferencing pointer to incomplete type > 'struct certificate_ocsp' > 1236 | ocsp->refcount--; > | ^~ > CC src/mux_fcgi.o > CC src/cfgparse-listen.o > CC src/http_ana.o > At top level: > src/ssl_sock.c:1231:13: warning: 'ssl_sock_free_ocsp' defined but not used > [-Wunused-function] > 1231 | static void ssl_sock_free_ocsp(struct certificate_ocsp *ocsp) > > ---- > I went and checked source code (for 2.2.4 as it has the same problem) > > https://git.haproxy.org/?p=haproxy-2.2.git;a=blob;f=src/ssl_sock.c;h=019597ae76f2cb926b7ad42baf6378cf3456c417;hb=HEAD > LINE 1290 > static void ssl_sock_free_ocsp(struct certificate_ocsp *ocsp) > > This is defined in a section: > > #if ((defined SSL_CTRL_SET_TLSEXT_STATUS_REQ_CB && !defined OPENSSL_NO_OCSP) > || defined OPENSSL_IS_BORINGSSL) > > If I go up to LINE 851 where struct certificate_ocsp is defined, it's > being in a section: > #if (defined SSL_CTRL_SET_TLSEXT_STATUS_REQ_CB && !defined OPENSSL_NO_OCSP) > > > So struct certificate_ocsp will not be defined for BORINGSSL and > compilation fails. > > My quick solution was (maybe not the best but it works) to move the struct > def above the wrong section like this: > #if ((defined SSL_CTRL_SET_TLSEXT_STATUS_REQ_CB && !defined > OPENSSL_NO_OCSP) || defined OPENSSL_IS_BORINGSSL) > /* > * struct alignment works here such that the key.key is the same as > key_data > * Do not change the placement of key_data > */ > struct certificate_ocsp { > struct ebmb_node key; > unsigned char key_data[OCSP_MAX_CERTID_ASN1_LENGTH]; > struct buffer response; > int refcount; > long expire; > }; > #endif > > Can you consider this as a bug and maybe potentially fix it in future > releases? > > > For the records after this 'patch' I get the below warnings with BoringSSL > but I think it's safe to ignore (?): > .... > CC src/hlua_fcn.o > CC src/namespace.o > src/ssl_sock.c:1292:13: warning: 'ssl_sock_free_ocsp' defined but not used > [-Wunused-function] > 1292 | static void ssl_sock_free_ocsp(struct certificate_ocsp *ocsp) > | ^~~~~~~~~~~~~~~~~~ > CC src/mux_fcgi.o > CC src/mux_h1.o > In file included from include/haproxy/pool.h:29, > from include/haproxy/chunk.h:31, > from include/haproxy/dynbuf.h:33, > from include/haproxy/channel.h:27, > from src/ssl_crtlist.c:23: > src/ssl_crtlist.c: In function 'crtlist_parse_file': > include/haproxy/list.h:51:70: warning: potential null pointer dereference > [-Wnull-dereference] > 51 | #define LIST_ADDQ(lh, el) ({ (el)->p = (lh)->p; (el)->p->n = > (lh)->p = (el); (el)->n = (lh); (el); }) > | > ~~~~~~~~^~~~~~ > src/ssl_crtlist.c:425:3: note: in expansion of macro 'LIST_ADDQ' > 425 | LIST_ADDQ(&ckchs->crtlist_entry, &entry->by_ckch_store); > | ^~~~~~~~~ > include/haproxy/list.h:51:44: warning: potential null pointer dereference > [-Wnull-dereference] > 51 | #define LIST_ADDQ(lh, el) ({ (el)->p = (lh)->p; (el)->p->n = > (lh)->p = (el); (el)->n = (lh); (el); }) > | ~~~~^~~ > src/ssl_crtlist.c:425:3: note: in expansion of macro 'LIST_ADDQ' > 425 | LIST_ADDQ(&ckchs->crtlist_entry, &entry->by_ckch_store); > | ^~~~~~~~~ > CC src/mux_h2.o > CC src/backend.o > CC src/cfgparse.o > .... > > Thanks, > sooslaca > >
