[Ach] Removed prosody

Matthew Wild mwild1 at gmail.com
Thu Feb 19 19:52:49 CET 2015


Hi,

Another Prosody developer here!

On 19 February 2015 at 18:13, Aaron Zauner <azet at azet.org> wrote:
>> On 18 Feb 2015, at 19:56, Aaron Zauner <azet at azet.org> wrote:
>>> I've reverted a recent contribution from GitHub after a prosody
>>> developer commented that it was erroneous:
>>> https://github.com/BetterCrypto/Applied-Crypto-Hardening/pull/80
>>>
>>> review

Thanks.

> These seem to be the default options in 0.9.6?
>
> https://prosody.im/doc/advanced_ssl_config#options

Yet another demonstration of the dilemma we face as upstream
developers (I have actually brought it up on this list before).

We strongly recommend that users do not override any of the defaults
without good cause, especially just to explicitly set them. This is
because they might change (i.e. improve) in future releases and you
will be stuck on the old settings. Server administration is hard
enough without manually tracking these kind of changes across all the
software you have installed. Prosody has sensible defaults, please use
them!

And the other problem is... even though they appear to be the
defaults, Pepi's configuration has a mistake in it. I see this happen
a lot (the mistakes are always different, so it's not something we can
always automatically catch). It is especially bad when someone
publishes these broken configs online in a blog post or "helpful"
tutorial. I'd swear the NSA are publishing some of these guides :)

Pepi is correct that we have been working on revising our config
layout in the next major release, so we can regain some control over
what the user is doing, rather than giving them almost direct access
to the OpenSSL API parameters (which is what we have today, and what
most software provides). That will allow us to more easily
sanity-check configurations, and at least warn loudly if the user does
something stupid (which can be for any reason from a simple typo to
incompetency or malicious advice).

People absolutely should be able to configure their server how they
want to, and I want to allow that. But there is a real cargo-cult
approach to system security gaining popularity, instead of securing
the software upstream. It worries me.

Regards,
Matthew



More information about the Ach mailing list