Re: BoringSSL commit dddb60e breaks compilation of HAProxy

[Willy Tarreau]

On Wed, Sep 08, 2021 at 12:34:49PM +0200, Aleksandar Lazic wrote:
> On 08.09.21 11:07, Willy Tarreau wrote:
> > On Wed, Sep 08, 2021 at 01:58:00PM +0500,  ??? wrote:
> > > ??, 8 . 2021 ?. ? 13:54, Willy Tarreau :
> > > 
> > > > On Wed, Sep 08, 2021 at 12:05:23PM +0500,  ??? wrote:
> > > > > Hello, Bob
> > > > > 
> > > > > I tracked an issue  https://github.com/haproxy/haproxy/issues/1386
> > > > > 
> > > > > 
> > > > > let's track activity there
> > > > 
> > > > Quite frankly, I'm seriously wondering how long we'll want to keep
> > > > supporting that constantly breaking library. Does it still provide
> > > > 
> > > 
> > > by "let us track activity" I do not mean that we are going to maintain
> > > BoringSSL :)
> > > 
> > > people will come from time to time with BoringSSL support request. 
> > > Existing
> > > github issue is good to redirect them to.
> > 
> > Oh this is how I understood it as well, I just think that you and a
> > handful of others have already spent a lot of energy on that lib and
> > I was only encouraging you not to spend way more than what you find
> > reasonable after this issue is created :-)
> 
> Is there another library which have the quic stuff implemented which
> can be used for quic development?

Fred told me that he manages to build it using the fork of openssl that
contains the proper stuff. Hopefully it should get merged soon. But with
BoringSSL the problem is that something that works on monday suddenly
fails to build on tuesday and there's no stable branch so you're just
forced to change your API to adapt to it on the fly. I don't want to
blame them too much because they always warned against this. It's been
convenient to start on QUIC but as soon as we can avoid this pain it
will be better to get rid of it.

Willy

Re: BoringSSL commit dddb60e breaks compilation of HAProxy

[Aleksandar Lazic]

On 08.09.21 11:07, Willy Tarreau wrote:

On Wed, Sep 08, 2021 at 01:58:00PM +0500,  ??? wrote:

??, 8 . 2021 ?. ? 13:54, Willy Tarreau :


On Wed, Sep 08, 2021 at 12:05:23PM +0500,  ??? wrote:

Hello, Bob

I tracked an issue  https://github.com/haproxy/haproxy/issues/1386


let's track activity there


Quite frankly, I'm seriously wondering how long we'll want to keep
supporting that constantly breaking library. Does it still provide



by "let us track activity" I do not mean that we are going to maintain
BoringSSL :)

people will come from time to time with BoringSSL support request. Existing
github issue is good to redirect them to.


Oh this is how I understood it as well, I just think that you and a
handful of others have already spent a lot of energy on that lib and
I was only encouraging you not to spend way more than what you find
reasonable after this issue is created :-)


Is there another library which have the quic stuff implemented which
can be used for quic development?


Willy

Re: BoringSSL commit dddb60e breaks compilation of HAProxy

[Willy Tarreau]

On Wed, Sep 08, 2021 at 01:58:00PM +0500,  ??? wrote:
> ??, 8 . 2021 ?. ? 13:54, Willy Tarreau :
> 
> > On Wed, Sep 08, 2021 at 12:05:23PM +0500,  ??? wrote:
> > > Hello, Bob
> > >
> > > I tracked an issue  https://github.com/haproxy/haproxy/issues/1386
> > >
> > >
> > > let's track activity there
> >
> > Quite frankly, I'm seriously wondering how long we'll want to keep
> > supporting that constantly breaking library. Does it still provide
> >
> 
> by "let us track activity" I do not mean that we are going to maintain
> BoringSSL :)
> 
> people will come from time to time with BoringSSL support request. Existing
> github issue is good to redirect them to.

Oh this is how I understood it as well, I just think that you and a
handful of others have already spent a lot of energy on that lib and
I was only encouraging you not to spend way more than what you find
reasonable after this issue is created :-)

Willy

Re: BoringSSL commit dddb60e breaks compilation of HAProxy

[Илья Шипицин]

ср, 8 сент. 2021 г. в 13:54, Willy Tarreau :

> On Wed, Sep 08, 2021 at 12:05:23PM +0500,  ??? wrote:
> > Hello, Bob
> >
> > I tracked an issue  https://github.com/haproxy/haproxy/issues/1386
> >
> >
> > let's track activity there
>
> Quite frankly, I'm seriously wondering how long we'll want to keep
> supporting that constantly breaking library. Does it still provide
>

by "let us track activity" I do not mean that we are going to maintain
BoringSSL :)

people will come from time to time with BoringSSL support request. Existing
github issue is good to redirect them to.



> any value that I'm not aware of ? It's not even possible to have
> the same version at the beginning and at the end of a maintenance
> branch, it's designed to constantly change and documented as such.
>
> I'd be strongly in favor for dropping it once it becomes too painful
> to deal with, and I sense that we're starting to get closer to that
> point now.
>
> Willy
>

Re: BoringSSL commit dddb60e breaks compilation of HAProxy

[Willy Tarreau]

On Wed, Sep 08, 2021 at 12:05:23PM +0500,  ??? wrote:
> Hello, Bob
> 
> I tracked an issue  https://github.com/haproxy/haproxy/issues/1386
> 
> 
> let's track activity there

Quite frankly, I'm seriously wondering how long we'll want to keep
supporting that constantly breaking library. Does it still provide
any value that I'm not aware of ? It's not even possible to have
the same version at the beginning and at the end of a maintenance
branch, it's designed to constantly change and documented as such.

I'd be strongly in favor for dropping it once it becomes too painful
to deal with, and I sense that we're starting to get closer to that
point now.

Willy

Re: BoringSSL commit dddb60e breaks compilation of HAProxy

[Илья Шипицин]

Hello, Bob

I tracked an issue  https://github.com/haproxy/haproxy/issues/1386


let's track activity there

вт, 7 сент. 2021 г. в 22:58, Zakharychev, Bob :

> BoringSSL commit dddb60e, "Make most of crypto/x509 opaque.", breaks
> compilation of HAProxy with the following errors (log from compiling
> HAProxy 2.4.4 with BoringSSL master branch commit a03c34c, but I suppose
> all other versions are equally affected):
>
>
> …
>
>   CC  src/ssl_sample.o
>
> In file included from include/haproxy/listener-t.h:37,
>
>  from include/haproxy/server-t.h:36,
>
>  from include/haproxy/lb_map-t.h:26,
>
>  from include/haproxy/backend-t.h:30,
>
>  from include/haproxy/proxy-t.h:35,
>
>  from include/haproxy/applet-t.h:31,
>
>  from include/haproxy/obj_type.h:26,
>
>  from src/ssl_sample.c:27:
>
> include/haproxy/openssl-compat.h: In function ‘X509_OBJECT_get0_X509_CRL’:
>
> include/haproxy/openssl-compat.h:182:23: error: dereferencing pointer to
> incomplete type ‘X509_OBJECT’ {aka ‘const struct x509_object_st’}
>
>  if (a == NULL || a->type != X509_LU_CRL) {
>
>^~
>
> src/ssl_sample.c: In function ‘smp_fetch_ssl_x_key_alg’:
>
> include/haproxy/openssl-compat.h:122:37: error: dereferencing pointer to
> incomplete type ‘X509’ {aka ‘struct x509_st’}
>
> #define X509_get_X509_PUBKEY(x) ((x)->cert_info->key)
>
>  ^~
>
> src/ssl_sample.c:716:55: note: in expansion of macro ‘X509_get_X509_PUBKEY’
>
>   X509_PUBKEY_get0_param(, NULL, NULL, NULL,
> X509_get_X509_PUBKEY(crt));
>
>^~~~
>
> make: *** [Makefile:945: src/ssl_sample.o] Error 1
>
>
>
> Indeed, BoringSSL commit dddb60e “unexported” these structs “aligning with
> OpenSSL” and directs to “Use the accessor APIs instead”. I couldn't figure
> out an easy fix to this - simply removing the two macros conditional on
> OPENSSL_IS_BORINGSSL in affected places doesn't fully help because while
> X509_get_X509_PUBKEY() accessor is now defined, X509_OBJECT_get0_X509_CRL()
> is still missing in BoringSSL. Therefore I defer the fix to HAProxy SSL
> experts - maybe it's actually BoringSSL that needs to be fixed by adding
> the missing accessor, or maybe the single loop in ssl_set_cert_crl_file()
> over all X509 store objects needs to be broken into two loops: one over
> certs returned by X509_STORE_get1_certs() and another over CRLs returned by
> X509_STORE_get1_crls().
>
> Thanks in advance for taking a stab at this,
>   Bob
>
>
>
>
>

Re: BoringSSL commit dddb60e breaks compilation of HAProxy

[Илья Шипицин]

yep :)

CI: Github Actions: temporarily disable BoringSSL builds ·
haproxy/haproxy@30ee296


I had a look, I found the same as you (no easy fix).

let us open github issue for tracking this.


вт, 7 сент. 2021 г. в 22:58, Zakharychev, Bob :

> BoringSSL commit dddb60e, "Make most of crypto/x509 opaque.", breaks
> compilation of HAProxy with the following errors (log from compiling
> HAProxy 2.4.4 with BoringSSL master branch commit a03c34c, but I suppose
> all other versions are equally affected):
>
>
> …
>
>   CC  src/ssl_sample.o
>
> In file included from include/haproxy/listener-t.h:37,
>
>  from include/haproxy/server-t.h:36,
>
>  from include/haproxy/lb_map-t.h:26,
>
>  from include/haproxy/backend-t.h:30,
>
>  from include/haproxy/proxy-t.h:35,
>
>  from include/haproxy/applet-t.h:31,
>
>  from include/haproxy/obj_type.h:26,
>
>  from src/ssl_sample.c:27:
>
> include/haproxy/openssl-compat.h: In function ‘X509_OBJECT_get0_X509_CRL’:
>
> include/haproxy/openssl-compat.h:182:23: error: dereferencing pointer to
> incomplete type ‘X509_OBJECT’ {aka ‘const struct x509_object_st’}
>
>  if (a == NULL || a->type != X509_LU_CRL) {
>
>^~
>
> src/ssl_sample.c: In function ‘smp_fetch_ssl_x_key_alg’:
>
> include/haproxy/openssl-compat.h:122:37: error: dereferencing pointer to
> incomplete type ‘X509’ {aka ‘struct x509_st’}
>
> #define X509_get_X509_PUBKEY(x) ((x)->cert_info->key)
>
>  ^~
>
> src/ssl_sample.c:716:55: note: in expansion of macro ‘X509_get_X509_PUBKEY’
>
>   X509_PUBKEY_get0_param(, NULL, NULL, NULL,
> X509_get_X509_PUBKEY(crt));
>
>^~~~
>
> make: *** [Makefile:945: src/ssl_sample.o] Error 1
>
>
>
> Indeed, BoringSSL commit dddb60e “unexported” these structs “aligning with
> OpenSSL” and directs to “Use the accessor APIs instead”. I couldn't figure
> out an easy fix to this - simply removing the two macros conditional on
> OPENSSL_IS_BORINGSSL in affected places doesn't fully help because while
> X509_get_X509_PUBKEY() accessor is now defined, X509_OBJECT_get0_X509_CRL()
> is still missing in BoringSSL. Therefore I defer the fix to HAProxy SSL
> experts - maybe it's actually BoringSSL that needs to be fixed by adding
> the missing accessor, or maybe the single loop in ssl_set_cert_crl_file()
> over all X509 store objects needs to be broken into two loops: one over
> certs returned by X509_STORE_get1_certs() and another over CRLs returned by
> X509_STORE_get1_crls().
>
> Thanks in advance for taking a stab at this,
>   Bob
>
>
>
>
>

BoringSSL commit dddb60e breaks compilation of HAProxy

[Zakharychev, Bob]

BoringSSL commit dddb60e, "Make most of crypto/x509 opaque.", breaks 
compilation of HAProxy with the following errors (log from compiling HAProxy 
2.4.4 with BoringSSL master branch commit a03c34c, but I suppose all other 
versions are equally affected):

...
  CC  src/ssl_sample.o
In file included from include/haproxy/listener-t.h:37,
 from include/haproxy/server-t.h:36,
 from include/haproxy/lb_map-t.h:26,
 from include/haproxy/backend-t.h:30,
 from include/haproxy/proxy-t.h:35,
 from include/haproxy/applet-t.h:31,
 from include/haproxy/obj_type.h:26,
 from src/ssl_sample.c:27:
include/haproxy/openssl-compat.h: In function 'X509_OBJECT_get0_X509_CRL':
include/haproxy/openssl-compat.h:182:23: error: dereferencing pointer to 
incomplete type 'X509_OBJECT' {aka 'const struct x509_object_st'}
 if (a == NULL || a->type != X509_LU_CRL) {
   ^~
src/ssl_sample.c: In function 'smp_fetch_ssl_x_key_alg':
include/haproxy/openssl-compat.h:122:37: error: dereferencing pointer to 
incomplete type 'X509' {aka 'struct x509_st'}
#define X509_get_X509_PUBKEY(x) ((x)->cert_info->key)
 ^~
src/ssl_sample.c:716:55: note: in expansion of macro 'X509_get_X509_PUBKEY'
  X509_PUBKEY_get0_param(, NULL, NULL, NULL, 
X509_get_X509_PUBKEY(crt));
   ^~~~
make: *** [Makefile:945: src/ssl_sample.o] Error 1

Indeed, BoringSSL commit dddb60e "unexported" these structs "aligning with 
OpenSSL" and directs to "Use the accessor APIs instead". I couldn't figure out 
an easy fix to this - simply removing the two macros conditional on 
OPENSSL_IS_BORINGSSL in affected places doesn't fully help because while 
X509_get_X509_PUBKEY() accessor is now defined, X509_OBJECT_get0_X509_CRL() is 
still missing in BoringSSL. Therefore I defer the fix to HAProxy SSL experts - 
maybe it's actually BoringSSL that needs to be fixed by adding the missing 
accessor, or maybe the single loop in ssl_set_cert_crl_file() over all X509 
store objects needs to be broken into two loops: one over certs returned by 
X509_STORE_get1_certs() and another over CRLs returned by 
X509_STORE_get1_crls().

Thanks in advance for taking a stab at this,
  Bob