[HINWEIS] - SVN-Repository ist zu svn.fhem.de umgezogen

Begonnen von Markus Bloch, 11 Dezember 2016, 15:15:15

Vorheriges Thema - Nächstes Thema

Markus Bloch

Hallo zusammen,

am Samstag den 17.12.2016 wurde das SVN-Repository von FHEM auf eine neue Plattform umgezogen, welche durch FHEM e.V. bereitgestellt wird. Das neue Repository ist nun unter https://svn.fhem.de/ erreichbar. Mit diesem Schritt ist auch das SVN nun unter den Schirm von fhem.de gewandert.

Um auch auf der neuen Plattform Änderungen an den eigenen Modulen durchführen zu können, bitten wir daher alle aktiven Developer uns einen SSH Public-Key per Mail an svn@fhem.de zu schicken. Wir werden dann den Zugang entsprechend auf der neuen Plattform einrichten. Um die Differenzen zwischen SourceForge Username und Forum-Username zu beseitigen wird ausschließlich der Forum-Username (einsehbar im Forum unter Menü Profil->Benutzerkonto) für die neue SVN-Plattform verwendet.

Detaillierte Informationen wie man auf das neue Repository zugreifen kann, gibt es unter https://svn.fhem.de/.

Für evtl. Fragen stehe ich hier gerne zur Verfügung.

Viele Grüße

Markus

Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Loredo

Hallo Markus,


wurde eine Umstellung auf Git damit vollkommen verworfen?
Bitte etwas mehr Infos über den Fahrplan.






Danke & Gruß
Julian
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Volker Kettenbach

Ja, sehr schade, dass es nicht git ist.
So etwas wie github.com ist was wirklich feines.

Markus Bloch

Hallo zusammen,

es gab in der Vergangenheit entsprechende Überlegungen generell auf git umzusteigen. Dabei standen die Vorteile von git (Pull Request, Branch/Merge) den Aufwänden für fhemupdate sowie das Anleiten aller Developer gegenüber. Da es Unentschieden ausging, bleiben wir weiterhin auf SVN.

Betateilchen hatte damals ein GIT-Repository aufgebaut. Die Resonanz war jedoch nicht sehr hoch.

Daher haben wir uns entschieden die neue Platform ebenfalls auf SVN zu belassen.

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Loredo

Wirklich schade.


Trotz alledem: Der neue Server hat natürlich Dampf, also vielen Dank für die Mühe beim Umzug generell :-)




PS - wenn Zeit ist:
https://securityheaders.io/?q=wiki.fhem.de&followRedirects=on
https://www.ssllabs.com/ssltest/analyze.html?d=wiki.fhem.de&s=88.99.31.202&latest (OCSP Stapling)


Sofern gewünscht gebe ich gerne Hilfestellung.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

rudolfkoenig


rudolfkoenig

Ich habe jetzt etliche Hinweise von securityheaders.io befolgt, nur HPKP mit Letsenrypt ist mir suspekt, und deswegen noch nicht implementiert. Den Rueckgabewert von ssllabs wg. OCSP Stabling habe ich nicht verstanden: Dauert ewig, liefert aber A+. OCSP stapling sollte doch zu verringerte Kommunikation fuehren, und damit eher schneller sein.

Die Absicherung von fhem.de ist wg. dem FHEM update (vertraegt sich nicht mit redirect auf HTTPS, obwohl mit HTTPS selbst keine Probleme hat) und die statistics Seite (ich kriege keine funktionierende Content-Security-Policy Header-Zeile hin) nicht vollstaendig.

Loredo

Zitat von: rudolfkoenig am 13 Dezember 2016, 11:17:35
nur HPKP mit Letsenrypt ist mir suspekt, und deswegen noch nicht implementiert.


Ja kann ich verstehen, muss man erstmal verstehen (und sollte man auch). Man kann sich da schon ins Knie schießen :-)
Mit Letsencrypt macht es deshalb nur Sinn die CA zu pinnen und nicht das eigene Zertifikat. Zusammen mit zwei Backup-Zertifikaten (letztendlich nichts weiter als zwei auf Halde generierte Private Keys, um sich den dazugehörigen Public-Key im Ernstfall schnell noch signieren zu lassen) ist man da auf einer recht sicheren Seite was den Betrieb angeht. Auch wenn man so "nur" das CA Zertifikat pinnt so ist es doch trotzdem besser als gar nichts zu pinnen.
Außerdem kann man natürlich erstmal nur den Testmodus setzen und erhält zusammen mit dem report-uri-Flag (siehe auch https://www.report-uri.io fürs Sammeln der Reports) auch ein hübsches Reporting für "was wäre wenn", bevor man das ganze produktiv/restriktiv setzt.


Zitat von: rudolfkoenig am 13 Dezember 2016, 11:17:35
Die Absicherung von fhem.de ist wg. dem FHEM update (vertraegt sich nicht mit redirect auf HTTPS, obwohl mit HTTPS selbst keine Probleme hat) und die statistics Seite (ich kriege keine funktionierende Content-Security-Policy Header-Zeile hin) nicht vollstaendig.


Das gleiche Reporting Verfahren kann man übrigens auch für CSP machen. Wie das funktioniert erklärt die Seite report-uri.io prima und stellt auch entsprechende Header-Generatoren bereit. Damit solltest du auch eine funktionierende CSP zusammenklicken und für den Testbetrieb aktivieren können.


Zitat von: rudolfkoenig am 13 Dezember 2016, 11:17:35
Den Rueckgabewert von ssllabs wg. OCSP Stabling habe ich nicht verstanden: Dauert ewig, liefert aber A+. OCSP stapling sollte doch zu verringerte Kommunikation fuehren, und damit eher schneller sein.


Aktuell ist OCSP nicht aktiviert, für ein einfaches Handling würde ich empfehlen über SSL-Offloading nachzudenken statt es den Apachen machen zu lassen. HAproxy macht OCSP Stapling eigentlich sehr einfach aktivierbar und kümmert sich dann selbstständig darum regelmäßig eine signierte Antwort vom OCSP Server von Letsencrypt einzuholen.


Die Aktivierung von OCSP führt auch nicht dazu, dass der SSLlabs Test schneller geht. Der baut ja nicht nur eine SSL Session auf, sondern prüft auch noch jede Menge an Angriffsvektoren aktiv aus. OCSP bringt dem Browser des Besuchers etwas, da er keine eigene Verbindung zum OCSP Server von Letsencrypt aufbauen muss (hier liegt der Zeitgewinn, den du vermutlich ansprichst). Gleichzeitig wird der OCSP Dienst bei Letsencrypt natürlich weniger belastet und der Besucher behält seine Privacy, da man sein Surfverhalten nicht zentral anhand der OCSP Abfragen nachverfolgen kann.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Loredo

Hier mal die .htaccess Konfiguration, wie ich sie bei mir verwende:




# STS
Header always set Strict-Transport-Security "max-age=15552000; preload"


# CSP: Production phase
Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://*.googleapis.com https://*.gstatic.com https://*.wp.com; style-src 'self' 'unsafe-inline' https://*.googleapis.com https://*.gstatic.com; img-src *; media-src *; font-src 'self' data: https://*.googleapis.com https://*.gstatic.com; connect-src 'self' data:; report-uri https://XXXYYYZZZ.report-uri.io/r/default/csp/enforce"
Header always set X-Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://*.googleapis.com https://*.gstatic.com https://*.wp.com; style-src 'self' 'unsafe-inline' https://*.googleapis.com https://*.gstatic.com; img-src *; media-src *; font-src 'self' data: https://*.googleapis.com https://*.gstatic.com; connect-src 'self' data:; report-uri https://XXXYYYZZZ.report-uri.io/r/default/csp/enforce"
Header always set X-WebKit-CSP "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://*.googleapis.com https://*.gstatic.com https://*.wp.com; style-src 'self' 'unsafe-inline' https://*.googleapis.com https://*.gstatic.com; img-src *; media-src *; font-src 'self' data: https://*.googleapis.com https://*.gstatic.com; connect-src 'self' data:; report-uri https://XXXYYYZZZ.report-uri.io/r/default/csp/enforce"


# HPKP: Evaluation phase for LetsEncrypt CA pinning (1xLE-CA + 2xBackup-Key)
#Header always set Public-Key-Pins-Report-Only 'pin-sha256="Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys="; pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg="; pin-sha256="Ggrghh/nWGX5PHVSRU4FeplPG5infxvSO6MdsFfwSvE="; pin-sha256="l1vvZm6RNJ9lqI9PKtQGTw+cXNeB6PN8osfE2GA18XQ="; max-age=2592000; report-uri="https://XXXYYYZZZ.report-uri.io/r/default/hpkp/reportOnly"'


# HPKP: Production phase for LetsEncrypt CA pinning (1xLE-CA + 2xBackup-Key)
Header always set Public-Key-Pins 'pin-sha256="Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys="; pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg="; pin-sha256="Ggrghh/nWGX5PHVSRU4FeplPG5infxvSO6MdsFfwSvE="; pin-sha256="l1vvZm6RNJ9lqI9PKtQGTw+cXNeB6PN8osfE2GA18XQ="; max-age=2592000; report-uri="https://XXXYYYZZZ.report-uri.io/r/default/hpkp/enforce"'


# CORS
Header always set Access-Control-Allow-Origin "https://www.XXXYYYZZZ.com"


# Apache Webserver
ServerSignature Off



Wie man sieht habe ich zunächst HPKP evaluiert (Public-Key-Pins-Report-Only) und nachdem über einen Zeitraum keine Meldungen im Reporting über Inkompatibilitäten aufgetaucht sind schließlich live geschaltet.




Gruß
Julian
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Loredo

Zitat von: rudolfkoenig am 13 Dezember 2016, 11:17:35
Die Absicherung von fhem.de ist wg. dem FHEM update (vertraegt sich nicht mit redirect auf HTTPS, obwohl mit HTTPS selbst keine Probleme hat)


Da die HTTP-Header alle rein clientseitig interpretiert werden, bleibt für das fhem-Update (so man es nicht daraufhin erweitern wollen würde) nur den HTTP-Redirect im Webserver auf HTTPS so umzubauen, dass er für die Update-URI nicht angewendet wird. Da fhem-Update den Strict-Transport-Security Header bisher nicht interpretiert, wird dort auch keine HTTPS Verbindung forciert. Wenngleich es wünschenswert wäre diesen Header zukünftig zu beachten, aber für das Update könnte man auch erstmal eine Ausnahme machen, wenn HTTPS da noch Probleme macht.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

rudolfkoenig


Loredo

Auf www.report-uri.io, alternativ auch auf deinem eigenen Server, wenn du das vom Browser gesendete JSON selbst verarbeiten möchtest (das Header Attribut "report-uri:" kann man ja beliebig setzen). Da das aber recht viel Aufwand ist das richtig zu tun und ein Browser eine solche Information auch nur im Fehlerfall sendet, sehe ich das nicht kritisch an es an einen externen Dienst wie diesen zu senden. Die übertragenen Informationen beinhalten auch nichts schützenswertes, sondern eh nur das, was der Browser als Fehlermeldung wirft.


Gruß

Julian
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

rudolfkoenig

An die KOPP_FC und PRESENCE Maintainer: bitte die Links zu http://svn.code.sf.net im Modul anpassen.

betateilchen

Wer auf macOS Sierra trotz korrektem ~/.ssh/config Eintrag Probleme hat, per svn+ssh:// das Repository zu erreichen, sollte kontrollieren, dass die Rechte auf das keyfile korrekt auf 400 stehen. Bei der Generierung des keyfiles mit ssh-keygen werden die Rechte auf 600 gesetzt, was macOS in aktuellen Versionen wohl nicht mehr zulässt.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Loredo

Ich habe hier diese Probleme zwar nicht feststellen können, mag aber auch daran liegen, dass ich das Keyfile mit Passwort geschützt habe und ssh-agent für die Bereitstellung des Keys verwende. Vielleicht also noch eine Alternative dazu.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER