* i18n: let the layers below hand their sentences over, so they can be translated
The accessibility findings, the PDF/A problems, the signature details, the
page-range mistakes and the edit labels were English in all ten languages,
because matching their wording from the UI with a tl! literal would break
silently whenever the engine changed it.
So each layer now hands the wording over instead, apart from the document's
own words: a WORDINGS list of every sentence it can say, with holes in it, and
said(&words), which looks the wording up through the closure it is given and
fills the holes in a single pass. in_english changes nothing, for the CLI and
the tests; the UI passes &i18n::words, a catalog lookup. A wording with no
entry comes back as it stands, which is the English, so the nine catalogs this
does not touch read exactly as before.
a11y::report_html takes a language tag and a words closure, so a saved report
reads the way the panel read, down to its lang attribute. print::PrintError
gained a variant per thing a person can be wrong about, with the numbers apart
from the words; faults rather than mistakes keep their own text.
Spanish translates all of it (107 entries). spanish_covers_what_the_engine_says
requires an entry per wording in the eight lists and
spanish_keeps_the_holes_in_what_the_engine_says requires the holes to survive
the translation, so the catalog cannot fall behind the engine unnoticed.
No new tl! literal, so the Chinese, French and Russian UI-literal gates are
unaffected.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* Sign tests from #1099: compare against the &'static str kinds
* Camera tests: undo returns a Label now
---------
Co-authored-by: Fernando Areán <soporte@codebit.es>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* fix(create): cap decoded size of imported PNGs
A PNG's declared dimensions sized an infallible allocation, so a few-byte file claiming huge dimensions aborted the process when the allocation failed. Cap the decoded size at the TIFF ceiling and reserve every input-sized buffer fallibly, returning CreateError::Image instead. (Security audit run-2: v3-024.)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* fix(xfa): bound total picture bytes kept during layout
Each laid-out picture kept its own copy, so one picture in a repeating subform multiplied without bound and could exhaust memory on open. Add a per-layout aggregate cap (256 MiB) that stops with XfaError::TooLarge. (Security audit run-2: v3-103.)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* fix(xfdf): bound XML nesting and protect redaction marks on import
Deeply nested XFDF/XML overflowed roxmltree's recursive parser and aborted the process; a non-recursive depth scan now rejects it before parsing. Imported comments could also replace a locked or redaction mark by /NM or add a hidden one; place() no longer replaces locked/Redact annotations and clears the hidden/invisible flags on imported redaction marks. (Security audit run-2: v3-105, v3-111.)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* fix(sign): classify post-signing changes by the signed revision's roles
A signed object's modification was classified from labels in the attacker-written new version, so relabelling a signed page /Type /Sig (or giving it /ModDate), or relabelling a drawn stream /ObjStm or /XRef, let a forged page validate as Valid even under DocMDP P=1. Decide an object's role (page content, signature, metadata, file plumbing) from what it was in the signed revision, not its new dictionary. (Security audit run-2: v3-082, v3-083.)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* fix(redact): remove redacted content from the saved file, fail closed otherwise
Apply Redactions and Remove Hidden Information left the originals behind: dropped or cleaned image/form XObjects kept their resource names (so the full rewrite saved the originals), an XFA form kept the redacted value in its datasets packet, and vertical-writing text under a mark was never hit by the horizontal removal geometry yet reported success. Prune replaced XObject names the page no longer draws, drop /XFA and /NeedsRendering when redacting an XFA form, and fail closed (RedactError::VerticalText) rather than silently leave vertical text. (Security audit run-2: v3-064, v3-067, v3-062.)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* fix(ui-egui): trust the displayed signer, not the document's embedded root
The Signatures panel's one-click 'Add to trusted certificates' trusted the top of the chain the document supplied, installing the author's self-signed root as an anchor instead of the signer shown. Trust the displayed signer certificate. (Security audit run-2: v3-098.)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Use main's decoded-size ceiling for PNGs too; keep the depth tests on main's checker
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* M9: visible digital signatures can show a drawn, typed or image graphic (#193)
A visible certificate signature can show a graphic where the signer's
name is large, as Acrobat's Configure Signature Appearance does: the
saved Fill & Sign signature (drawn, typed or image) or an imported
PNG/JPEG. Sign as previews it and remembers the choice; sign_document
takes `graphic` (image, text or strokes).
pdfcraft-sign gains `Graphic` and `SignOptions::graphic`. Graphics are
checked and size-capped before drawing; images keep alpha as a soft
mask and are encrypted with the rest of the update in encrypted files.
Refs #193
* Refresh catalog hashes
---------
Co-authored-by: Brandon Thomas <echelon@gmail.com>
Token identities that macOS exposes through CryptoTokenKit (a CAC or PIV
card in a reader) were not listed: the Keychain search only covered the
file-based keychains. keychain::identities now also searches the token
access group, de-duplicates by certificate, and skips card certificates
whose key usage allows neither digitalSignature nor nonRepudiation (the
CAC encryption certificate, which would produce a signature that fails
validation). Card identities are labelled "(smart card)" in the sign
dialog. The key never leaves the card; macOS asks for the PIN.
Claude-Session: https://claude.ai/code/session_0158vdscYZsFFCPLjokXoyzM
Co-authored-by: sfv9 <286824270+sfv9@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
A store certificate PdfCraft can't use (no private key, a P-521 /
Brainpool / Ed25519 key, a key CNG can't open) was dropped from the
Sign dialog silently, so a user whose CA-issued identity shows in
Acrobat but not here had nothing to go on. `windows::list` now returns
those under `unusable` with the subject, fingerprint and a reason that
names the Windows error code; the Sign dialog shows them greyed and
unselectable with the reason, and `sign_windows_ids` returns them.
A key that needs a prompt to open (NTE_SILENT_CONTEXT, NTE_UI_REQUIRED
while listing) is listed and prompts at signing instead of being
skipped. Certificates without a private key stay out of the dialog but
are reported by the tool.
Tests: the explained-error table, the store listing's invariants, a
key-less certificate in the ignored store test, the automation output,
and a kittest dialog test for a greyed entry. Verified by hand that a
.p12 imported into the CNG and legacy Microsoft providers lists, and
that a P-521 certificate is explained.
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* M9: sign and timestamp encrypted documents
Signing a password-protected PDF failed with "not supported: signing
encrypted documents". The writer encrypted every string, including the
signature's /Contents placeholder, which the signer patches in place
after hashing.
- cos: a signature dictionary's /Contents is never encrypted or
decrypted (ISO 32000-2 §7.6.2), identified by /Type /Sig|/DocTimeStamp
or by /Contents + /ByteRange. Existing signatures in encrypted files
now read their real CMS and survive rewrites of their dictionary.
- sign: the blanket refusal is replaced by the document's permissions
(Table 22) when opened with the user password: existing fields and
document timestamps need fill-forms, new fields need annotate +
modify, certifying needs modify. Refusals name the permissions
password.
- Tests for all four algorithms, counter-signing, tampering,
permissions, document timestamps and the sign_document tool; parity
entry sign.encrypted-documents; ROADMAP log.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Hadi Chokr <hadichokr@icloud.com>
* M9: signing an encrypted document waits for a pending security change to be saved
Otherwise the incremental save becomes a full rewrite that applies or removes protection while
signing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Signed-off-by: Hadi Chokr <hadichokr@icloud.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* Parity: merge the duplicate form.field-list evidence and notes
#649 and #650 each added `evidence` and `notes` to the same entry, so the
TOML has duplicate keys and `cargo xtask parity` fails on main.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* M9: the signer's certificate must allow document signing (key usage, EKU, critical extensions)
A trusted signer whose certificate may not sign documents was reported
Valid. Validation now checks the signer certificate (RFC 5280 §4.2.1.3,
§4.2.1.12, §4.2): a keyUsage needs digitalSignature or nonRepudiation, an
extended key usage needs a document-signing purpose (any, emailProtection,
codeSigning, RFC 9336 documentSigning, Adobe Authentic Documents, Microsoft
document signing), and no critical extension may be one PdfCraft doesn't
process. Otherwise the verdict is Unknown and the details say why.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* M9: a critical qcStatements extension doesn't make a qualified certificate unusable
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* Sign: decide Windows store keys in code every platform builds
#646 fixed the Windows build after #386 with `_` arms in the two
matches in windows.rs. That module is cfg(windows), so Linux and macOS
CI never compile it, and the next PublicKey variant will either break
the Windows build again or, now, fall into `_` without anyone choosing.
The store's two decisions move into keys.rs, which every platform
builds, with every variant named and no `_` arm:
- PublicKey::store_signing_key: RSA, or ECDSA with 256/384 bits, or
None for the kinds PdfCraft only verifies with (P-521, brainpool,
Ed25519, Unsupported).
- PublicKey::store_signature_der: CNG's raw r||s as DER (RSA as is);
the verify-only kinds return SignError::Unsupported, as since #646.
windows.rs calls both, with no `_` arms left. Behaviour is unchanged.
tests/store_keys.rs runs everywhere: every variant's answer (with an
exhaustive match, so a new variant must be added to it), the P-256 and
P-384 conversion round-tripped through PublicKey::verify (code that
used to compile only on Windows), and malformed CNG signatures erroring
rather than panicking.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Sign: smart cards and tokens in the Windows store ask for their PIN (#694)
Signing with a Windows store identity whose key lives on a smart card or
USB token failed with NTE_SILENT_CONTEXT (0x80090022) and no PIN dialog.
`identities()` acquires each key with CRYPT_ACQUIRE_SILENT_FLAG so that
listing never prompts, and signing reused that handle after
`set_silent(false)`. That only drops NCRYPT_SILENT_FLAG from
NCryptSignHash: a provider handle that was opened silently stays silent,
so a card that needs its PIN refuses instead of asking.
`WindowsKey` now keeps the certificate context and acquires a fresh,
non-silent key handle when it signs, so the provider can show its own
dialog. Listing is unchanged and still silent.
Reproduced and checked by hand with a qualified certificate on a SafeNet
token (SafeNet Smart Card Key Storage Provider, RSA-2048): 0.5.0 fails
with 80090022, this build shows the SafeNet PIN dialog and signs. The
software-key round trip (`signing_with_windows_store_identities`,
--ignored) still passes on Windows 11.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Sign: a Windows store identity signs with its issuers
A digital ID file brings its certificate chain and the signature embeds
it; a Windows store identity signed with its own certificate only. A
certificate issued by an intermediate CA (the usual case on a token)
then validates only where the reader already has that CA.
`windows::find`, which fetches the identity to sign with, now fills
`chain` with the certificates Windows chains it to, without the root.
`identities()` still builds no chains, so listing stays fast and local.
A chain that can't be built leaves `chain` empty, as before.
Test `a_windows_store_identity_signs_with_its_issuers` (--ignored, like
the other store test): a temporary root, issuer and signer; the
signature validates against the root alone. The cleanup guard now also
removes the public copy New-SelfSignedCertificate leaves in Intermediate
Certification Authorities, which the existing test left behind.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: James Locke <336218001+jcl-bit@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: mmmaarian03-crypto <253881360+mmmaarian03-crypto@users.noreply.github.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
#646 fixed the Windows build after #386 with `_` arms in the two
matches in windows.rs. That module is cfg(windows), so Linux and macOS
CI never compile it, and the next PublicKey variant will either break
the Windows build again or, now, fall into `_` without anyone choosing.
The store's two decisions move into keys.rs, which every platform
builds, with every variant named and no `_` arm:
- PublicKey::store_signing_key: RSA, or ECDSA with 256/384 bits, or
None for the kinds PdfCraft only verifies with (P-521, brainpool,
Ed25519, Unsupported).
- PublicKey::store_signature_der: CNG's raw r||s as DER (RSA as is);
the verify-only kinds return SignError::Unsupported, as since #646.
windows.rs calls both, with no `_` arms left. Behaviour is unchanged.
tests/store_keys.rs runs everywhere: every variant's answer (with an
exhaustive match, so a new variant must be added to it), the P-256 and
P-384 conversion round-tripped through PublicKey::verify (code that
used to compile only on Windows), and malformed CNG signatures erroring
rather than panicking.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Fix non-exhaustive match in Windows signing path
The PublicKey enum gained P521, BrainpoolP256, BrainpoolP384, BrainpoolP512, and Ed25519 variants, but the Windows-specific match statements in windows.rs were not updated, causing a compile error on Windows builds.
Add wildcard arms that return a clean error for unsupported key types.
* Windows store: a key type it can't sign with is Unsupported, not a crypto failure
---------
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* M9: more signature validation algorithms
Validation now reads what real signers write, and says when it is weak:
- Digests SHA-224, SHA-512/224, SHA-512/256, SHA3-224/256/384/512 and
RIPEMD-160, beside SHA-1 and SHA-2.
- RSA PKCS#1 v1.5 for every digest, in `rsa_pad`: the one expected encoding
is built and compared byte for byte, with or without the DigestInfo's NULL
(RFC 8017 App. B.1). A signature over the bare digest, which doesn't say
which hash it uses, is refused. The signature value must be below the
modulus (RFC 8017 §5.2.2); s and s + n both verified before.
- RSA-PSS with the hash, MGF1 hash and salt length the signature declares.
- ECDSA as DER, non-minimal DER or raw r||s on P-256, P-384, P-521 and
brainpoolP256r1/P384r1/P512r1 (BSI "plain" ECDSA OIDs too); brainpoolP512r1
is hand-written on crypto-bigint because no RustCrypto crate has it.
- Ed25519 (RFC 8419), and the legacy adbe.x509.rsa_sha1 format.
- An algorithm PdfCraft can't check is Unknown, never Invalid.
- SHA-1 and RIPEMD-160 signatures validate, but the signature's details say
the algorithm is weak (wording pinned by tests).
- Encoding irregularities that were tolerated are listed in the details
(`verify_noting`; `verify` keeps its signature).
Found while testing, each with a regression test that failed before the fix:
a brainpoolP512r1 public key with a coordinate >= p panicked inside
crypto-bigint's `sub_mod` (the certificate comes from the PDF); it is refused
now, and the point at infinity is an invalid signature, not an error.
Vectors were made with OpenSSL (tests/data/README.md has the commands).
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Update comment to clarify MAC digest restrictions
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* M9: a legacy x509.rsa_sha1 signature whose key the verifier rejects is Invalid; only unsupported keys are "can't check yet"
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* M9: read BER signatures; later changes are classified narrowly
Real-world signatures (DocuSign, Telekom QES, Documenso) are BER: indefinite
lengths and segmented OCTET STRINGs, which the strict DER reader turned away
("DER signature wrong"). Behind that, later revisions that add DSS data or
rewrite the XMP were classified as tampering.
- cms: the CMS structure is read with `Tlv::parse_ber` (the reader #453 added
for PKCS#12); certificates and signed attributes are still verified over
their own exact bytes, signed attributes with an indefinite length are
re-encoded as DER first (RFC 5652 §5.4), and the details say the signature
was BER. High tag numbers are not read.
- pdf: validation data added after signing is a permitted change, but only
objects reached through /DSS /Certs|CRLs|OCSPs|VRI by the keys the standard
defines, with the shape of their role, and new or only grown since signing.
A /DSS entry naming other objects (a page's contents) excuses nothing.
- pdf: only the signed catalog's /Metadata is the document's XMP. A
/Type /Metadata or /Type /DSS label on any other dictionary or stream, even
one it already had when signed (a page's Form XObject), makes nothing
permitted. Negative tests at every DocMDP level.
Six of the new tests fail on the previous code: the BER signature, nested
segments, the store-growth rules, and a dictionary or stream carrying a
/Type /Metadata or /Type /DSS label. The last one let a drawn Form XObject be
rewritten under a Valid signature.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* M9: comparing a grown document security store is linear for references and bounded otherwise
only_grew compared arrays element by element, so a crafted /Certs of ~100k entries could hang
validation. Reference arrays are compared as sets; other arrays only up to 10,000 elements.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* M9: validate a document timestamp that sits in a signature field
Documenso (and others) store the document timestamp as an AcroForm signature
field (`Timestamp_1`) whose /V is a /Type /DocTimeStamp dictionary. Field
values only went through the signature validator, which read the RFC 3161
token as a CMS signature, compared its TSTInfo with the document digest and
reported "altered or corrupted since the signature was applied" for an
untouched file.
- A field value with /SubFilter /ETSI.RFC3161 is validated as a timestamp.
- Standalone timestamps are found with /Type /DocTimeStamp (ISO 32000-2
12.8.5) as well as the /Type /Sig older writers used; our own
timestamp_document now writes /DocTimeStamp. The discovery cache (#419)
selects its candidates with the same test, so it sees both.
- The discovery test that lists a signature field holding a timestamp used to
assert `doc_timestamp == false`, which is the bug above; it asserts true now.
What that test is about (the field is listed once, not also as a standalone
timestamp) is unchanged.
Regression tests build the same structure with a test TSA; no third-party
file is needed, and they fail without the fix.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* M9: a trusted TSA whose certificate wasn't valid when it stamped leaves a document timestamp Unknown, never Valid
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* M9: chain building checks CA constraints, key usage, path length and validity
build_chain linked certificates by name and signature only. An issuer must
also be allowed to issue: basicConstraints CA:TRUE (an old v1 self-signed
root without constraints still anchors), keyCertSign when there is a key
usage, a pathLenConstraint that allows the CAs below it, and validity at the
signing time (or the trusted timestamp / token time) when it is known.
Without this, an ordinary end-entity certificate of a trusted CA, embedded in
a PDF, could "issue" a certificate for any identity and chain to the trusted
root. The signature details now say why an issuer was refused.
Tests issue certificates in-process and cover each refusal, plus a signed PDF
whose signer chains through an end-entity certificate (Unknown, not Valid).
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LXAstazhuAFyakty2m93Af
* M9: unreadable keyUsage, pathLen or basicConstraints fail closed; only v1/v2 self-signed certificates count as old roots
- a present keyUsage that doesn't parse allows no usage (it was unrestricted)
- a present pathLenConstraint that doesn't parse allows no CA below (it was unlimited)
- basicConstraints counts as present before it is parsed, so a garbled one can't make a
certificate look like an old root
- the self-signed-without-basicConstraints exception applies to v1/v2 certificates only
- restores the load_certificates doc comment
Tests build v1 certificates when they have no extensions, as real old roots are.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* M9: clippy: slice from a reference in the chain test
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* M14: bound large-PDF memory use (#307)
Inspect large documents lazily, share parser/resource metadata, bound full-save
and raster retention, and cache signature candidate discovery safely.
Preserve upstream rendering deduplication, pixel alignment, signature previews,
and organizer insertion behavior, with regression coverage for their interaction.
Validated with 1,336 workspace tests, 193 parser tests, strict workspace Clippy,
30 WASM crate checks, 1x/2x GUI protocols, and same-PDF workflow comparisons.
* cos: drop the writer cache-policy probe and its test-only hooks in production paths
* cos: the temporary reader keeps parsed objects until a count or owned-bytes budget
Since #552 a stream read from the file is a view into the input, so clearing the whole parse
cache after every read saved little memory and cost most of the full-save slowdown (every
object parsed twice, indirect /Length objects re-parsed per stream). Clear only past
OBJECTS entries or STREAM_BYTES of data of the cache's own (decrypted streams, strings).
* cos: the writers refuse a document opened with a stream limit (read-only inspection)
* cos: a full save fails rather than writing null when an object reads differently the second time
* render: parsing is not timed by the watchdog; timing tests with wide margins
A slow first parse (a huge or damaged file) made the whole pool fail every page for its
lifetime. Parsing, shared or private, is now its own untimed stage, as on main before the
shared parser; rendering is timed from when parsing ends. The init-timeout tests become one
deterministic test (a 2 s parse against a 10 ms limit, shared and private). Watchdog tests
use limits and injected delays ~10x apart instead of 25-50 ms against real renders. Also:
saturating retired-worker count, main's stop-flag test runs on private parsers (the first
shared timeout is a private retry), set_queue documents that unlisted results are dropped,
and retire() documents the permanent per-worker-parser fallback.
* render: page numbers in the lazy page tree use checked conversion
* render: the lazy inspector is compared with lopdf on named destinations and object streams too
* ui: on-screen pages always render; pages turned back to stay cached; stable thumbnail tags
- Visible pages and tiles are always admitted and uploaded (the viewport bounds them); the
byte and count limits decide only how much prefetch fits. A HiDPI two-up view or a 5K
viewport left pages on 'Rendering...' for good.
- Pages no longer demanded stay cached, nearest the current page first, while the 128 MiB
allowance and the 24-page count have room: paging back no longer re-renders.
- Thumbnail density follows the demand count rounded up to a power of two, so rows scrolling
in and out of an organize grid don't change every thumbnail's tag and re-render it.
- A suspended (background) tab drains its pool's finished results instead of holding them.
- Organize drag-and-drop ends on the primary button only.
- Tests: the stale-result test uses valid pixels and checks nothing was uploaded; the
organizer wheel test runs 40 steps; regressions for the first three fixes.
* vendor: mark the hayro-syntax lock and SegmentList patches and list them as (8) and (9); clippy 1.99 as_chunks in a raster test
* render: clippy 1.99 — contains over iter().any() in a raster test
---------
Co-authored-by: Brandon Thomas <echelon@gmail.com>
Importing a digital ID exported by Windows failed with "PKCS #12: not a
PKCS #12 file" — at the second byte of the file, before the password was
looked at. Windows writes a .p12 in BER: the PFX, its ContentInfo and
the [0] around the AuthenticatedSafe all use the indefinite length form
(0x80 … 00 00), and the AuthenticatedSafe itself is an OCTET STRING
split into segments. der.rs took definite lengths only, so every one of
those files was turned away. OpenSSL writes definite DER, which is why
the fixtures never showed it.
A Tlv now carries the rules it was read with, and its children are read
the same way: Tlv::parse is the strict DER reader it always was,
Tlv::parse_ber also takes the indefinite form, and Tlv::octets joins the
segments of a constructed OCTET STRING, borrowing when there is nothing
to join. Both are depth-bounded. pkcs12 reads the envelope with the BER
reader; x509 and cms keep the strict one, so nothing that is verified
over its own bytes changes.
The MAC decides what is allowed here: it covers the contents of the
authSafe OCTET STRING, the segments joined, which is what the writer
MACed. So the file is never normalised to DER — that would change the
octets the MAC was computed over and turn a right password into a wrong
one.
The test builds the Windows shape out of the OpenSSL fixtures, twice:
the outer wrappers in BER with the MacData intact, which is what proves
the MAC is taken over the right octets, and then the AuthenticatedSafe
re-encoded as well, with the MacData dropped (RFC 7292 §4 makes it
optional), for a file that is BER the whole way down.
Claude-Session: https://claude.ai/code/session_013Q5dhMC58jk1ePNW37xe1b
Co-authored-by: Fernando Areán <soporte@codebit.es>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
List Current User Personal CNG identities alongside file digital IDs and sign
without exporting their private keys through safe rustls-cng wrappers.
Expose Windows store references through automation and the desktop dialogs,
with RSA and ECDSA validation, certificate cleanup, and UI regression coverage.
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
pkcs12::open demanded clean DER at the first byte, so a file with one
extra newline, PEM armour or a bare base64 body (the shapes OpenSSL
wraps, editors and government portals emit) was refused before any
crypto ran, with "malformed data: PKCS #12: not a PKCS #12 file" and no
reason.
open now runs the bytes through normalize(): ASCII whitespace is
trimmed, "-----BEGIN" takes the base64 body between the armour markers
(byte offsets, so a marker glued to the body line works too), and a
bare base64 body is decoded — a real DER PFX always contains bytes
outside the base64 alphabet, so the fast path can't swallow one. The
exact parse reason is carried into the error instead of being dropped.
Truncated or empty files still fail, now saying why.
Test: crypto.rs::opens_wrapped_pkcs12_files_and_still_rejects_broken_ones
(a wrapped copy of rsa-aes.p12 yields the same certificate through
trailing whitespace, PEM armour and bare base64; truncated and empty
files error with the reason). It failed on all three wrapped forms
before the fix.
Co-authored-by: Mawfyy <mawfy12@gmail.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* Signatures: RFC 3161 timestamp tokens (PAdES B-T) behind a transport-free TSA interface
* Signatures: document timestamps, DSS/VRI evidence embedding, trusted verification time
* Signatures: revocation evidence verification (CRL and OCSP) wired into validation
* Signatures: real-world certificate compatibility (CRLDP, tolerant extensions) and XFA-aware DocMDP classification
* Signatures: RFC 6960 encodings, delegated-responder verification, TSA trust anchoring, try_oid overflow
* Signatures: harden PR #69 validation (XFA, metadata, revocation, TSA trust, token digest)
- Remove the XFA "form fill" reclassification: it read the new revision, so
an update could add /XFA + /NeedsRendering and replace the page tree while
approval and P=2/3 certification signatures stayed Valid. Classification
(including catalog /Extensions) is back to main's.
- A changed stream tagged /Type /Metadata counts as metadata only when it is
the signed catalog's /Metadata stream or was already metadata when signed;
a relabelled page Form XObject is "other changes".
- A verified revocation stays Invalid when the certificate was also outside
its validity at signing time (was softened to Unknown).
- An embedded timestamp whose TSA does not chain to the trust store is
reported as an unverified timestamp and no longer sets the validity or
revocation time; the signer's claimed time is used, as on main.
- parse_token checks the TSTInfo messageDigest with the SignerInfo digest
algorithm, not the imprint's.
Each fix has a regression test in crates/sign/tests/pdf.rs that fails on
the PR head.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Brandon Thomas <echelon@gmail.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The app, crates, binaries, bundle id, packaging, icons, screenshots and docs are now
PdfCraft / pdfcraft (repo storytold/pdfcraft). On first launch the desktop app moves the
PrintCraft settings and crash-recovery folders to the new name, and both apps read settings
saved under the old storage key, so upgrades keep recent files, preferences and unsaved work.
The signing test fixtures keep their PrintCraft subject names (they are binary).
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
PKCS #12 HMAC errors now propagate as `SignError`. Key-bag lookup uses `find_map` and chain
building uses `let … else`. `der::oid` (only ever given this crate's OID literals) keeps the
standard's narrow, documented `expect` exception. The crate now denies the panic lints.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Stable clippy 1.99 denies chunks_exact/chunks_exact_mut with a constant
size (32 sites), which failed the test job on main and every open PR.
Behaviour unchanged; MSRV 1.90 has as_chunks.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
