snipeTRandBrandon Thomas 9c2d9c02bf fix(crypt): R2–R4 passwords with non-ASCII characters open (PDFDocEncoding) (#905) ...

Revisions 2–4 of the standard security handler take the password in
PDFDocEncoding (ISO 32000-2 §7.6.4.3.2, Algorithm 2). PdfCraft authenticates
an encrypted file twice, and neither did that:
- pdfcraft-crypt took Latin-1 and dropped every other character, so "ı"
  (0x9A) and "€" (0xA0) vanished and "ılık€" became "lk";
- the renderer (vendored hayro-syntax, "TODO: Convert to PDFDocEncoding")
  used the UTF-8 bytes, so any non-ASCII password failed, even "Çok güzel",
  which Latin-1 and PDFDocEncoding write alike;
- the engine handed the renderer an owner-recovered user password as Latin-1
  characters, which the renderer then read as UTF-8 again.
Files that qpdf or Acrobat protected with such passwords could not be
opened with the right password.

- pdfcraft-crypt encodes R2–R4 passwords in PDFDocEncoding and, for a
  password with characters PDFDocEncoding lacks (ğ, ş, İ), also tries its
  UTF-8 bytes, which qpdf writes for those. The PDFDocEncoding table moves
  here from pdfcraft-cos (which depends on this crate) and cos uses it.
- hayro-syntax (vendored patch 14) tries an R2–R4 password as given, then
  in PDFDocEncoding.
- The engine passes a recovered user password to the renderer as UTF-8 when
  its bytes are UTF-8 and as PDFDocEncoding otherwise, so the renderer gets
  exactly those bytes back.

Co-authored-by: Brandon Thomas <echelon@gmail.com>

2026-10-10 17:10:39 -04:00

..

src

fix(crypt): R2–R4 passwords with non-ASCII characters open (PDFDocEncoding) (#905)

2026-10-10 17:10:39 -04:00

Cargo.toml

Rename PrintCraft to PdfCraft (#174)

2026-10-07 16:03:57 -04:00