Re: [exim] some OpenSSL topics

On 2013-10-15 at 15:05 +0000, Viktor Dukhovni wrote:
> This cipher list is clearly the result of an incomplete understanding
> of the OpenSSL cipherlist syntax. And yet you're not a novice
> user. Hence my contention that the OpenSSL cipher syntax is for
> OpenSSL experts only, applications should not expose it directly
> to users.
>
> [ Postfix has cipher grades (null, export, low, medium, high), users
> choose one of these, and leave the underlying cipherlists alone! ]

For clarity, Exim's philosophy in such matters, as I interpret this, has
been to try to do the right thing by default, document to discourage
playing when an option is dangerous, but expose the full power of the
underlying API so that those who _do_ know enough can do so.

We provide a tool which professional postmasters can use as they see
fit and shy away from being a nanny. We'll _encourage_ people to play
safe, with sane defaults, but we rarely stop people who _choose_ to
shoot themselves in the foot.

Easy things easy, hard things possible.

_Sometimes_ we take away power, but always with reluctance and after
providing an escape hatch if feasible. I'm the person who has taken
away the flexibility twice, that come to mind.

(Eg, we used to strongly discourage setting the Exim run-time user as
root. I changed that to compile and run-time checks which will require
patching Exim to disable, on the basis that only those who can manage
such patching stand a chance of being qualified to argue that they
should be able to set root as the run-time user.)

So, what works for the project you're involved in is not the approach
used by Exim and is unlikely to become our approach.

Specifically as relates to OpenSSL: once 1.0.2 is out, I expect Exim to
gain support for the new SSL_CONF_cmd system, integrating more OpenSSL
configuration management directly into Exim's configuration file, giving
administrators _more_ flexibility and freedom here. Even though we
already have "openssl_options" (which I added), because doing things the
way the "upstream" wants them done leads to fewer problems in the longer
run and we're happy to let postmasters tune.

In fact, the history of openssl_options, and the various feature changes
before that option was added, and the changes in defaults of that value,
while providing the escape hatch for others, is instructive in how we
manage the defaults to be sane, in a conservative manner, but expose the
power that many professional postmasters running large installations
value.

-Phil