Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Malware: Zip-Bombe entpackt 46…

Softwarequalität im freien Fall

  1. Thema

Neues Thema Ansicht wechseln


  1. Softwarequalität im freien Fall

    Autor: /mecki78 11.07.19 - 17:04

    In einer ZIP Datei steht doch, wie groß dessen Inhalt nach dem Auspacken ist. Also...

    - entweder stimmt die Angabe, dann weiß aber ein Dekompressor schon im Vorfeld, dass da 4,5 PBytes rauskommen und dass das die Kapazität lokaler Datenspeicher deutlich übersteigt, ergo sollte er nicht mal anfangen was auszupacken sondern mit einen Fehler abbrechen.

    - die Angabe stimmt nicht, dann sollte aber ein Dekompressor spätestens wenn er merkt, dass er bereits so viel Bytes entpackt hat, wie angegeben war und der Datenstrom trotzdem nicht zu Ende ist, sofort mit einen Fehler abbrechen, weil dann ist die Datei offensichtlich korrupt.

    Das sind doch zwei sehr einfach abzufangende Fehlerfälle.
    Wird Software heute nur noch von Idioten geschrieben?
    Ich darf das fragen, denn ich wäre dann so einer dieser Idioten, nur wie gesagt, ich hätte das so wie oben erwähnt implementiert. Als es hieß "Jeder kann programmieren" war damit nicht gemeint, dass es auch jeder tun sollte.

    /Mecki

  2. Re: Softwarequalität im freien Fall

    Autor: nikeee13 11.07.19 - 17:26

    Und dann gibt's Leute, die sich freuen, wenn das Programm es doch schafft, eine korrupte Datei zu entpacken und der Tag damit gerettet ist.

  3. Re: Softwarequalität im freien Fall

    Autor: schap23 11.07.19 - 17:30

    Was soll denn das mit dem "freien Fall". Früher ging es nur um Features und Geschwindigkeit. Daß die Eingabedaten sich an die Spezifikationen halten würden und niemand bösartig manipulierte Daten liefern würde, wurde vorausgesetzt.

    Jetzt wird verlangt, daß alles zehnmal überprüft wird, ob da doch jemand was manipuliert hat. Wenn man das perfekt macht, wird die Software allerdings beliebig langsam, da sie nur noch prüft und keine Ergebnisse mehr liefert.

    Warum aber irgendein Rückgang bei der Softwarequalität vorliegen soll (oder sogar ein "freier Fall"), wenn Software heute Überprüfungen nicht macht, auf die vor 10, 20 Jahren niemand im Traume gekommen wäre, entzieht sich meinem Verständnis.

  4. Re: Softwarequalität im freien Fall

    Autor: violator 11.07.19 - 17:33

    Wieso manipuliert? Wenn ein Programm weiß, dass der Inhalt zu groß für den Datenträger ist, sollte man annehmen, dass er das gar nicht erst entpackt, sondern direkt meckert. Manche Programme sind aber dumm und entpacken halt, um dann nach ner Ewigkeit zu sagen, dass das ja gar nicht geht.

  5. Re: Softwarequalität im freien Fall

    Autor: Mohrhuhn 11.07.19 - 17:49

    Lieber ein Schrott Programm als gar kein Programm

  6. Re: Softwarequalität im freien Fall

    Autor: Quantium40 11.07.19 - 17:51

    violator schrieb:
    > Wieso manipuliert? Wenn ein Programm weiß, dass der Inhalt zu groß für den
    > Datenträger ist, sollte man annehmen, dass er das gar nicht erst entpackt,
    > sondern direkt meckert. Manche Programme sind aber dumm und entpacken halt,
    > um dann nach ner Ewigkeit zu sagen, dass das ja gar nicht geht.

    Wobei man nicht vergessen darf, dass die meisten Entpacker dann noch so nett sind, die unvollständig entpackten Daten gleich wieder zu entsorgen.
    Das machte schon immer viel Spass, wenn dann ein größeres Archiv irgendwo kurz vor Schluss einen Fehler hatte.

  7. Re: Softwarequalität im freien Fall

    Autor: sevenacids 11.07.19 - 18:09

    schap23 schrieb:
    --------------------------------------------------------------------------------
    > Was soll denn das mit dem "freien Fall". Früher ging es nur um Features und
    > Geschwindigkeit. Daß die Eingabedaten sich an die Spezifikationen halten
    > würden und niemand bösartig manipulierte Daten liefern würde, wurde
    > vorausgesetzt.
    >
    > Jetzt wird verlangt, daß alles zehnmal überprüft wird, ob da doch jemand
    > was manipuliert hat. Wenn man das perfekt macht, wird die Software
    > allerdings beliebig langsam, da sie nur noch prüft und keine Ergebnisse
    > mehr liefert.
    >
    > Warum aber irgendein Rückgang bei der Softwarequalität vorliegen soll (oder
    > sogar ein "freier Fall"), wenn Software heute Überprüfungen nicht macht,
    > auf die vor 10, 20 Jahren niemand im Traume gekommen wäre, entzieht sich
    > meinem Verständnis.

    Es geht ja hier nicht um komplexe Algorithmen. Für eine Integritätsprüfung reicht im ersten Moment wirklich der Wert, der die Größe der entpackten Daten angibt und diesen auszulesen und auf Plausibilität zu prüfen erfordert nun wirklich nicht viel Rechenzeit. Von daher ist es schon seltsam, dass sowas wie eine ZIP-Bombe existieren kann, weil ich der Meinung bin, dass man sowas auch ordentlich, um nicht zu sagen intelligent, implementieren kann. Zumal man heute in einer Datenstruktur nun wirklich nicht mehr auf jedes Byte achten und sich dann so Sachen wie Jahreszahlen in 8-bit erlauben muss.

  8. Re: Softwarequalität im freien Fall

    Autor: /mecki78 11.07.19 - 20:11

    nikeee13 schrieb:
    --------------------------------------------------------------------------------
    > Und dann gibt's Leute, die sich freuen, wenn das Programm es doch schafft,
    > eine korrupte Datei zu entpacken und der Tag damit gerettet ist.

    Dadurch das 4,5 PBytes dein System lahm legen ist dein Tag gerettet?

    Für alle anderen gibt es dann eine Repair Funktion, die nur so tut als würde sie die Daten entpacken, um heraus zu finden, wie viele Daten das denn wären und die dann die Größenangaben in der Datei repariert. Das wird bei 4,5 PByte zwar ewig dauern, aber CPU Laufzeit ist unendlich verfügbar, das ist keine Resource, die dir "ausgehen" kann, anders als RAM oder Festplattenspeicher.

    /Mecki

  9. Re: Softwarequalität im freien Fall

    Autor: /mecki78 11.07.19 - 20:20

    schap23 schrieb:
    --------------------------------------------------------------------------------
    > Daß die Eingabedaten sich an die Spezifikationen halten
    > würden und niemand bösartig manipulierte Daten liefern würde, wurde
    > vorausgesetzt.

    Wann war denn das? Muss vor meiner Zeit gewesen sein.

    > Jetzt wird verlangt, daß alles zehnmal überprüft wird,

    Warum? Einmal reicht doch.

    > Wenn man das perfekt macht, wird die Software
    > allerdings beliebig langsam,

    Wenn man die beiden Tests einbaut, die ich vorgeschlagen habe, dann ändert das weder etwas an der Geschwindigkeit noch am Speicherbrauch.

    /Mecki

  10. Re: Softwarequalität im freien Fall

    Autor: /mecki78 11.07.19 - 20:21

    Mohrhuhn schrieb:
    --------------------------------------------------------------------------------
    > Lieber ein Schrott Programm als gar kein Programm

    Also wenn das Schrottprogramm deinen Rechner dauerhaft lahmlegt, ich glaube dann ist den meisten gar kein Programm lieber.

    /Mecki

  11. Re: Softwarequalität im freien Fall

    Autor: Stepinsky 11.07.19 - 21:17

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > In einer ZIP Datei steht doch, wie groß dessen Inhalt nach dem Auspacken
    > ist. Also...
    >
    > - die Angabe stimmt nicht, dann sollte aber ein Dekompressor spätestens
    > wenn er merkt, dass er bereits so viel Bytes entpackt hat, wie angegeben
    > war und der Datenstrom trotzdem nicht zu Ende ist, sofort mit einen Fehler
    > abbrechen, weil dann ist die Datei offensichtlich korrupt.

    Du müsstest diese Abfrage direkt in den Deflate-Algo einbauen. Aber gerade dieser Teil ist natürlich performance-empfindlich.

    > Wenn man die beiden Tests einbaut, die ich vorgeschlagen habe, dann ändert
    > das weder etwas an der Geschwindigkeit noch am Speicherbrauch.
    Hast du schon mit ZIP-Dekomprimierung gearbeitet oder wie kannst du so eine Aussage treffen?

    sevenacids schrieb:
    > Es geht ja hier nicht um komplexe Algorithmen. Für eine Integritätsprüfung
    > reicht im ersten Moment wirklich der Wert, der die Größe der entpackten
    > Daten angibt und diesen auszulesen und auf Plausibilität zu prüfen
    > erfordert nun wirklich nicht viel Rechenzeit.
    Aber woher soll der Algo denn vor dem Entpacken wissen, ob die angegebene Größe stimmt? Und wenn du dir den zitierten Blog-Beitrag durchliest, hört sich das alles nicht so trivila an. Oder hast du schon selbst einen ZIP-Algo programmiert?

    > Von daher ist es schon
    > seltsam, dass sowas wie eine ZIP-Bombe existieren kann, weil ich der
    > Meinung bin, dass man sowas auch ordentlich, um nicht zu sagen intelligent,
    > implementieren kann.
    Das ZIP-format ist älter und kann aus Kompatibilitätsgründen nicht beliebig neu implementiert werden. Hast du dir die Spezifikationen schon mal durchgelesen?

    Ich fürchte, ihr habt auch nicht mehr Ahnung wie ich von der Programmierung eines Komprimierungs-Algos bzw. speziell des ZIP-Verfahrens. Dann sollte man aber etwas vorscihtiger mit den eigenen Aussagen sein.
    Ich finde es immer verdächtig, wenn jemand alle anderen für Vollidioten hält. Der ZIP-Algo wurde schließlich nicht nur von einer einzelnen Firma implementiert.

  12. Re: Softwarequalität im freien Fall

    Autor: /mecki78 11.07.19 - 22:18

    Stepinsky schrieb:
    --------------------------------------------------------------------------------
    > Du müsstest diese Abfrage direkt in den Deflate-Algo einbauen.

    Also ich weiß zwar nicht genau, wie der Code intern aussieht, aber das Interface nach Außen habe ich schon oft benutzt um Daten damit zu entpacken und das schreibt Bytes in Chunks, d.h. du gibst dem Funktionsaufruf einen RAM Puffer und er füllt diesen RAM Puffer dann mit Daten. Ist der voll, dann hört er auf zu entpacken (was ja irgendwo mitten im Datenstrom der Fall sein kann und meistens auch ist, außer der Puffer war größer als die zu entpackenden Daten), dann kommt der Funktionsaufruf zurück und teilt dir mit, dass er pausieren musste, weil der Ausgabepuffer voll ist, aber der Datenstrom noch nicht am Ende. Dann musst du entweder diesen Puffer leeren (z.B. Inhalt auf die Platte schreiben), dann kannst du ihn wiederverwenden oder du rufst die Funktion erneut mit einem anderen, noch leeren Puffer auf, dann kann die schon mal den weiter befüllen während du z.B. auf einen Hintergrund Thread den vorherigen Pufferinhalt auf die Platte schreibst (oder über das Netzwerk sendest, durch einen Parser jagst, etc. je nachdem was du da eigentlich gerade tust).

    Diese Puffer können so ziemlich beliebige Größe haben, bzw. es gibt vielleicht eines Mindest- und eine Maximalgröße, das habe ich gerade nicht im Kopf, aber ich weiß, dass du auch mit ganz kleinen Puffern von wenigen KB arbeiten kannst. Natürlich ist es deutlich performanter, wenn du möglichst große Puffer nutzt, z.B. 1 MB oder gleich 10 MB, weil dann muss die Funktion nicht so oft "absetzen", da sie bei jedem Pausieren internen State weg sichern muss, damit sie beim nächsten Aufruf genau dort weitermachen kann, wo sie vorhin abgebrochen hat. Und am besten du hast gleiche einen Pool, so dass du mindestens immer einen Puffer hast, der gerade befüllt wird (weil hier wird die CPU belastet), einer der schon voll ist und gerade weiter verarbeitet wird (meistens sind das I/O Operationen, die belasten kaum die CPU, aber eben die Platte oder das Netzwerk) und mindestens noch einen freien, der sofort einspringen kann, wenn der aktuell voll läuft (um lange Pausen zu vermeiden). Die verarbeiteten Puffer werden dann wieder zurück in den Pool geworfen und damit quasi recycled, weil das weniger Zeit kostet als die Puffer jedes mal zu vernichten und dann bei Bedarf wieder einen neuen zu erzeugen. Wann immer du einen braucht, holst du dir einen aus den Pool. Nachteil ist mehr Speicherverbrauch, aber 3 Puffer á 10 MB sind gerade mal 30 MB, denen weint niemand einen Träne nach.

    Für den von mir vorgeschlagenen Test, musst du nur immer dann, wenn ein Puffer vollgeschrieben wurde, die Größe des Puffers auf einen Zähler addieren, der die Gesamtgröße alles bisher gelieferten Puffer summiert und dann einmal schauen ob dieser Wert jetzt größer ist als er laut Indextabelle hätten werden dürfen. Ist er größer und die Funktion will einen weiteren Puffer haben, dann stimmt da was nicht, weil der Stream sollte schon lange zu ende sein, da du bereits so viel Bytes entpackt hast, wie die Datei angeblich groß ist, also sollten da keine weiteren Daten mehr kommen. Und um das mal in ein Verhältnis zu setzen: Diese eine Addition und der anschließende Test brauchen nicht mal ein hundertstel der Zeit, die man braucht so einen Puffer auf die Festplatte zu schreiben, eher ein tausendstel. Und auch das auf die Platte schreiben von 10 MB braucht deutlich unterhalb einer Sekunde, Festplatten können so um die 150 MB und SSD so um die 500 MB die Sekunde auf die Platte schreiben.

    > Ich fürchte, ihr habt auch nicht mehr Ahnung wie ich von der Programmierung
    > eines Komprimierungs-Algos bzw. speziell des ZIP-Verfahrens.

    Also wie ZIP grundsätzlich funktioniert, das ist mir schon bekannt. Ich kenne die ganzen Algorithmen, die der verwendet, zumindest in der Theorie. Ich habe zwar noch nie einen ZIP Decompressor geschrieben, aber ich habe z.B. mal einen LZO Decompressor geschrieben. LZO ist deutlich einfacher aufgebaut und erreicht deutlich schlechtere Kompressionsraten, aber darum ging es dem Entwickler auch nicht, sondern es ist unheimlich schnell. Selbst mit einer schwachen CPU dauert es nur minimal länger, ob man die Daten jetzt unkomprimiert durch reicht oder mit LZO komprimiert, aber sind die Daten gut komprimierbar, dann kann LZO die Datenmenge durchaus merklich reduzieren. LZO nutzen z.B. die Dateisysteme btrfs und ZFS bzw. sie bieten es als Option an und auch einer der NASA Rover auf den Mars hat die Daten mit LZO komprimiert, bevor er sie an die Erde gesendet hat, weil das sind alles Anwendungsfälle wo es weniger auf die Kompressionsrate als viel mehr auf die Geschwindigkeit ankommt.

    Daher habe ich schon eine grobe Vorstellung, wie in etwa der ZIP Code aussehen müsste. Klar, natürlich ist der um ein vielfaches komplexer, aber wie gesagt, an der Stelle muss ich den Code doch gar nicht anfassen. Da der Code nie mehr Daten schreibt als in einen Puffer passen, kann da erst mal nichts schief gehen. Es reicht wenn ich jedes mal nachschaue wenn wieder ein Puffer voll geschrieben wurde und das ist ja jetzt wirklich kein Hexenwerk.

    /Mecki

  13. Re: Softwarequalität im freien Fall

    Autor: ThomasSV 11.07.19 - 22:27

    FUD!

    Du hoffst auch nur, dass hier niemand rumlungert, der sich mit dem guten alten PKZip auskennt.

    Aber ich muss Dich enttäuschen.

    Zu Deinen Befürchtungen:
    Die Abfrage kommt nicht in den Entpack-Algo, sondern in den Teil, der das Entpackte auf die Platte bringt: nur der Teil hat näml. die korrekten Zahlen.

    Natürlich verlangsamt das den Schreibvorgang. Zumindest theoretisch. Ob man das messen kann, wage ich zu bezeifeln. (und ja: ich kenne Format & Algo)

    Für den Entpacker selber wäre es tatsächlich relativ schwer, über die entpackte Größe Buch zu führen: dafür sind die Chunks normalerweise zu zahlreich und gerne auch nicht Vielfache von 8bit...

    Solche ZIPBomben gibt‘s wohl, weil heute eh keiner mehr ein unzip programmiert. Da wird gerade noch eine Lib eingebunden. Und offensichtlich ist der Markt weder für die Nutzer noch die Entwickler der Libs sowas wert.

    Apropos:
    Hat hier jmd. schon mal Geld für einen Packer ausgegeben, der (vor allem) ZIP kann?

    Eben...

  14. Re: Softwarequalität im freien Fall

    Autor: mambokurt 12.07.19 - 00:41

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > In einer ZIP Datei steht doch, wie groß dessen Inhalt nach dem Auspacken
    > ist. Also...
    >
    > - entweder stimmt die Angabe, dann weiß aber ein Dekompressor schon im
    > Vorfeld, dass da 4,5 PBytes rauskommen und dass das die Kapazität lokaler
    > Datenspeicher deutlich übersteigt, ergo sollte er nicht mal anfangen was
    > auszupacken sondern mit einen Fehler abbrechen.

    A) es gibt Situationen da kannst du nicht ermitteln wie viel Platz frei ist
    B) wird wohl eher nicht die korrekte Größe im Zipfile stehen (jedenfalls nicht wenn man sich den Blog durchliest und sieht wie der gute Mann das Format gegen sich selbst wendet)

    > - die Angabe stimmt nicht, dann sollte aber ein Dekompressor spätestens
    > wenn er merkt, dass er bereits so viel Bytes entpackt hat, wie angegeben
    > war und der Datenstrom trotzdem nicht zu Ende ist, sofort mit einen Fehler
    > abbrechen, weil dann ist die Datei offensichtlich korrupt.

    Es reicht wenn der Packer nicht nach Spec gearbeitet hat, kommt vor. Siehe unten.

    > Das sind doch zwei sehr einfach abzufangende Fehlerfälle.
    > Wird Software heute nur noch von Idioten geschrieben?
    > Ich darf das fragen, denn ich wäre dann so einer dieser Idioten, nur wie
    > gesagt, ich hätte das so wie oben erwähnt implementiert. Als es hieß "Jeder
    > kann programmieren" war damit nicht gemeint, dass es auch jeder tun sollte.

    Die eigentliche Frage ist deine Kernkompetenz bzw die deines Programmes. Wenn du ein Programm namens SecureZip vertreibst und damit wirbst dass das Dateien nicht entpackt sobald sie komisch sind bekommst du sicherlich deinen Kundenstamm von Aluhutträgern zusammen. Der Rest der Menschheit möchte aber einfach nur möglichst die Daten aus der Zip gepopelt bekommen. Da sind wir dann am Punkt von oben. Zip ist ein olles Format und du musst mit deinem Entpacker im Zweifel Kram von vor 20 Jahren entpacken der mit irgendeinem halbkapputten zusammengefrickelten Packer erstellt wurde. Dann erklär mal deinem Kunden 'ich könnte das entpacken, aber per Definition ist das nicht in Ordnung!'.
    Wenn möglich sollte man heute natürlich davon ausgehen dass alles was an Input kommt dich auf die bösest mögliche Art ins Gesicht schießen will, aber wenn deine Kernkompetenz das Entpacken von Daten ist kannst du nicht viel mehr machen als einen Dialog anzeigen und warnen, und wir wissen alle dass sowas einfach weggeklickt wird. Mal davon abgesehen: im Nachhinein schreien 'jahaaa das darfste so nich nachen!' ist natürlich sehr einfach, da muss man aber auch mal sehen dass der Core der ganzen Programme am Markt wahrscheinlich 20 Jahre alt ist und nicht mehr groß überarbeitet wurde. Vielleicht mal refaktorisiert und hübsch gemacht aber den Algorithmus dahinter fasst doch keiner an, und wenn der nach Spec arbeitet ist er auch gut. Die Spec ist das Problem, die basiert immer noch auf einer Spec von 1989. Und da hat halt niemand daran gedacht das irgendwie abzusichern, da gings noch pur um Effizienz und Funktion.

  15. Re: Softwarequalität im freien Fall

    Autor: freebyte 12.07.19 - 09:50

    ThomasSV schrieb:
    --------------------------------------------------------------------------------
    > Für den Entpacker selber wäre es tatsächlich relativ schwer, über die
    > entpackte Größe Buch zu führen: [...]

    Warum? Der Entpacker-Core muss eh zurückgeben, wie weit der Übergabebuffer gefüllt wurde. Damit weiss er auch, wieviel (entpackte) Bytes er aus diesem Stream zurückgegeben hat.

    Die Prüfung selbst (Grösse im Direktory vs. entpackte Größe) hat imho aber nichts im Core zu tun, das muss auf Applikationsebene gemacht werden weil man dort auch das Dictionary gelesen hat.

    fb

  16. Re: Softwarequalität im freien Fall

    Autor: tomatentee 12.07.19 - 11:53

    Ich tippe einfach, dass die Berechnung der zur erwartenden Größe nicht präzise ist, sonst würde das so gemacht.

  17. Re: Softwarequalität im freien Fall

    Autor: Tuxgamer12 12.07.19 - 16:15

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Wird Software heute nur noch von Idioten geschrieben?

    Völlig richtig. Hängt vielleicht damit zusammen:

    https://www.der-postillon.com/2015/03/wissenschaftlich-erwiesen-alles.html

    Ernsthaft: Verfügbaren Speicherplatz prüfen ist sicherlich keine Aufgabe des eigentlichen unzippers (denn der soll einfach nur seinen Job "unzippen" machen). Wohl aber Aufgabe der jeweiligen Anwendung (z.B. Dateimanager).

    Was natürlich durchaus gemacht wird.

    Z.B. nautilus bringt sofort, Windows 10 File Explorer nach bisschen herumrechnen entsprechenden Fehler "nicht genügend Speicher" - gerade getestet.
    Wie im verlinkten Blog beschrieben, hat z.B. der Mozilla addons-server einfach Timeout nach 110 Sekunden - was auch gegen andere Typen Zip-Bomben schützt, die z.B. versuchen den Entpacker in eine Endlosschleife laufen zu lassen.

    McAfee AV soll dagegen laut Twitter-Tweet fürchterlich crashen - was mich aber bei den Antiviren-Schrott nicht zu sehr verwundert ;).

    Jedenfalls, daraus zu verallgemeinern "Softwarequalität im freien Fall" und pauschal jeden Softwareentwickler für (möglicherweise) blöd zu erklären - das ist jedenfalls nicht in Ordnung.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Fraunhofer-Institut für Optronik, Systemtechnik und Bildauswertung IOSB, Karlsruhe
  2. operational services GmbH & Co. KG, Wolfsburg
  3. Adecco Personaldienstleistungen GmbH, Erfurt
  4. spectrumK GmbH, Berlin

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 3,74€
  2. 4,19€
  3. 49,94€
  4. 4,32€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Endpoint Security: IT-Sicherheit ist ein Cocktail mit vielen Zutaten
Endpoint Security
IT-Sicherheit ist ein Cocktail mit vielen Zutaten

Tausende Geräte in hundert verschiedenen Modellen mit Dutzenden unterschiedlichen Betriebssystemen. Das ist in großen Unternehmen Alltag und stellt alle, die für die IT-Sicherheit zuständig sind, vor Herausforderungen.
Von Anna Biselli

  1. Datendiebstahl Kundendaten zahlreicher deutscher Firmen offen im Netz
  2. Metro & Dish Tisch-Reservierung auf Google übernehmen
  3. Identitätsdiebstahl SIM-Dieb kommt zehn Jahre in Haft

Erneuerbare Energien: Die Energiewende braucht Wasserstoff
Erneuerbare Energien
Die Energiewende braucht Wasserstoff

Kein anderes Element ist so universell und dabei simpel aufgebaut wie Wasserstoff und das energiereiche Gas lässt sich aus fast jedem Energieträger gewinnen. Genauso vielseitig gestaltet sich seine Nutzung.
Ein Bericht von Jan Oliver Löfken

  1. Strom-Boje Mittelrhein Schwimmende Kraftwerke liefern Strom aus dem Rhein
  2. Speicherung von Überschussstrom Wasserstoff soll bei Engpässen helfen
  3. Energiewende DLR-Forscher bauen Kohlekraftwerke zu Stromspeichern um

Erasure Coding: Das Ende von Raid kommt durch Mathematik
Erasure Coding
Das Ende von Raid kommt durch Mathematik

In vielen Anwendungsszenarien sind Raid-Systeme mittlerweile nicht mehr die optimale Lösung. Zu langsam und starr sind sie. Abhilfe schaffen können mathematische Verfahren wie Erasure Coding. Noch existieren für beide Techniken Anwendungsgebiete. Am Ende wird Raid aber wohl verschwinden.
Eine Analyse von Oliver Nickel

  1. Agentur für Cybersicherheit Cyberwaffen-Entwicklung zieht in den Osten Deutschlands
  2. Yahoo Richterin lässt Vergleich zu Datenleck platzen

  1. TLS-Zertifikat: Gesamter Internetverkehr in Kasachstan kann überwacht werden
    TLS-Zertifikat
    Gesamter Internetverkehr in Kasachstan kann überwacht werden

    In Kasachstan müssen Internetnutzer ab sofort ein spezielles TLS-Zertifikat installieren, um verschlüsselte Webseiten aufrufen zu können. Das Zertifikat ermöglicht eine staatliche Überwachung des gesamten Internetverkehrs in dem Land.

  2. Ari 458: Elektro-Lieferwagen aus Leipzig kostet knapp 14.000 Euro
    Ari 458
    Elektro-Lieferwagen aus Leipzig kostet knapp 14.000 Euro

    Ari 458 ist ein kleiner Lieferwagen mit Elektroantrieb, den der Hersteller mit Aufbauten für verschiedene Einsatzzwecke anbietet. Die Ausstattung ist einfach, dafür ist das Auto günstig.

  3. Quake: Tim Willits verlässt id Software
    Quake
    Tim Willits verlässt id Software

    Seit 24 Jahren ist Tim Willits einer der entscheidenden Macher bei id Software, nun kündigt er seinen Rückzug an. Was er künftig vorhat, will der ehemalige Leveldesigner und studierte Computerwissenschaftler erst nach der Quakecon verraten.


  1. 17:52

  2. 15:50

  3. 15:24

  4. 15:01

  5. 14:19

  6. 13:05

  7. 12:01

  8. 11:33