Diskussion:RadicaleCalDAVServer

Beschwerdeführer droht mit Blacklisting der Anleitung

Die Installationsanleitung ist einwandfrei, aber suboptimal.

Wir wurden heute von einem Dritten (Ticket #2015081110000178) darüber in Kenntis gesetzt unter Androhung der Aufnahme in eine Blacklist von Anleitungen, die Nutzer unsichere Konfigurationen empfehlen.

Orientierung an den best practices

Grundsätzlich ist die Anleitung nicht falsch. Im vorderen Teil ist sie leider unnötig kompliziert. Die Empfehlung - den best practices für Python folgend - lautet eigentlich:

# Basiordner anlegen
$ mkdir radicale
# und absichern
$ chmod 700 radicale
# Virtuelle Python-Umgebung (im Userspace) erzeugen
$ virtualenv radicale/virtualenv
# und dort Radicale installieren 
$ radicale/virtualenv/bin/pip install Radicale
# Ordnerstrukturen erzeugen
$ mkdir radicale/application/etc radicale/application/log radicale/application/data

Man erhält so eine klare Trennung zwischen der Installation der Software nebst Abhängigkeiten und den Anwendungsdaten. Entsprechend verteilt man dann die Konfigurations-, Daten- und Log-Dateien auf die jeweiligen Unterordner.

Möchte man an Stelle des Filesystem-Backends ein Datenbank-Backend nutzen, so sind die passenden Python-Bibliotheken in das virtualenv zu installieren. Alternativ kann man die systemweit installierten Bibliotheken nutzer (site-package beim virtualenv aktivieren); dies enspricht jedoch nicht den best pratices.

Der WSGI-Starter sieht dann so aus (Pfad zum Python im virtualenv):

#!/......./virtualenv/bin/python

import radicale

radicale.log.start()
application = radicale.Application()

TLS oder Nicht-TLS - beides ist möglich

Wenn man nun noch konsequent auf die Ordner app-ssl und htdocs-ssl setzt, nutzt man die TLS-Terminierung des Apache, der von Hostsharing auf dem aktuellen Stand gehalten wird und auch unser Beschwerdeführer sollte zufrieden sein.

Im Übrigen gilt es als best practice, die TLS-Terminierung nicht der Anwendung, sondern einem reverse proxy zu überlassen. Konkret erhöht dies sogar die Sicherheit, weil Hostsharing die allfälligen Sicherheitsprobleme mit OpenSSL im Blick behält und passend reagiert statt dieses Problem auf den Endnutzer abzuwälzen.

Hostsharing befürwortet und unterstützt den Einsatz von TLS, erzwingt ihn aber nicht. Der besseren Lesbarkeit halber wiederholen wir auch nicht bei jeder Erwähnung einer Installationsoption eine Belehrung über die Risiken der Wahl.

Grundsätzliches

Der maßgebliche Autor dieser Anleitung ist Java-Experte und ihm ist sicherlich nicht vorzuwerfen, dass ihm "virtualenv" nicht geläufig ist. Die etwas umständlichere Installationsvariante birgt keine Sicherheitsrisiken. Zudem setzt der Autor implizit voraus, dass unseren Nutzern der Unterschied zwischen den ssl- und nicht-ssl-Konfigurationoptionen bekannt ist. Dies - genauer die Beschreibung der Ordner und der SSL/TLS-Terminierung - geht unter anderem aus der maßgeblichen Endandwender-Dokumentation hervor.

--Web (Diskussion) 21:26, 11. Aug. 2015 (CEST)