[PATCH 2 of 2] SSL: let it build against BoringSSL
Maxim Dounin
mdounin at mdounin.ru
Wed Jul 30 04:15:46 UTC 2014
Hello!
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
http://nginx.org/
More information about the nginx-devel
mailing list