Achtung: RedMatic inkompatibel mit RaspberryMatic 3.45.7.20190504

[hobbyquaker]

Siehe dazu:
[*] https://github.com/rdmtc/RedMatic/issues/202
[*] viewtopic.php?f=65&t=50589

Ich versuche baldmöglichst ein RedMatic Update bereitzustellen das dieses Problem löst und die Kompatibilität mit RaspberryMatic 3.45.7.20190504 wiederherstellt. Stand Jetzt muss ich leider RedMatic-Nutzern (noch) davon abraten RaspberryMatic 3.45.7.20190504 zu nutzen.

EDIT: ein möglicher Workaround für RaspberryMatic 3.45.7.20190504 ist hier beschrieben: https://github.com/rdmtc/RedMatic/issue ... -489457842

[nicolas-eric]

Hab das auch schon gemerkt.
HomeKit ging noch.
Aber einiges andere nicht mehr.
Alte SD rein und läuft alles wieder.


Wäre schön, wenn solche Änderungen, die das verursachten, untereinander abgesprochen werden, damit sowas nicht passiert.
Welchen Zweck diese Änderung hat, die dazu führt, dass RedMatic nicht mehr richtig funktioniert, würde ich gerne mal wissen.

[hobbyquaker]

Wäre schön, wenn solche Änderungen, die das verursachten, untereinander abgesprochen werden, damit sowas nicht passiert.

Bin ich bei Dir

Welchen Zweck diese Änderung hat, die dazu führt, dass RedMatic nicht mehr richtig funktioniert, würde ich gerne mal wissen.

Es wurde in RaspberryMatic 3.45.7.20190504 ein neuer HTTP Response Header im lighttpd (Webserver) konfiguriert der dem Browser mitteilt von welchen Quellen Inhalte geladen werden dürfen, also eine "Sicherheitsmaßnahme".

[nicolas-eric]

Oh Mann, dieses momentane „immer sicherer“ Konzept nervt ein wenig.
Nahezu jedesmal hat min. ein AddOn oder eine mit der HM zusammenarbeitende andere Software Probleme dadurch.
Früher ohne das alles war die Ursache für Sicherheitsprobleme auch fast nie die CCU2, sondern der DAU mitsamt Portweiterleitung.

[hobbyquaker]

Aus so einer Diskussion werd ich mich raushalten. Ich gebe dabei nur zu bedenken: Es steckt sicherlich keine Boshaftigkeit hinter sowas, ich bin unzweifelhaft überzeugt dass das aus bester Absicht heraus gemacht wird - daher mache ich Jens da sicher auch keinen Vorwurf. Mich interessiert jetzt nur wie ich schnellstmöglich RedMatic wieder kompatibel machen kann

Wo ich Dir allerdings recht gebe: es wäre wünschenswert wenn Addon Entwickler seitens Jens und eQ-3 vorab über "Breaking Changes" informiert werden würden, noch besser wäre es wenn es für Addon-Entwickler ein Beta-Programm gäbe und man neue Releases mit etwas Vorlauf zum Testen bekommen könnte. Sehe mich leider nicht in der Lage neben meinen eigenen Projekten auch noch die Commit-History von RaspberryMatic stets im Auge zu behalten...

[nicolas-eric]

Boshaftigkeit werfe ich auch nicht vor, ganz im Gegenteil.
Ich kann auch fachlich nicht beurteilen, ob das notwendig war oder nicht.
Habe beruflich aber auch schon erlebt, dass hochbezahlte SW Entwickler manchmal etwas gut gemeint verschlimmbessert haben, wenn sie erstmal „im Tunnel“ sind. Da geht es um sicherheitsrelevante Systeme, aber selbst dabei kann man so übertreiben, bis es vor lauter Sicherheit für den nicht IT-affinen Anwender bei den Behörden kaum mehr möglich ist, das zu nutzen.

[jmaus]

Wäre schön, wenn solche Änderungen, die das verursachten, untereinander abgesprochen werden, damit sowas nicht passiert.

Bin ich bei Dir

Ich bin da auch voll bei euch

Welchen Zweck diese Änderung hat, die dazu führt, dass RedMatic nicht mehr richtig funktioniert, würde ich gerne mal wissen.

Es wurde in RaspberryMatic 3.45.7.20190504 ein neuer HTTP Response Header im lighttpd (Webserver) konfiguriert der dem Browser mitteilt von welchen Quellen Inhalte geladen werden dürfen, also eine "Sicherheitsmaßnahme".

Das ergibt natürlich vollkommen Sinn wenn RedMatic via Cross-Site Zugriffe versucht dinge darzustellen weil das wie du richtig beschrieben hast seit der neuen version aus Sicherheitsgründen unterbunden wird. Der "Breaking Change" sind hierbei wohl das hinzufügen der folgenden zwei Zeilen in die lighttpd Konfiguration:

https://github.com/jens-maus/RaspberryM ... conf#L6-L7

bzw. die Übernahme dieser Änderung von einem Sicherheitsexperten mittels PullRequest:

https://github.com/jens-maus/RaspberryMatic/pull/597

Wo ich Dir allerdings recht gebe: es wäre wünschenswert wenn Addon Entwickler seitens Jens und eQ-3 vorab über "Breaking Changes" informiert werden würden, noch besser wäre es wenn es für Addon-Entwickler ein Beta-Programm gäbe und man neue Releases mit etwas Vorlauf zum Testen bekommen könnte. Sehe mich leider nicht in der Lage neben meinen eigenen Projekten auch noch die Commit-History von RaspberryMatic stets im Auge zu behalten...

Also das mit informieren über "breaking changes" setzt aber voraus das ich überhaupt Kenntnis davon habe das es sich hierbei um einen "Breaking Change" handelt. Und das ist eben mitunter etwas schwieriger in Erfahrung zu bringen. Wo ich aber komplett mitgehe ist, das ich Beta-Versionen zu verfügung stellen könnte. In der Tat habe ich das auch schon dick auf meiner Agenda und werde wohl bald zumindest "nightly builds" von RaspberryMatic zur Verfügung stellen die dann den Entwicklungsstand des jeweiligen Tages entsprechen und die dann jeder zu (Vorab-)Tests nutzen kann.

Mich interessiert jetzt nur wie ich schnellstmöglich RedMatic wieder kompatibel machen kann

Dazu müsstest du erst einmal rausfinden welche Teile deines RedMatic direkte Zugriffe zu externen Webservern von der WebUI tätigen und diese entweder abschalten bzw. umgehen und lokal Daten laden lassen oder du findest einen Weg dem lighttpd für deine URLs beizubringen für diese Zugriffe einen anderen "Content-Security-Policy:" response header zu senden.

Ich kann auch fachlich nicht beurteilen, ob das notwendig war oder nicht.
Habe beruflich aber auch schon erlebt, dass hochbezahlte SW Entwickler manchmal etwas gut gemeint verschlimmbessert haben, wenn sie erstmal „im Tunnel“ sind. Da geht es um sicherheitsrelevante Systeme, aber selbst dabei kann man so übertreiben, bis es vor lauter Sicherheit für den nicht IT-affinen Anwender bei den Behörden kaum mehr möglich ist, das zu nutzen.

Also "notwendig" ist in dem Zuge natürlich völlig relativ und liegt im Blickwinkel des Betrachters. Selbst ist mir im Kontext von RaspberryMatic in dem Zuge die Sicherheit auch eher zweitrangig. "Bedanken" für das Einführen dieser und anderer vergangenen und wohl noch kommenden Sicherheitsanpassungen in der CCU/WebUI kannst du dich dabei vor allem bei privaten Sicherheitsexperten sowie dem BSI. Diese haben in der Vergangenheit mehrfach durch Öffnen von offiziellen CVEs (siehe https://www.cvedetails.com/vulnerabilit ... /Eq-3.html) dafür gesorgt, dass das Thema Sicherheit im Bezug auf die CCU und WebUI mehr und mehr in den Vordergrund gerückt wurde (siehe https://www.eq-3.de/aktuelles/newsreade ... r-ccu.html), sodass man zwangsläufig das Thema Sicherheit über das Thema Kompatibilität stellen musste...

[hobbyquaker]

Dazu müsstest du erst einmal rausfinden welche Teile deines RedMatic direkte Zugriffe zu externen Webservern von der WebUI tätigen

Das weiss ich bereits

und diese entweder abschalten bzw. umgehen und lokal Daten laden lassen

Das ist nicht praktikabel machbar. Es handelt sich u.A. um OAuth Flows, z.B. gegen den Home-Connect Cloudservice (für die Integration von Bosch/Siemens Haushaltsgeräten) oder Abfragen des Node-RED Palette Manager gegen nicht vorhersehbare URLs. Node-RED benötigt da zwingend eine etwas laxere Content-Security-Policy.
Neben diesen Dingen gibt es natürlich noch viel mehr - was nicht zwingend sein muss - aber für den User eben convenient ist, so z.B. die Einbindung eines Webcam Bildes in ein Dashboard u.Ä.

oder du findest einen Weg dem lighttpd für deine URLs beizubringen für diese Zugriffe einen anderen "Content-Security-Policy:" response header zu senden.

Habe ich schon den halben Tag versucht, leider erfolglos bisher (siehe auch viewtopic.php?f=65&t=50589)

Edit: Habs hinbekommen, das wird der Weg sein

[nicolas-eric]

Ich kann auch fachlich nicht beurteilen, ob das notwendig war oder nicht.
Habe beruflich aber auch schon erlebt, dass hochbezahlte SW Entwickler manchmal etwas gut gemeint verschlimmbessert haben, wenn sie erstmal „im Tunnel“ sind. Da geht es um sicherheitsrelevante Systeme, aber selbst dabei kann man so übertreiben, bis es vor lauter Sicherheit für den nicht IT-affinen Anwender bei den Behörden kaum mehr möglich ist, das zu nutzen.

Also "notwendig" ist in dem Zuge natürlich völlig relativ und liegt im Blickwinkel des Betrachters. Selbst ist mir im Kontext von RaspberryMatic in dem Zuge die Sicherheit auch eher zweitrangig. "Bedanken" für das Einführen dieser und anderer vergangenen und wohl noch kommenden Sicherheitsanpassungen in der CCU/WebUI kannst du dich dabei vor allem bei privaten Sicherheitsexperten sowie dem BSI. Diese haben in der Vergangenheit mehrfach durch Öffnen von offiziellen CVEs (siehe https://www.cvedetails.com/vulnerabilit ... /Eq-3.html) dafür gesorgt, dass das Thema Sicherheit im Bezug auf die CCU und WebUI mehr und mehr in den Vordergrund gerückt wurde (siehe https://www.eq-3.de/aktuelles/newsreade ... r-ccu.html), sodass man zwangsläufig das Thema Sicherheit über das Thema Kompatibilität stellen musste...

Das kenne ich, beruflich habe ich mit Hard- und Software zu tun, die auch erst monatelang vom BSI getestet (inkl. Zonenvermessung etc.) und freigegeben werden muss, bevor sie genutzt werden darf. Aber da geht es um Verarbeitung und Speicherung von VS-NfD bis Str.Geh. Daten.
Hätte nicht gedacht, dass das BSI auch beim Thema SmartHome so involviert ist. Werde mal rein interessehalber nachfragen, vielleicht kann mir wer was genaueres dazu sagen.

Selbstverständlich will auch EQ3 auf dem neuesten Stand sein, selbst eine rein theoretische und praktisch nie genutzte Sicherheitslücke ist ja schon imageschädigend und spiegelt sich in den Verkaufszahlen wider.

Trotzdem würde ich mir wünschen, dass das nicht zu allzustarken Einschränkungen bei der Nutzbarkeit oder Überraschungen - wie in diesem Fall - führen würde.

[hobbyquaker]

So ist es natürlich noch viel besser: https://github.com/jens-maus/RaspberryMatic/pull/619

ein Möglicher Workaround für RaspberryMatic 3.45.7.20190504 ist hier beschrieben: https://github.com/rdmtc/RedMatic/issue ... -489457842