Neueste Beiträge

#1

Multimedia / Aw: MagentaTV

Letzter Beitrag von Monti - 24 November 2025, 18:37:11

Wow, danke für die Änderung das gibt klar einige Daumen hoch!
Nun müsste das nur noch in das Modul damit es bei einem Update nicht wieder "verschwindet".

#2

DOIF / Aw: DOIF_Readings|event_Readin...

Letzter Beitrag von holle75 - 24 November 2025, 18:19:19

Danke Damian, ja, könnte man testen, aber so ist es auch für Nachfolgende festgehalten. Ich suche mir immer die Finger wund im Forum und habe auch zu dieser keine Antwort gefunden. Bzw. für den Teil der Frage den du beantwortet hast schon.

Was ich noch immer nicht verstehe (das war die Kernfrage): ist ein attr do resetwait für einen Strang ohne wait das Selbe wie ein attr do always?

Die commandref schweigt sich dazu aus (bzw ist es wahrscheinlich so und bedarf keiner Erklärung?)

#3

Sprachsteuerung / Aw: [37_echodevice] Amazon Ech...

Letzter Beitrag von passibe - 24 November 2025, 17:57:27

Liege ich falsch, dass das cookie abläuft und deshalb automatisch regelmäßig erneuert wird ?

Die Aktualisierung des Cookies hat damit überhaupt nichts zu tun.

Es ist doch keine "Sicherheitlücke" in alexa-cookie2, sondern in npm !

Nein. npm hat keine Sicherheitslücke in dem Sinne, sondern es werden einfach die Konten der Entwickler "beliebter" Pakete durch Social Engineering, Phishing usw. gekapert und dann wird Schadcode in deren Projekte eingefügt. Man kann sich das ungefähr so vorstellen, als würde jemand deinen Account hier im Forum kapern und dann darüber Links zu irgendwelche Betrugswebsites verbreiten.


Ansonsten: Es handelt sich hier um einen Supply-Chain-Angriff. Da gibt es jetzt im Hinblick auf alexa-cookie2 zwei Möglichkeiten:

1. Der Entwickler von alexa-cookie2 selbst wird Ziel des Angriffs. Angreifer erhalten Zugriff auf sein npm-Konto und veröffentlichen eine neue alexa-cookie2-Version, die Schadcode enthält.
Dass das passiert ist aber eher unwahrscheinlich, weil alexa-cookie2 jetzt keine große Bibliothek ist, die anderswo haufenweise als dependency verwendet wird.
Zudem ist unwahrscheinlich, dass, selbst wenn das passieren würde, das den FHEM-Nutzer betrifft, weil der FHEM-Nutzer ja erstmal diese neue (schädliche) Version von alexa-cookie2 überhaupt installieren müsste. Und ich bin der Meinung, dass viele Nutzer alexa-cookie2 einmal beim Einrichten von echodevice installieren und danach eben nicht mehr aktualisieren, außer etwas funktioniert nicht oder man installiert das gesamte System neu. Typischerweise wird aber einigermaßen schnell bemerkt, dass das Konto gekapert wurde, sodass dann die schädliche Version wieder zurückgerufen wird und das Zeitfenster, in dem die überhaupt verfügbar ist, recht klein ist. Dementsprechend ist es auch relativ unwahrscheinlich, dass ein FHEM-Nutzer genau in diesem Zeitraum alexa-cookie2 aktualisiert bzw. neu installiert.

2. Die zweite Möglichkeit ist, dass das Konto des Entwicklers einer der dependencies (Abhängigkeiten) von alexa-cookie2 (klick) gekapert wird. Wie man aber sieht, sind die Versionen der dependencies da einigermaßen fix und, soweit ich sehe, aktualisiert der Entwickler von alexa-cookie2 diese dependencies auch stets manuell (klick) und sowieso auch nicht so häufig. Dass diese seltene, manuelle Aktualisierung dann ausgerechnet in einen Zeitraum fällt, in dem eine der dependencies über ein gekapertes Entwicklerkonto eingefügten Schadcode enthält, ist also erneut relativ unwahrscheinlich. Zumal auch dann der FHEM-Nutzer immer noch alexa-cookie2 manuell aktualisieren (oder neu installieren) müsste.

Diese Supply-Chain-Angriffe zielen a) auf Pakete ab, die bei ganz vielen anderen Paketen als dependency benutzt werden und b) auf Umgebungen, in denen dependencies automatisch aktualisiert und dann auch automatisch das "Endpaket" aktualisiert wird. Beides ist hier nicht der Fall.

Ich hoffe, das klärt es ein bisschen auf.

FHEM betreffend sind sicherheitsmäßige Probleme eher anderswo zu finden. Nämlich z.B. darin, dass Leute Port 8083 ohne Weiteres ins Netz stellen oder generell ihr Betriebssystem überhaupt nicht aktualisieren. Diese Sache mit npm fällt angesichts dessen (und auch angesichts der sonst geringen Wahrscheinlichkeit, wie dargestellt) nach meiner Auffassung ganz ganz untergeordnet ins Gewicht.

#4

FRITZ!Box / Aw: 72_FRITZBOX.pm ab Version...

Letzter Beitrag von neobiker - 24 November 2025, 17:54:52

Hallo Jörg,

Hallo Neobiker,

wg Deiner Race-Condition könntest Du ja zusätzlich auf das Reading retStat_lastReadout triggern. Das wird ganz zum Schluss mit eine readingsSingleUpdate geschrieben.

Grüße Jörg

gute Idee, das bringt mich darauf, den Trigger umzuziehen in den Notify des Dummy, dann brauch ich kein UserReading in fbox mehr dafür:
notify: fbox retStat_lastReadout -> setreading DG_Thermo readValues fbox -> alle UserReadings aus fbox lesen

Probiere ich aus.

Gruss
Neobiker

#5

DOIF / Aw: Weihnachtsbeleuchtung scha...

Letzter Beitrag von Damian - 24 November 2025, 17:51:36

Funktioniert deine Definition denn?

Der einzige Trigger im ersten und zweiten Zweig ist [LiSens_Garage_0Uhr:state]. Wenn es am besagten Tag keinen Trigger gibt, wird der Befehl jeweils nicht ausgeführt.

Ich würde die tägliche Lichtsteuerung von den Sonderbehandlungen logisch trennen und als Anfänger in zwei DOIFs im FHEM-Modus aufteilen. Als Perlkenner kann man alles in einem DOIF-Perl-Device unterbringen. Dort lassen sich die unterschiedlichen Funktionen durch einen modularen Aufbau logisch voneinander trennen.

#6

FHEMWEB / Aw: Claude.ai Problem mit Anfa...

Letzter Beitrag von Prof. Dr. Peter Henning - 24 November 2025, 17:46:37

ein Sprachmodell mit gezielten Informationen zu füttern

Wer ein Sprachmodell wie Claude.ai nutzt, um Fehleranalysen zu erstellen, hat die Technik und Logik solcher Sprachmodelle einfach nicht verstanden.

LG

pah

#7

DOIF / Aw: DOIF_Readings|event_Readin...

Letzter Beitrag von Damian - 24 November 2025, 17:31:00

Der Befehl wird (im FHEM-Modus) erst zum Ausführungszeitpunkt ausgewertet und ausgeführt. Dh. Es wird der aktuelle Wert zum Ausführungszeitpunkt genommen und nicht der zum Triggerzeitpunkt 10 Sekunden zuvor.


Bei resetwait wird beim wiederholten Trigger im Gegensatz zu do always die ablaufende wait-Zeit zurückgesetzt, solange der Befehl noch nicht ausgeführt wurde und der wait-Timer noch aktiv war. Dh. sollte innerhalb von 10 Sekunden immer wieder ein Trigger (für den gleichen Zweig) kommen, wird der Befehl nie ausgeführt, weil die wait-Zeit nicht ablaufen kann.

All das kannst du einfach mit einem Test-DOIF und einem Dummy selbst testen.

#8

FRITZ!Box / Aw: 72_FRITZBOX.pm ab Version...

Letzter Beitrag von JoWiemann - 24 November 2025, 17:22:01

Hallo Neobiker,

wg Deiner Race-Condition könntest Du ja zusätzlich auf das Reading retStat_lastReadout triggern. Das wird ganz zum Schluss mit eine readingsSingleUpdate geschrieben.

Grüße Jörg

#9

Sprachsteuerung / Aw: [37_echodevice] Amazon Ech...

Letzter Beitrag von JudgeDredd - 24 November 2025, 17:18:57

Es ist doch keine "Sicherheitlücke" in alexa-cookie2, sondern in npm !
(ich habe mir aber nicht angeguckt, worin die Sicherheitslücke überhaupt besteht: Lücke in veralteten Modulen oder Schadsoftware in aktuellen Modulen)

So wie ich das Verstanden habe, geht es hier um das Modul "alexa-cookie2". Durch Lücken in NPM kann der Quellcode von eben diesem Modul manipuliert werden.
Bei Aktualisierung oder Installation wird nun der manipulierte Quellcode anstatt des originalen geladen.

Mit der eigentlichen Aktualisierung des Cookies hat die Sicherheitlücke nichts zu tun.

Wenn ich hier eine Gefahr sehen würde, dann eher in den Abhängigkeiten die das Modul verwendet. Da ich den Umfang nicht kenne, wieviele da verwendet werden.

#10

FRITZ!Box / Aw: 72_FRITZBOX.pm ab Version...

Letzter Beitrag von neobiker - 24 November 2025, 17:15:57

Hallo Jörg,

das läuft jetzt prima soweit. Derzeit hilft mein sleep 5 aus der Race-Condition.
Habe grade mal die Module FBAHAHTTP und FBDECT disabled,
meine DG_Thermo und Wz_Thermo devices laufen jetzt super.

Die Definitionen des Dummy devices und des notifiers habe ich in oberen Post aktualisiert.

Gruss
Neobiker