[Ach] Removed prosody
Aaron Zauner
azet at azet.org
Thu Feb 19 20:40:47 CET 2015
Alexander Wuerstlein wrote:
> On 2015-02-19T20:09, Aaron Zauner <azet at azet.org> wrote:
>>
>> Matthew Wild wrote:
>>> 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.
>> I cannot agree more, it is vital that all this is fixed upstream. Our
>> project intended to be an intermediate solution. A lot has been fixed in
>> OpenSSL, TLS specs and various server daemons (e.g. Apache, MTAs,
>> OpenSSH,..) since.
>
> The big problem with fixes from upstream is that usually crypto
> improvements are not classified as security fixes and therefore not
> backported to the older releases that are in widespread use. Or even
> worse, many software projects don't even support the older branches that
> distributions ship.
>
> For non-configuration changes, distributions usually take care of the
> necessary backporting, but for configuration this is usually not
> feasible. Admins therefore have to fix the resulting insecure
> configurations by themselves which leads to the aforementioned mess.
>
> This could be fixed by backports of default crypto config or at least
> publishing configuration advice for old releases. Which is of course a
> task for upstream, distros or projects.
>
Yep. But it's important to recognize upstream changes in security/crypto
policies as well. For example; I've written the original OpenSSH part of
the document, they since ship excellent default settings for newer
OpenSSH releases - there's really no need to wire an update for current
versions of OpenSSH. As with other daemons in our document; these should
stay in there. Some distros fix this by backporting (Debian for exmaple,
Fedora has their central crypto policy stuff going on) - some do not,
it's good to have our document as a reference.
To be honest: ideally we wouldn't need this document a year from now and
everything is fixed upstream in distros and specs. -- but let's be
realistic; that's not going to happen. Thus it's vital that our document
sees active contributions and people researching which changes have been
made for which service, protocol and distribution over time.
Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20150219/8a3af692/attachment.sig>
More information about the Ach
mailing list