fix: authenticate PDF passwords with the spelling that actually unlocks the file

[nelsonduarte]

The problem

A correct password was accepted by the unlock prompt and then rejected by every tool that touched the same document. The user saw the document visibly open in the viewer, with a blank thumbnail strip, while each tool insisted the password was wrong.

Root cause

The app normalised passwords to NFC before handing them to either engine. NFC is a third spelling that neither engine uses.

• ISO 32000-2 section 7.6.4.3.3 mandates SASLprep (RFC 4013) for R6/AES-256. The Normalize step of SASLprep is NFKC, not NFC.
• pypdf implements SASLprep in full since 6.12.0 (_encryption._saslprep, ending in unicodedata.normalize("NFKC", ...)), applied in _encode_password whenever V >= 5 and the argument is a str.
• MuPDF does not normalise at all. pdf_saslprep_from_utf8 in pdf_crypt.c is a stub carrying a /* TODO: stringprep with SASLprep profile */ comment and copies the UTF-8 bytes verbatim.

So the prompt (fitz) and the tools (pypdf) could disagree about the very same password, and NFC matched neither.

What changed

New pure module app/pdf_password.py (no PySide6, no app.* import, fully headless-testable):

• Expands a typed password into a small ordered, de-duplicated candidate list: raw, SASLprep(raw), NFC(raw). NFD is deliberately absent, it is not a spelling any engine produces.
• Caches the spelling that actually authenticated, so every later operation reuses the exact bytes that worked instead of guessing again.
• Feeds both engines the same UTF-8 byte sequence (pypdf gets bytes, which skips its SASLprep branch; fitz gets the str, which MuPDF encodes to the same bytes), so they can no longer diverge by construction for R >= 5.

Encrypt tool probes instead of predicting. pypdf normalises on the write side, so the tool no longer tries to guess the spelling its own output will carry: it probes the written file and caches the spelling that opens it.

Password clearing reaches real paths. The clearing hook was on a path real documents never take, so the cache outlived the document it belonged to.

Wrong passwords are warnings, not crashes. Every raising site reached show_error, which put the generic "something went wrong, see the log" text in the primary slot and hid the real, already-translated sentence behind "Show Details", prefixed with a Python class name, in eight locales. A dedicated WrongPasswordError now routes to a warning with the translated message in the primary text and no traceback pane. The generic crash path is unchanged and still logs.

R <= 4 is best effort, and documented in the module. The spec defers to the host system code page there, so no conformance target exists and no single spelling is guaranteed to satisfy both engines.

How it was verified

• Suite grew from 592 to 673 passing (2 skipped), run in the project venv with QT_QPA_PLATFORM=offscreen.
• Coverage of the touched modules went from 35% to 58%; app/window.py from 0% to 52%.
• New tests: tests/test_unicode_passwords.py (candidate expansion and ordering, cached-winner reuse, encrypt probe, clearing, real encrypted-file round trips) and tests/test_wrong_password_dialog.py (asserts what the dialog is told to show: primary text, icon, presence or absence of the details pane, plus the generic path pinned so "warn on wrong password" cannot degrade into "warn on everything").
• The obsolete source-text NFC assertion in tests/test_polish_lows.py was replaced by behavioural round-trip tests against genuinely encrypted files, since a source-text assertion cannot distinguish the two presentations.

What is deliberately NOT in this PR

• The pypdf / cryptography bump together with the Flatpak pins in flatpak/requirements-pinned.txt. requirements.txt was reverted here on purpose so this PR stays a behaviour fix; the bump gets its own PR.
• _open_fitz fail-open behaviour, left as is.
• Metadata discarded by the encrypt tool, pre-existing and out of scope.
• R <= 4 non-Latin-1 passwords, unfixable without a conformance target (see above).
• fitz truncating at NUL, an upstream behaviour, not worked around here.
• Renaming the 11 _password sites in the render classes, a pure naming refactor with a real blast radius, kept separate.
• The designer's UX findings: message without the file name, lock icon deformed at HiDPI, primary button contrast, "Senha" versus "Palavra-passe" in PT, and the show-password toggle. All are UI polish, tracked separately.

CI

Only CodeQL runs on this PR. security-deps.yml is path-filtered to requirements.txt, flatpak/requirements-pinned.txt and its own workflow file, none of which this PR touches, so its strict pip-audit --strict gate does not fire.

[gitguardian]

️✅ There are no secrets present in this pull request anymore.

If these secrets were true positive and are still valid, we highly recommend you to revoke them.
While these secrets were previously flagged, we no longer have a reference to the
specific commits where they were detected. Once a secret has been leaked into a git
repository, you should consider it compromised, even if it was deleted immediately.
Find here more information about risks.

---

^{_{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}}

[cloudflare-workers-and-pages]

Deploying pdfapps with    Cloudflare Pages

Latest commit:	88d93c8
Status:	✅  Deploy successful!
Preview URL:	https://91b177cd.pdfapps.pages.dev
Branch Preview URL:	https://fix-unicode-password-normali.pdfapps.pages.dev

View logs