On 05/02/2017 02:10 PM, Eric Covener wrote:
I think to be useful, reasonable SSL defaults have to be subject to
change in maintenance (and over-rideable)


So... this got me thinking. If we put this new "stuff" (whatever it turns out to be) into a new directive,

- part of its operation gets tied to source code that's hidden from the end user
- we'll probably have to duplicate some SSL directive logic in the module
- we have to figure out the merge/conflict scenarios, which -- while definitely worthwhile in the long term -- feels likely to add complexity to the short-term discussion

If all of the settings that are part of this new directive can be described in terms of other already-existing directives, could we implement it as a server-owned Macro?

- their implementation is public and auditable by anyone who understands the config syntax - they can be easily patched for vulnerabilities without recompiling anything - merge/conflict resolution will follow the individual directives' current merge logic (whatever that happens to be)

We could reserve a macro prefix (or symbol) for the server and its modules so that we don't step on anyone with future expansion. Then it's just a matter of

    Include macros/ssl.conf

    Use !SslIntermediateSecuritySettings

We'd have to be very explicit that the macro definitions belong to the server distribution, and installing a newer (or older) version of the server would overwrite whatever changes you'd made to those macro files.

Thoughts?

--Jacob

Reply via email to