LibreKAT/Ocideck
LibreKAT/Ocideck
Watch
4
0
Fork
You've already forked Ocideck
 1
Code Issues Pull requests Projects Releases 21 Packages Activity Actions

PDF-export breekt een code-token (hash, IP-adres, bestandsnaam) midden in af, zonder markering #1789

New issue
Closed
opened 2026-08-26 11:48:25 +00:00 by brenno · 3 comments
brenno commented 2026-08-26 11:48:25 +00:00
Owner
Copy link

Wat is het probleem?

In de PDF-documentexport breekt package:pdf een aaneengesloten code-token (inline code, `-gemarkeerd) midden in het token af zodra de kolom smaller is dan het token, en zonder enige aanduiding dat er een breuk zit. Bij prozawoorden is dat lelijk (#1727); bij een hash, een IP-adres of een bestandsnaam is het een inhoudelijk defect: de lezer kan de waarde niet betrouwbaar overnemen of vergelijken.

Dit is de opvolging van #1727: die ging over Nederlandse woorden in tabelcellen. Deze gaat over tokens die per definitie niet op een woordgrens mogen breken.

Hoe te reproduceren

  1. Maak een document met een tabel waarin een kolom inline-code-tokens bevat die breder zijn dan de kolom:
| Bestandstype | Bestandsnaam | SHA-256 |
|---|---|---|
| EVTX | `RD01-SecurityLogs.evtx` | `9936839ce155c2f1c5a5424d55d8b3931df7d1fe976dab5c56a7ae415e729c91` |
| ZIP-archief | `GW01-IISLogs.zip` | `c2704d20f45f5bdd5e021a963cb80c23c981e623b9ea75edff6b5e75b7d80a28` |
  1. Exporteer naar PDF.

Verwacht gedrag

Een code-token breekt niet, of breekt met een zichtbare voortzettingsaanduiding, of de kolom krijgt de breedte die het token nodig heeft. Een lezer kan de waarde overnemen zonder te hoeven raden waar een regeleinde zat en of daar een teken is weggevallen.

Werkelijk gedrag

Waargenomen in Incidentrapport-RWM-aanval-op-de-externe-werkomgeving-RDWebRD-Gateway-volledig.pdf (OciDeck 0.4.10), §12.1 "Technische bijlage — digitale vingerafdrukken van bewijsbestanden", pagina's 41–43:

  • SHA-256- en SHA-512-waarden staan over drie tot vier regels verdeeld zonder enige markering;
  • bestandsnamen breken: securitylog.e / vtx, u_ex260725.lo / g, GW01-Applicat / ion-Security( / mogelijkdubbe / l)-System.zip;
  • de kop Bestandstype staat verticaal over vijf regels: Be / sta / nd / sty / pe, waardoor de kopband ruim 110 pt hoog wordt.

In §19.4 (pagina's 64–66) gebeurt hetzelfde met IP-adressen: 178.230.197. / 173, 77.62.145.11 / 0, 212.85.56.16 / 2, 217.18.80.23 / 4, 84.241.213.3 / 8.

Waarom dit zwaarder weegt dan #1727

§12.1 is een chain-of-custody-bijlage. Het doel van die tabel is dat een derde de hashes kan natellen. Een hash die willekeurig over vier regels is gehakt is daarvoor onbruikbaar — het defect raakt de functie van het document, niet alleen de leesbaarheid.

Richting voor een oplossing

Behandel een PdfSpan met code/monospace als één ondeelbare eenheid bij het bepalen van de kolombreedte: het flex-gewicht in pdfTableColumnWidths (lib/services/pdf/document_pdf_widgets.dart) neemt nu het langste woord, maar een token van 64 tekens hoort de kolom te dwingen. Waar de bladspiegel dat onmogelijk maakt, is een expliciete voortzettingsaanduiding of een kleinere corpsgrootte voor die kolom beter dan een stille breuk.

## Wat is het probleem? In de PDF-documentexport breekt `package:pdf` een aaneengesloten code-token (inline code, `` ` ``-gemarkeerd) midden in het token af zodra de kolom smaller is dan het token, en zonder enige aanduiding dat er een breuk zit. Bij prozawoorden is dat lelijk (#1727); bij een hash, een IP-adres of een bestandsnaam is het een inhoudelijk defect: de lezer kan de waarde niet betrouwbaar overnemen of vergelijken. Dit is de opvolging van #1727: die ging over Nederlandse woorden in tabelcellen. Deze gaat over tokens die per definitie niet op een woordgrens mogen breken. ## Hoe te reproduceren 1. Maak een document met een tabel waarin een kolom inline-code-tokens bevat die breder zijn dan de kolom: ```markdown | Bestandstype | Bestandsnaam | SHA-256 | |---|---|---| | EVTX | `RD01-SecurityLogs.evtx` | `9936839ce155c2f1c5a5424d55d8b3931df7d1fe976dab5c56a7ae415e729c91` | | ZIP-archief | `GW01-IISLogs.zip` | `c2704d20f45f5bdd5e021a963cb80c23c981e623b9ea75edff6b5e75b7d80a28` | ``` 2. Exporteer naar PDF. ## Verwacht gedrag Een code-token breekt niet, of breekt met een zichtbare voortzettingsaanduiding, of de kolom krijgt de breedte die het token nodig heeft. Een lezer kan de waarde overnemen zonder te hoeven raden waar een regeleinde zat en of daar een teken is weggevallen. ## Werkelijk gedrag Waargenomen in `Incidentrapport-RWM-aanval-op-de-externe-werkomgeving-RDWebRD-Gateway-volledig.pdf` (OciDeck 0.4.10), §12.1 "Technische bijlage — digitale vingerafdrukken van bewijsbestanden", pagina's 41–43: - SHA-256- en SHA-512-waarden staan over drie tot vier regels verdeeld zonder enige markering; - bestandsnamen breken: `securitylog.e` / `vtx`, `u_ex260725.lo` / `g`, `GW01-Applicat` / `ion-Security(` / `mogelijkdubbe` / `l)-System.zip`; - de kop `Bestandstype` staat verticaal over vijf regels: `Be` / `sta` / `nd` / `sty` / `pe`, waardoor de kopband ruim 110 pt hoog wordt. In §19.4 (pagina's 64–66) gebeurt hetzelfde met IP-adressen: `178.230.197.` / `173`, `77.62.145.11` / `0`, `212.85.56.16` / `2`, `217.18.80.23` / `4`, `84.241.213.3` / `8`. ## Waarom dit zwaarder weegt dan #1727 §12.1 is een chain-of-custody-bijlage. Het doel van die tabel is dat een derde de hashes kan natellen. Een hash die willekeurig over vier regels is gehakt is daarvoor onbruikbaar — het defect raakt de functie van het document, niet alleen de leesbaarheid. ## Richting voor een oplossing Behandel een `PdfSpan` met `code`/monospace als één ondeelbare eenheid bij het bepalen van de kolombreedte: het flex-gewicht in `pdfTableColumnWidths` (`lib/services/pdf/document_pdf_widgets.dart`) neemt nu het langste *woord*, maar een token van 64 tekens hoort de kolom te dwingen. Waar de bladspiegel dat onmogelijk maakt, is een expliciete voortzettingsaanduiding of een kleinere corpsgrootte voor die kolom beter dan een stille breuk.
brenno commented 2026-08-26 12:15:37 +00:00
Author
Owner
Copy link

Opgepakt samen met #1794 — zelfde functie. Tak fix/pdf-tabelbreedte-1789-1794.

Opgepakt samen met #1794 — zelfde functie. Tak `fix/pdf-tabelbreedte-1789-1794`.
brenno commented 2026-08-26 13:21:40 +00:00
Author
Owner
Copy link

Deels opgelost in PR #1795.

Wat weg is. De letter van een tabel krimpt nu tot elke kolom haar langste woord op één regel draagt, en de vaste-breedteletter krimpt mee. IP-adressen en een SHA-256 van 64 tekens blijven daardoor heel — beide staan als regressietoets in document_pdf_render_test.dart.

Wat blijft. Een SHA-512 van 128 tekens niet. Onder minTableFontScale (0,62) krimpt de letter niet verder, omdat een tabel daaronder eerder onleesbaar wordt dan behulpzaam. De hashtabel van §12.1 in het RDWeb-rapport heeft op 11 punt ruwweg 1400 punten nodig tegen 470 beschikbaar — een factor 0,34, ruim onder de ondergrens.

Waarom dat geen bug meer is maar een keuze. 128 hexadecimale tekens zijn breder dan een A4 ooit kan zijn. Elke oplossing binnen de tabelvorm is slecht: doorkrimpen levert onleesbare 4-punts tekst, afbreken mét markering maakt de waarde alsnog onovertypbaar, en een liggend blad verschuift de grens maar haalt hem niet weg.

Voor die tabel is de tabelvorm zelf de verkeerde keuze. De bruikbare vorm is een blok per bestand met de hashes onder elkaar op eigen regels, waar de volle bladbreedte beschikbaar is. Dat is een wijziging in het rapport, niet in de renderer — maar OciDeck kan de auteur er wél op wijzen. Een kwaliteitsmelding "deze tabel past niet en wordt afgebroken" ligt in het verlengde van #1280 en #1164, en zou dit soort stille verminking zichtbaar maken vóór de export. Dat is de zinvolle vervolgstap; dit issue blijft daarvoor open.

Deels opgelost in PR #1795. **Wat weg is.** De letter van een tabel krimpt nu tot elke kolom haar langste woord op één regel draagt, en de vaste-breedteletter krimpt mee. IP-adressen en een SHA-256 van 64 tekens blijven daardoor heel — beide staan als regressietoets in `document_pdf_render_test.dart`. **Wat blijft.** Een SHA-512 van 128 tekens niet. Onder `minTableFontScale` (0,62) krimpt de letter niet verder, omdat een tabel daaronder eerder onleesbaar wordt dan behulpzaam. De hashtabel van §12.1 in het RDWeb-rapport heeft op 11 punt ruwweg 1400 punten nodig tegen 470 beschikbaar — een factor 0,34, ruim onder de ondergrens. **Waarom dat geen bug meer is maar een keuze.** 128 hexadecimale tekens zijn breder dan een A4 ooit kan zijn. Elke oplossing binnen de tabelvorm is slecht: doorkrimpen levert onleesbare 4-punts tekst, afbreken mét markering maakt de waarde alsnog onovertypbaar, en een liggend blad verschuift de grens maar haalt hem niet weg. Voor die tabel is de tabelvorm zelf de verkeerde keuze. De bruikbare vorm is een blok per bestand met de hashes onder elkaar op eigen regels, waar de volle bladbreedte beschikbaar is. Dat is een wijziging in het rapport, niet in de renderer — maar OciDeck kan de auteur er wél op wijzen. Een kwaliteitsmelding "deze tabel past niet en wordt afgebroken" ligt in het verlengde van #1280 en #1164, en zou dit soort stille verminking zichtbaar maken vóór de export. Dat is de zinvolle vervolgstap; dit issue blijft daarvoor open.
brenno commented 2026-08-26 14:56:37 +00:00
Author
Owner
Copy link

Restpunt opgelost in 86452abf9 (PR #1797).

De export telt nu de tabellen die ook op de kleinste toegestane letter niet passen en meldt ze na afloop, langs dezelfde route als een ontbrekend teken of een te grof logo. De melding noemt de schade (lange waarden middenin afgebroken) én de twee vormen die wél passen — "maak de tabel smaller" is geen handeling die iemand kan uitvoeren.

Wat een afbreking van een SHA-512 betreft blijft de technische situatie zoals ze was: 128 hexadecimale tekens zijn breder dan een A4 ooit kan zijn, en elke oplossing bínnen de tabelvorm is slecht. Het verschil is dat de auteur het nu hóórt in plaats van het na het drukken te ontdekken. Daarmee is de titel van dit issue — "zonder markering" — afgedekt: de markering staat niet op de pagina maar op het scherm van wie exporteert.

Een afslag die ik heb laten liggen, voor wie hier later komt: de eerste opzet was een kwaliteitsregel in slide_quality_analyzer met een nieuwe SlideQualityIssueKind. Die laag kent het paginaformaat niet en had op een A4-aanname moeten rekenen — ernaast zodra iemand liggend of op A3 zet. De exportroute is korter én nauwkeuriger.

Restpunt opgelost in 86452abf9 (PR #1797). De export telt nu de tabellen die ook op de kleinste toegestane letter niet passen en meldt ze na afloop, langs dezelfde route als een ontbrekend teken of een te grof logo. De melding noemt de schade (lange waarden middenin afgebroken) én de twee vormen die wél passen — "maak de tabel smaller" is geen handeling die iemand kan uitvoeren. Wat een afbreking van een SHA-512 betreft blijft de technische situatie zoals ze was: 128 hexadecimale tekens zijn breder dan een A4 ooit kan zijn, en elke oplossing bínnen de tabelvorm is slecht. Het verschil is dat de auteur het nu hóórt in plaats van het na het drukken te ontdekken. Daarmee is de titel van dit issue — "zonder markering" — afgedekt: de markering staat niet op de pagina maar op het scherm van wie exporteert. Een afslag die ik heb laten liggen, voor wie hier later komt: de eerste opzet was een kwaliteitsregel in `slide_quality_analyzer` met een nieuwe `SlideQualityIssueKind`. Die laag kent het paginaformaat niet en had op een A4-aanname moeten rekenen — ernaast zodra iemand liggend of op A3 zet. De exportroute is korter én nauwkeuriger.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
v0.5.0
v0.4.10
v0.4.9
v0.4.8
v0.4.7
v0.4.6
v0.4.5
v0.4.4
v0.4.3
v0.4.2
v0.4.1
v0.4.0
v0.3.6
v0.3.5
v0.3.4
v0.3.3
v0.3.2
v0.3.1
v0.3.0
v0.2.0
v0.1.3
v0.1.2
v0.1.1
v0.1.0
archive/git-mirror
Labels
Clear labels   
accepted
Assessed and will be built

  
bug
Something is broken

  
declined
Assessed and will not be built

  
docs
Documentation only

  
duplicate
Already tracked elsewhere

  
enhancement
New feature or improvement request

  
good first issue
Small, self-contained, and a good place to start

  
in-progress
Someone is working on this right now. Do not start it in parallel.

  
needs-info
Waiting for the reporter

  
privacy
Personal data can leak. Handled before anything else.

  
security
A weakness someone could use. Handled before anything else.

  
triage
Awaiting assessment

No labels
accepted
bug
declined
docs
duplicate
enhancement
good first issue
in-progress
needs-info
privacy
security
triage
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
LibreKAT/Ocideck#1789
No description provided.