Hello!

On Sat, May 04, 2019 at 03:18:12AM +0200, Pascal Ernster wrote:

> [2019-05-04 02:37] Maxim Dounin:
> > Thank you for the patch.
> > See comments here:
> >
> > https://trac.nginx.org/nginx/ticket/1445
> >
>
> In the first comment on that ticket, you write
>
> > At most, we can consider a generic interface to set various OpenSSL options.
>
> Would there be a realistic chance of you accepting a patch that simply
> exposes OpenSSL's SSL_CONF_cmd() through the nginx config file(s)?
>
> It would of course do the obvious basic checks using
> SSL_CONF_cmd_value_type() like
> "Does the requested option exist in OpenSSL?",
> "If a file/directory was specified, does it exist and is it readable?",
> "If a relative file/directory was specified, prepend the nginx
> configuration directory path to the string.",
> and would of course check the return value of SSL_CONF_cmd() itself, but
> it would *not* try to do anything further like "Prevent the user from
> overriding settings made through other nginx configuration directives".
>
> Since I'm not too experienced in writing C code, it would be quite a bit
> of work for me, so I'd like to know beforehand if it would be worth the
> effort at all, or if you'd reject the patch anyhow.

As of now, such an option is considered. But whether a
patch will be accepted or not heavily depends on the patch quality
and overral simplicity of the interface involved.

Note well that what your original patch does - that is, preferring
ChaCha without any user-configurable options - can be easily
achieved by using appropriate system-wide OpenSSL config. If
unsure, you may consider this approach instead.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel