Encryption derives its keys from a prepared password, not the typed one:
AES-256 (R6) applies SASLprep, falls back to the password as given if
SASLprep refuses it, and truncates the UTF-8 to 127 bytes; RC4/AES-128
(R2-R4) use PDFDocEncoding cut or padded to exactly 32 bytes, and the
padding starts with "(". Protection::validate checked only the typed
strings, so a permissions password of U+00AD wrote a file that opens with
owner rights and no password, and an open password "A" with a permissions
password U+FF21 (or RC4/AES-128 passwords "a"x31 and "a"x31 + "(") wrote a
file whose open password lifts the restrictions.
pdfcraft-crypt gains effective_password(algorithm, password), the bytes the
keys are derived from (it and create share the private prepared_password
helper), re-exported from pdfcraft-cos. validate refuses a password whose
effective bytes are those of "", and an open and a permissions password
whose effective bytes are equal. Opening files is unchanged.
Fixes#1185.
* Issue #568: honour the document's copy permission
ISO 32000-2 §7.6.4.1 has readers restrict access to an encrypted file
according to its permissions, and Table 22 bit 5 covers "Copy or otherwise
extract text and graphics". PdfCraft reported the bit (Document Properties
shows "Content copying: Not allowed") but ⌘C copied selected text anyway.
- Engine: Document::allows_copying / check_copying, and Needs::Copying for
Take a snapshot, Export to image/text/Word/HTML/RTF and Export all images.
Save Image As refuses too.
- UI: ⌘C moves from canvas::shortcuts to the app, which knows the document.
Refused copies, snapshots and exports say why. The snapshot tool and the
exports check again when they act, since the tool stays selected across tabs.
- Automation: text_extract (and the MCP text resources), text_paragraphs,
doc_export_text/images/all_images, doc_export_office and image_save refuse.
Find, read aloud and the accessibility tools keep working: the spec exempts
assistive technology, and searching isn't copying. Page extraction stays with
the assemble bit, as before. Owners and unencrypted files are unaffected.
* Refresh catalog hashes
---------
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* Issue #870: keys leave the document under a dialog alone
With Preferences (or any other dialog) open, the registered shortcuts still
ran on the document underneath it: ⌘W / Ctrl+W closed the file, ⌘Z undid an
edit, ⌘F opened Find. In Organize Pages the grid's own keys did too, so Delete
or Backspace deleted the selected pages behind the dialog, and the grid took
the Escape meant to close it.
Every modal now owns the keyboard, as "Save changes?" already did:
PdfCraftApp::modal_open covers the dialog, the save, password and link
prompts and the update check. Shortcuts stop there, and the organize grid's
keys and autoscroll wait until the page is unobstructed.
* Contributors: credit jay-tau by their GitHub profile name
Joel Tony