Begrenzte zlib-Dekompression: das kumulative Ausgabebudget während der Dekodierung durchsetzen

Worum es geht

Das Dekompressionsobjekt von Pythons zlib akzeptiert max_length, um die Ausgabe eines einzelnen decompress-Aufrufs zu begrenzen. Nicht verarbeitete Eingabe kann in unconsumed_tail verbleiben; eof unterscheidet einen vollständigen Stream, während unused_data Bytes jenseits seines Endes beschreibt. Die Grenze gilt pro Aufruf, sodass eine aufrufende Stelle ihr kumulatives Ausgabebudget separat durchsetzen muss. Python zlib

Warum es wichtig ist

Ein Agent fügt möglicherweise eine feste Chunk-Grösse hinzu und nimmt an, dass der Gesamtspeicher begrenzt ist, während jeder Chunk an eine wachsende Liste angehängt wird. Vor dem Dekodieren Grenzen für komprimierte Eingabe, erzeugte Ausgabe und Verarbeitungsaufwand festlegen. Zusätzlich entscheiden, ob das Protokoll verkettete Streams oder nachgestellte Bytes zulässt.

So wird es angewendet

• Eine aufgabenspezifische maximale Entpackgrösse wählen und das verbleibende Budget nach jedem erzeugten Chunk nachführen. Überschüssige Ausgabe zurückweisen, statt sie für eine spätere Prüfung aufzubewahren.
• Jedem begrenzten decompress-Aufruf ein explizites, positives Ausgabekontingent übergeben. Null mit Vorsicht behandeln, denn der dokumentierte Standardwert bedeutet unbegrenzte Ausgabe, nicht die Erlaubnis für null Bytes.
• unconsumed_tail behandeln, bevor über Eingabe hinweggegangen wird, die der Decoder nicht verarbeitet hat. An der Ausgabegrenze eine bewusste Strategie zur Erkennung von Vollständigkeit bzw. überschüssigen Daten anwenden statt eines unbegrenzten Flush.
• Nach Ende der Eingabe eof prüfen und die Vorgabe des Protokolls für unused_data anwenden. Einen abgeschnittenen Stream von einem sonst gültigen Stream mit unzulässigem nachgestelltem Inhalt unterscheiden.
• Fixtures vorschlagen für ein Ergebnis genau am Budget, ein Ergebnis über dem Budget, Abschneiden, nachgestellte Daten und Chunk-Grenzen innerhalb der komprimierten Darstellung.

Stolpersteine

Eine Obergrenze für die Ausgabegrösse begrenzt für sich genommen weder die CPU-Zeit noch die Speicherung der komprimierten Eingabe noch den Speicherbedarf nachgelagerten Parsings. Der Parameter für die Flush-Länge beschreibt eine anfängliche Puffergrösse, keine kumulative Sicherheitsobergrenze. Wo das Bedrohungsmodell es verlangt, ein externes Ausführungsbudget in Betracht ziehen. Dies sind vorgeschlagene Abwehrprüfungen; es wird weder ein Dekompressions-Benchmark noch ein Test zur Ressourcenerschöpfung behauptet.