[Security][P0] Maak het resourcebudget van presentatie-import volledig

brenno commented

2026-07-26 09:06:06 +00:00

Owner

Probleem

De presentatie-import begrenst inmiddels de ruwe invoer, ZIP-grootte en Snappy-uitvoer, maar de huidige grenzen zijn nog geen samenhangend resourcebudget. PresentationImportService.prepare accepteert tot 2 GiB volledig in geheugen; validatie en importer decoderen hetzelfde archief opnieuw. ZIP kent geen limiet op aantal entries of compressieverhouding en de importers begrenzen aantallen dia's, XML-nodes, IWA-records en protobuf-objecten niet. De Snappy-stream wordt bovendien eerst in een groeiende List<int> opgebouwd en daarna nogmaals naar Uint8List gekopieerd.

Risico

Een groot of speciaal geconstrueerd .pptx, .odp of .key kan buitensporig geheugen en CPU vragen, de app laten vastlopen of door het besturingssysteem laten beëindigen. De bestaande bytecaps beperken enkele gevallen, maar zijn hoog genoeg dat uitputting op gewone werkstations nog vóór de grens kan optreden.

Voorgestelde aanpak

Definieer één centraal importbudget met realistische platformgrenzen.
Begrens bronbytes, aantal archive-entries, grootte per entry en totaal, compressieverhouding, XML/IWA-partgrootte, dia's, records en protobuf-objecten.
Decodeer een archief niet tweemaal en vermijd dubbele volledige buffers.
Maak tijdsbudget/annulering onderdeel van hetzelfde contract.
Vertaal iedere overschrijding naar een stabiele ImportFailureReason met een begrijpelijke melding.

Acceptatiecriteria

Geen allocatie of iteratie wordt uitsluitend gestuurd door een onbegrensde waarde uit de bronpresentatie.
Normale presentaties blijven ondersteund binnen gedocumenteerde grenzen.
Overschrijding eindigt gecontroleerd zonder gedeeltelijk deck of crash.
Tests dekken ZIP-bommen, zeer veel entries, extreme Snappy-lengtes en buitensporige aantallen dia's/objecten.
Een geheugentest bewijst dat piekgebruik niet meegroeit naar meerdere volledige kopieën van de maximale invoer.

Verificatie

Draai make check, gerichte vijandige fixtures en een geheugen-/looptijdmeting op een representatief groot deck.

Herkomst

Verplaatst en tegen de actuele OciDeck-port herijkt vanuit Keiko #1.

## Probleem De presentatie-import begrenst inmiddels de ruwe invoer, ZIP-grootte en Snappy-uitvoer, maar de huidige grenzen zijn nog geen samenhangend resourcebudget. `PresentationImportService.prepare` accepteert tot 2 GiB volledig in geheugen; validatie en importer decoderen hetzelfde archief opnieuw. ZIP kent geen limiet op aantal entries of compressieverhouding en de importers begrenzen aantallen dia's, XML-nodes, IWA-records en protobuf-objecten niet. De Snappy-stream wordt bovendien eerst in een groeiende `List<int>` opgebouwd en daarna nogmaals naar `Uint8List` gekopieerd. ## Risico Een groot of speciaal geconstrueerd `.pptx`, `.odp` of `.key` kan buitensporig geheugen en CPU vragen, de app laten vastlopen of door het besturingssysteem laten beëindigen. De bestaande bytecaps beperken enkele gevallen, maar zijn hoog genoeg dat uitputting op gewone werkstations nog vóór de grens kan optreden. ## Voorgestelde aanpak - Definieer één centraal importbudget met realistische platformgrenzen. - Begrens bronbytes, aantal archive-entries, grootte per entry en totaal, compressieverhouding, XML/IWA-partgrootte, dia's, records en protobuf-objecten. - Decodeer een archief niet tweemaal en vermijd dubbele volledige buffers. - Maak tijdsbudget/annulering onderdeel van hetzelfde contract. - Vertaal iedere overschrijding naar een stabiele `ImportFailureReason` met een begrijpelijke melding. ## Acceptatiecriteria - Geen allocatie of iteratie wordt uitsluitend gestuurd door een onbegrensde waarde uit de bronpresentatie. - Normale presentaties blijven ondersteund binnen gedocumenteerde grenzen. - Overschrijding eindigt gecontroleerd zonder gedeeltelijk deck of crash. - Tests dekken ZIP-bommen, zeer veel entries, extreme Snappy-lengtes en buitensporige aantallen dia's/objecten. - Een geheugentest bewijst dat piekgebruik niet meegroeit naar meerdere volledige kopieën van de maximale invoer. ## Verificatie Draai `make check`, gerichte vijandige fixtures en een geheugen-/looptijdmeting op een representatief groot deck. ## Herkomst Verplaatst en tegen de actuele OciDeck-port herijkt vanuit [Keiko #1](https://pawprint.vigilis.online/brenno/Keiko/issues/1).

brenno added the

labels

2026-07-26 09:06:06 +00:00

brenno commented

2026-07-26 09:23:48 +00:00

Author

Owner

Opgepakt. Tak: fix/874-import-budget. Verwachte reikwijdte: nieuw lib/services/import/utils/import_budget.dart (één centraal budget), plus archive_utils.dart, xml_utils.dart, keynote/iwa/snappy.dart, presentation_import_service.dart en de drie importers voor de doorvoering; adversariële fixtures + een piekgeheugentest in test/import/.

brenno referenced this issue from a commit

2026-07-26 11:07:07 +00:00

fix(import): één centraal resourcebudget voor de presentatie-import (#874)

brenno referenced this issue from a commit

2026-07-26 11:31:16 +00:00

fix(import): één centraal resourcebudget voor de presentatie-import (#874)

brenno referenced this issue from a pull request that will close it,

2026-07-26 11:31:31 +00:00

fix(import): één centraal resourcebudget voor de presentatie-import (#874) #884

brenno closed this issue

2026-07-26 11:32:17 +00:00

brenno referenced this issue from a commit

2026-07-26 11:32:18 +00:00

Merge pull request 'fix(import): één centraal resourcebudget voor de presentatie-import (#874)' (#884) from fix/874-import-budget into main

brenno removed the

in-progress

label

2026-07-26 11:32:48 +00:00

brenno commented

2026-07-26 11:32:48 +00:00

Author

Owner

Gebouwd en gemerged in main (merge 760c3c6d, commit ef8be022, PR #884). Eén centraal ImportBudget, doorgevoerd op elk punt waar de bron de allocatie kon sturen; archief wordt nog maar één keer uitgepakt; Snappy zonder dubbele buffer; tel-caps op onderdelen/dia's/IWA-objecten; elke overschrijding eindigt als tooLarge met een leesbare limiet. make check groen (dekking 86,5%), secrets- en SAST-scan schoon, bewaker akkoord (afweging vastgelegd). Adversariële fixtures + decodeer-één-keer-test.

NIET hierin, bewust: tijdbudget/annulering horen bij hetzelfde contract maar krijgen pas betekenis op een worker-isolate — die landen in #875, aan ditzelfde budget-object. En één niet-blokkerende gebruikstekst-nuance (de weigermelding kan erbij zeggen dat het origineel bruikbaar blijft in het bronprogramma) raakt de tooLarge-l10n-string; apart mee te nemen om de scope zuiver te houden.

Gebouwd en gemerged in main (merge 760c3c6d, commit ef8be022, PR #884). Eén centraal ImportBudget, doorgevoerd op elk punt waar de bron de allocatie kon sturen; archief wordt nog maar één keer uitgepakt; Snappy zonder dubbele buffer; tel-caps op onderdelen/dia's/IWA-objecten; elke overschrijding eindigt als tooLarge met een leesbare limiet. make check groen (dekking 86,5%), secrets- en SAST-scan schoon, bewaker akkoord (afweging vastgelegd). Adversariële fixtures + decodeer-één-keer-test. NIET hierin, bewust: tijdbudget/annulering horen bij hetzelfde contract maar krijgen pas betekenis op een worker-isolate — die landen in #875, aan ditzelfde budget-object. En één niet-blokkerende gebruikstekst-nuance (de weigermelding kan erbij zeggen dat het origineel bruikbaar blijft in het bronprogramma) raakt de tooLarge-l10n-string; apart mee te nemen om de scope zuiver te houden.

brenno referenced this issue from a commit

2026-07-26 16:44:49 +00:00

feat(import): tijddeadline + serialiseerbaar taakcontract + platform-runner (#875)

brenno referenced this issue

2026-07-26 16:45:17 +00:00

fix(import): voer presentatievalidatie en parsing buiten de UI-isolate uit (#875) #902

brenno referenced this issue

2026-07-26 16:46:48 +00:00

[Prestaties][P0] Voer presentatievalidatie en parsing buiten de UI-isolate uit #875