These tasks sometimes fail under non-Docker installations when the administrator tries to run them without explicitly requesting the production environment.
* Avoid hard-coding ciphers into configuration
This change allows OpenSSL to choose the most appropriate available cipher(s) from the HIGH cipher suite. This is sufficient to get an A on the SSLLabs.com tests suite. If MEDIUM is allowed as well, the grade drops to a B which is still more than adequate for most deployments.
This type of configuration would prevent problems such as the current inability of Tusky on Android 7 devices to connect to some Mastodon instances.
The main benefit though, is this delegates the decisions about which ciphers are "good" and which ciphers are "bad" to the experts; the distribution security teams and the OpenSSL developers. If a weakness is found in a particular cipher it will get moved from HIGH to one of the lower classes (or removed entirely) and this will get deployed just like any other security update. Similarly, if new stronger ciphers are standardized (such as Curve 25519) - these will immediately become available without needing to change the configuration.
Hope this helps!
Note: I have not been able to test this change with Mastodon myself. I am using these settings in production elsewhere though, and they work quite well. Alternately, if people don't want to trust the OpenSSL definitions, please consider taking a look at https://wiki.mozilla.org/Security/Server_Side_TLS and implementing the recommendations from there.
* Also avoid SHA1
As requested during review. :)
* Fix a typo in the ssl_ciphers line
I wrote !SHA1, should have written just !SHA. Very sorry about the noise.
* Avoid hard-coding ciphers into configuration
This change allows OpenSSL to choose the most appropriate available cipher(s) from the HIGH cipher suite. This is sufficient to get an A on the SSLLabs.com tests suite. If MEDIUM is allowed as well, the grade drops to a B which is still more than adequate for most deployments.
This type of configuration would prevent problems such as the current inability of Tusky on Android 7 devices to connect to some Mastodon instances.
The main benefit though, is this delegates the decisions about which ciphers are "good" and which ciphers are "bad" to the experts; the distribution security teams and the OpenSSL developers. If a weakness is found in a particular cipher it will get moved from HIGH to one of the lower classes (or removed entirely) and this will get deployed just like any other security update. Similarly, if new stronger ciphers are standardized (such as Curve 25519) - these will immediately become available without needing to change the configuration.
Hope this helps!
Note: I have not been able to test this change with Mastodon myself. I am using these settings in production elsewhere though, and they work quite well. Alternately, if people don't want to trust the OpenSSL definitions, please consider taking a look at https://wiki.mozilla.org/Security/Server_Side_TLS and implementing the recommendations from there.
* Also avoid SHA1
As requested during review. :)
* Translating: add devise/doorkeeper i18n sources
The two links mentioned here are mostly official places for parking these libraries' translations. Pointing translators there should save them some time.
* fixup rephrase (squash this)
Changed privacy table, “can I import my followers” question (it’s
“people I follow”), and removed the “still see posts from blocked
people” question, because it’s been fixed.
Integrated questions from @raccoon (https://mastodon.social/@Raccoon).
Made a cursory editing lookover. Added some incomplete credits/contacts
at the bottom.
Add FAQ screenshots to screenshots/ directory. Also, consistently size
each screenshot to 200px height in FAQ.md if still readable. Small text
changes.
Noëlle Anthony