I actually was going to respond in a similar way by proposing the use of files
that could be Included. I really like this idea for all the reasons mentioned -
the biggest being that it's trivial for a SecAdmin or WebAdmin to see what is
in the Included file and its macros and what gets applied. I am also in support
of regularly evolving the values because an admin making use of them is aware
that they are delegating responsibility to us or their package vendor. The
downside (which may no longer be valid - haven't looked in ages) is that I
think Includes and Macros confuse line numbers in error messages.
--
Daniel Ruggeri
-------- Original Message --------
From: Jacob Champion <champio...@gmail.com>
Sent: May 2, 2017 5:48:34 PM CDT
To: dev@httpd.apache.org
Subject: Re: SSL and Usability and Safety
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
