[PATCH 2 of 2] SSL: let it build against BoringSSL

Maxim Dounin mdounin at mdounin.ru
Wed Jul 30 04:15:46 UTC 2014


On Tue, Jul 29, 2014 at 04:19:39PM -0700, Piotr Sikora wrote:

> Hey Maxim,
> > I think that it's better idea to preserve the common code rather
> > than to add unneded #ifndef's.
> Well, my argument for #ifndefs is that both BoringSSL and LibreSSL
> (for which I have patch in my queue) removed support for export cipher
> suites, so I don't see a point in calling a function that we know
> doesn't do anything and that might be removed sooner rather than
> later.

The problem is lots of added lines required to avoid calling it.

> BoringSSL made SSL_CTX_set_tmp_rsa_callback() a no-op (at least for
> now) and just ignores the callback.
> LibreSSL sets and calls the callback (because of the
> SSL_OP_EPHEMERAL_RSA, which is still supported, even though it
> violates TLS standard), but I expect it might get removed soon... and
> then, depending on their implementation, it might put an error on the
> error queue, which will just mess things for us.
> I'm going to send the LibreSSL patch in a moment and let's see if the
> #ifndefs are still bothering you, but I feel rather strongly about
> keeping them.

If expected further API changes in BoringSSL/LibreSSL is a 
concern, we may want to wait longer before the API settles a bit.  
I believe I've already suggested this during previous discussion 
about LibreSSL.

> > This one scares me though.  In particular, because BoringSSL
> > managed to move various EVP_* functions to CIPHER library, and
> > this looks strange.  I also wonder how many similar changes are
> > unnoticed because they don't break build...
> Rest seems to work fine :)
> I'm rather committed to switching to BoringSSL myself in the near
> future, so this is more than just "it compiles" change.

Even if it works, it would be non-trivial to support code with 
such #if's.  We may want to add some additional level of 
abstraction here.  Not sure if it worth the effort in this 
particular case though.

Maxim Dounin

More information about the nginx-devel mailing list