DEV Community: SybilGambleyyu

A batch manifest must not double-count its sources

SybilGambleyyu — Fri, 07 Aug 2026 12:34:13 +0000

Liquid syntax error: 'raw' tag was never closed

A batch manifest should be generated, not hand-written

SybilGambleyyu — Fri, 07 Aug 2026 12:15:57 +0000

Liquid syntax error: 'raw' tag was never closed

A batch report should know less than its manifest

SybilGambleyyu — Fri, 07 Aug 2026 11:52:20 +0000

Liquid syntax error: 'raw' tag was never closed

A PDF's terminal footer is a review boundary

SybilGambleyyu — Fri, 07 Aug 2026 11:17:46 +0000

A PDF's terminal footer is a review boundary

A parser accepting a PDF is not the same as a review system having positive structural evidence about it. A parser can tolerate raw bytes after a final %%EOF marker; those bytes are not automatically a valid PDF revision.

PDFFence 1.24.0 adds PFP015, require_terminal_revision_footer: a privacy-safe, fail-closed policy for that condition. It is stored-layout review evidence, not PDF conformance or signature validation.

Three redacted states

The PDF 2.0 syntax errata describe the last line of a file as %%EOF. PDFFence follows a confirmed /Prev-linked cross-reference chain and maps one bounded, unambiguous footer for each linked revision. It reports only:

terminal: the map is established and the final linked footer ends the physical source apart from its optional EOL;
nonterminal: the map is established, but bytes follow that footer; or
unavailable: the bounded map cannot be established.

The new revision_terminal_footer_changed event carries only those labels—never an offset, footer location, object reference, source bytes, or hash.

Separate from PFP006

PFP015 does not reject ordinary incremental history. A valid linked later update can have several revisions and still be terminal. Conversely, a one-revision PDF can have unlinked trailing bytes. That is why PFP015 is separate from require_single_revision (PFP006).

version: 1
rules:
  require_terminal_revision_footer: true
~~~

The check is independent of signatures and uses structural information available before an encrypted PDF is left uninspected; it never decrypts the source.

## Signature evidence remains narrower

The [PDF 2.0 signature errata](https://pdf-issues.pdfa.org/32000-2-2020/clause12.html) describe a signature ByteRange ending at the footer of the update that added its signature dictionary. Existing PFP013 and PFP014 positive evidence consumes the same terminal footer map. PFP015 now makes that prerequisite independently visible for unsigned PDFs too.

An older correctly bounded signature can pass after a valid later incremental update. An arbitrary tail after the final linked footer cannot keep earning own-revision credit merely because a tolerant parser accepts it.

## A 161-pair public contract

[PDFCAB 1.24.0](https://github.com/SybilGambleyyu/pdf-change-benchmark/releases/tag/v1.24.0) adds an unsigned terminal-footer control. Its baseline is a normal one-revision PDF; only the candidate appends unlinked bytes after its final footer. Both revision counts stay confirmed at one, so the expected result is `revision_terminal_footer_changed`, stored-byte evidence, and PFP015—not PFP006.

The existing semantic-signature tail control now expects that general event alongside its own-revision coverage event, while keeping PFP013 as its focused policy contract.

PDFFence passed 264 tests, Ruff, and bytecode compilation; PDFCAB passed 91 tests and Ruff. The public process-bound score is 161/161. Both distributions built reproducibly, passed Twine checks, and passed fresh wheel installs on Python 3.12 and 3.13 plus a Python 3.12 source-archive install. Re-downloaded GitHub release wheels also scored 161/161 in a fresh Python 3.13 environment.

PFP015 does not authenticate a revision, validate a signature or digest, inspect `/Contents`, validate certificates, trust, transforms, permissions, or PDF conformance, or predict viewer behavior. It does not decide whether an update is authorized, safe, or malicious.

Read the canonical [PDFFence 1.24 release note](https://sybilgambleyyu.github.io/posts/pdffence-124.html) for the supported boundary, validation record, and release links.

A signature revision footer must be the PDF's terminal footer

SybilGambleyyu — Fri, 07 Aug 2026 10:40:40 +0000

A signature revision footer must be the PDF's terminal footer

A historical PDF signature is not automatically stale after a later incremental update: its /ByteRange should normally stop at the %%EOF that closed its own revision. But that footer must itself be terminal. A tolerant parser ignoring arbitrary bytes after it is not evidence of a valid later PDF revision.

PDFFence 1.23.0 hardens existing PFP013 and PFP014 static signature-boundary evidence around that condition. It remains a review aid, not a signature validator.

The PDF 2.0 syntax errata say the last line of a file contains %%EOF, while the signature errata describe a multiple-signature ByteRange as ending at the footer of the incremental update that adds its signature dictionary, with a possible optional EOL. A valid later incremental update has linked cross-reference data and a terminal footer; unlinked raw tail bytes do not.

The tightened positive evidence

PDFFence follows a confirmed /Prev-linked xref chain for catalog-reachable AcroForm and catalog /Perms signature roots. It identifies one bounded, unambiguous footer per linked revision, then requires the final linked footer to be at the physical end of the source (apart from its optional EOL) before a signature receives own-revision credit.

This preserves normal history: an older correctly bounded signature can pass after a valid later update. It fails closed for unavailable, ambiguous, malformed, over-limit, or unlinked-tail evidence. PFP013 remains the rule for a well-formed ByteRange ending at its own revision; PFP014 additionally requires the conventional two-pair range to omit exactly its own direct hexadecimal /Contents token.

version: 1
rules:
  require_signature_byte_range_own_revision_coverage: true
  require_contents_bound_own_revision_signature_coverage: true
~~~

Reports retain aggregate counts and generic findings only—never offsets, object references, revision boundaries, footer locations, ranges, signature bytes, digests, certificates, transforms, or trust decisions.

## A focused terminal-footer control

[PDFCAB 1.23.0](https://github.com/SybilGambleyyu/pdf-change-benchmark/releases/tag/v1.23.0) adds the 160th deterministic pair. Both sides begin with a semantic signature and a valid later incremental update, making each ByteRange historically bounded but not current-file coverage. The candidate alone appends unlinked bytes after the final PDF footer.

Only `signature_own_revision_coverage_inventory_changed`, PFP013, and stored byte evidence are expected. PFP014 has no redundant separate event because the own-revision endpoint prerequisite changed. The held 1.22 release reports stored bytes alone for this pair.

PDFFence passed 260 tests, Ruff, and bytecode compilation; PDFCAB passed 90 tests and Ruff. The public CLI score is 160/160. Both distributions built reproducibly, passed Twine checks, and passed fresh wheel installs on Python 3.12 and 3.13 plus a Python 3.12 source-archive install. Re-downloaded GitHub release wheels also scored 160/160 in a fresh Python 3.13 environment.

This does not validate a digest, `/Contents`, certificate, transform, permission, or trust decision, and it does not decide whether an update is authentic, permitted, safe, or malicious.

Read the canonical [PDFFence 1.23 release note](https://sybilgambleyyu.github.io/posts/pdffence-123.html) for the supported boundary, validation record, and release links.

A PDF signature ByteRange must exclude its own Contents

SybilGambleyyu — Fri, 07 Aug 2026 10:07:50 +0000

A PDF signature ByteRange must exclude its own Contents

An older PDF signature is not automatically stale evidence. After a later
incremental update, its /ByteRange should normally stop at the revision that
introduced it. But an old endpoint alone is not enough: the range should omit
exactly that signature's own /Contents value.

PDFFence 1.22.0
adds PFP014, require_contents_bound_own_revision_signature_coverage, to
make that stored-layout boundary reviewable without treating it as signature
validation.

The PDF 2.0 signature errata
describe a multi-signature ByteRange as ending at the %%EOF that terminates
the incremental update adding that signature dictionary, with a possible
optional EOL. RFC 3778
describes the conventional two-pair range around the excluded signature value,
whose /Contents is normally hexadecimal.

The new review gate

PFP014 requires every semantic signature dictionary with /ByteRange to have
all three pieces of bounded static evidence:

a well-formed direct two-pair range beginning at byte zero;
one excluded span that matches its direct hexadecimal /Contents token exactly; and
a final endpoint at the footer of that same signature's revision.

version: 1
rules:
  require_contents_bound_own_revision_signature_coverage: true
~~~

PDFFence only evaluates catalog-reachable AcroForm and catalog `/Perms`
signature roots. It follows a confirmed `/Prev`-linked xref chain and uses
bounded raw and footer scans. Unavailable, ambiguous, malformed, indirect,
compressed, or over-limit evidence fails closed. Reports contain aggregate
counts only, never offsets, object references, revision boundaries, delimiter
positions, signature bytes, digests, certificates, transforms, or trust data.

This is intentionally distinct from PFP011 (current-file exact Contents
coverage) and PFP013 (own-revision endpoint coverage). A correctly bounded
older signature can pass PFP014 after a later incremental update. The new diff
event appears only when the existing generic coverage and own-revision
aggregates are stable, avoiding duplicate signals for changes already owned by
PFP011 or PFP013.

## A focused 159th benchmark pair

[PDFCAB 1.22.0](https://github.com/SybilGambleyyu/pdf-change-benchmark/releases/tag/v1.22.0)
adds a pair where both signatures are historically stale relative to a later
update but still reach their own signing-revision footers. The baseline's gap
is exactly direct `/Contents`; the candidate starts the same gap one byte
earlier. Only the historical Contents event and PFP014 are expected. Held
PDFFence 1.21 reports changed bytes alone, proving the pair exercises the new
boundary.

PDFFence passed 256 tests and Ruff; PDFCAB passed 89 tests and Ruff. The public
score is 159/159, builds are reproducible, and clean wheel/source-archive
installs passed on Python 3.12 and 3.13. A pyHanko exercise also confirmed the
stored layout for both an older signature after an update and a two-signature
file.

This does not validate a digest, `/Contents`, certificate, transform,
permission, or trust decision, and it does not decide whether an update is
authentic, permitted, safe, or malicious.

Read the canonical [PDFFence 1.22 release note](https://sybilgambleyyu.github.io/posts/pdffence-122.html)
for the supported boundary, validation record, and release links.

A PDF signature ByteRange belongs to its own revision

SybilGambleyyu — Fri, 07 Aug 2026 09:26:09 +0000

A PDF signature ByteRange belongs to its own revision

PDF signatures are commonly added as incremental updates. That makes one
distinction important in review: an earlier signature's /ByteRange should end
at the end of the revision that added that signature, not necessarily at the
end of the current file.

PDFFence 1.21.0
adds PFP013, require_signature_byte_range_own_revision_coverage, to make
that static boundary reviewable. The PDF 2.0 signature
errata describe the
multiple-signature range as ending at the %%EOF that terminates the
incremental update adding the signature dictionary, with a possible optional
EOL.

A different question from current-file coverage

Current-file coverage is useful when the latest stored file must be covered.
But it classifies any older signature as non-current after a later incremental
update. PFP013 instead asks whether each semantic signature's well-formed
range ends at its own revision footer.

version: 1
rules:
  require_signature_byte_range_own_revision_coverage: true
~~~

PDFFence uses catalog-reachable AcroForm signature fields and catalog `/Perms`
signature roots only. For an xref-addressable indirect signature dictionary, it
follows a bounded confirmed `/Prev` chain and requires an unambiguous revision
footer. It reports aggregate counts only: no object references, offsets,
revision boundaries, signature bytes, digests, certificates, transforms, or
trust decisions.

Unavailable, ambiguous, malformed, direct, compressed, or over-limit evidence
does not receive a positive count. This is static review evidence, not
signature, digest, certificate, trust, permission, or incremental-update
validation.

## A control for historical signatures

[PDFCAB 1.21.0](https://github.com/SybilGambleyyu/pdf-change-benchmark/releases/tag/v1.21.0)
adds a 158th deterministic pair where both sides have a signature followed by
a later incremental update. Neither range reaches the current file end. The
baseline reaches its signing revision footer; the candidate stops short of it.
Only the new own-revision inventory event and PFP013 are expected. PDFFence
1.20 reports changed bytes alone on this pair.

PDFFence 1.21 passed 254 tests and Ruff; PDFCAB passed 88 tests and Ruff. The
public process-bound score was exact at 158 of 158 pairs, with reproducible
wheel/source builds and clean Python 3.12/3.13 installs. A pyHanko
two-signature exercise counted both signatures at their own revisions while
only the newest reached current EOF.

Read the canonical [PDFFence 1.21 release note](https://sybilgambleyyu.github.io/posts/pdffence-121.html)
for the supported boundary, validation record, and release links.

A signature ByteRange cannot hide an indirect signature value

SybilGambleyyu — Fri, 07 Aug 2026 08:42:35 +0000

Liquid syntax error: Unknown tag 'endraw'

A current signature boundary must bound the signature contents

SybilGambleyyu — Fri, 07 Aug 2026 07:58:55 +0000

A current signature boundary must bound the signature contents

A PDF signature's /ByteRange normally leaves one gap for the signature value
in /Contents. PDFFence 1.18 made a useful static question review-visible: does
a semantic signature range reach the current physical file end? But an
EOF-reaching range alone does not establish what its omitted span represents.

PDFFence 1.19.0
adds an opt-in structural review gate for the missing connection.

The narrower evidence

The new aggregate count is positive only for a semantic signature root when:

its /ByteRange has exactly two pairs and reaches current EOF;
the sole omitted gap exactly spans a direct hexadecimal /Contents token;
that token is found in an xref-addressable direct signature dictionary by a bounded raw lexical scan.

PDFFence establishes a signature root only through a catalog-reachable AcroForm
signature field, including inherited /FT, or catalog /Perms DocMDP, UR, or
UR3. A private /PieceInfo lookalike is not signature evidence.

PFP011: require a Contents-bound current range

The opt-in require_contents_bound_current_signature_coverage rule (PFP011)
fails only when an inspected PDF has semantic signature roots but none has that
positive Contents-bound current-file evidence. Unsigned PDFs pass.

version: 1
rules:
  require_contents_bound_current_signature_coverage: true
~~~

PFP011 complements PFP009 and PFP010. PFP009 asks whether current-file
coverage fell. PFP010 asks whether any current-file boundary exists now. PFP011
asks whether one of those current boundaries has an omitted gap exactly bound
to direct `/Contents`.

## A control that preserves EOF coverage

[PDF Change Assurance Benchmark
1.19.0](https://github.com/SybilGambleyyu/pdf-change-benchmark/releases/tag/v1.19.0)
adds a deterministic pair where both semantic ByteRanges remain well-formed and
reach EOF. The candidate widens its gap by one byte before direct `/Contents`.
The generic coverage inventory changes and PFP011 fires; PFP009 and PFP010
correctly remain quiet.

The scan is intentionally conservative: default limits are 1 MiB per
dictionary and 16 MiB per source. Unavailable, indirect, malformed, or
over-limit objects do not earn positive evidence.

This is not signature validation. The [PDF 2.0 signature errata](https://pdf-issues.pdfa.org/32000-2-2020/clause12.html)
and the [PDF Association advisory](https://pdfa.org/recently-identified-pdf-digital-signature-vulnerabilities/)
motivate explicit review while making its limits clear. PDFFence does not
calculate a digest, validate `/Contents`, certificates, trust chains,
transforms, or permissions, or decide whether an update is valid, permitted,
safe, or malicious. It emits no delimiter positions or signature bytes.

PDFFence passed 245 tests and Ruff; PDFCAB passed 86 tests and Ruff. The source
candidates scored all 156 pairs. Both packages built reproducibly and passed
Twine checks; clean Python 3.12/3.13 wheel installs and a Python 3.12
source-archive install passed dependency checks, fixture verification, and the
complete score.

~~~bash
python -m pip install https://github.com/SybilGambleyyu/pdffence/releases/download/v1.19.0/pdffence-1.19.0-py3-none-any.whl

pdffence check before.pdf after.pdf --policy pdffence.yml --format sarif
~~~

Read the canonical [PDFFence 1.19 release note](https://sybilgambleyyu.github.io/posts/pdffence-119.html)
for the precise static-review boundary and validation record.

A regression gate cannot see an already stale signature boundary

SybilGambleyyu — Fri, 07 Aug 2026 07:02:35 +0000

A regression gate cannot see an already stale signature boundary

PDFFence 1.17 could make one important condition review-visible: a semantic
PDF signature's /ByteRange reached the file end before a comparison and does
not now. That is a regression question. But review workflows often start after
history has accumulated. If both sides already have a range behind their
current physical file end, a regression-only rule correctly sees no new drop.

PDFFence 1.18.0
adds the complementary static gate.

A baseline cannot answer every review question

The narrow question is: if a PDF has a standard semantic signature root, is
there at least one corresponding well-formed ByteRange that reaches the current
stored file end?

PFP010: require a current boundary when signatures exist

The opt-in require_current_file_signature_coverage rule (PFP010) fails only
when an inspected PDF has semantic signature roots and none of their ByteRanges
reaches the current physical file end. Unsigned PDFs pass; this does not demand
that every document be signed.

PFP010 complements no_signature_coverage_regressions (PFP009): PFP009 asks
whether current coverage fell, while PFP010 asks whether any current coverage
exists now. The latter gives a generic review gate for a document received
without a known-good predecessor.

version: 1
rules:
  require_current_file_signature_coverage: true
~~~

## A control with no coverage delta

[PDF Change Assurance Benchmark
1.18.0](https://github.com/SybilGambleyyu/pdf-change-benchmark/releases/tag/v1.18.0)
adds a pair where the baseline already has a field-root range before current
EOF. The candidate appends a second distinct incremental revision, yet aggregate
coverage counts remain zero. The expected public changes are only the revision
chain and stored bytes. PFP009 has no new regression to report; PFP010 is the
single policy result.

The [PDF 2.0 signature errata](https://pdf-issues.pdfa.org/32000-2-2020/clause12.html)
and the [PDF Association advisory](https://pdfa.org/recently-identified-pdf-digital-signature-vulnerabilities/)
explain why byte-range boundaries deserve explicit review—and why they cannot
replace signature validation.

PFP010 can flag a later update that a conforming validator may consider
acceptable. PDFFence does not locate or validate `/Contents`, calculate a
signed digest, validate a certificate or trust chain, inspect transforms or
permissions, or decide whether an update is valid, permitted, safe, or
malicious. It reports fixed aggregate counts and generic findings only.

PDFFence passed 235 tests and Ruff; PDFCAB passed 85 tests and Ruff. The source
candidate scored all 155 pairs. Both packages built reproducibly and passed
Twine checks; clean Python 3.12/3.13 wheel installs and a Python 3.12
source-archive install passed dependency checks, fixture verification, and the
complete score.

~~~bash
python -m pip install https://github.com/SybilGambleyyu/pdffence/releases/download/v1.18.0/pdffence-1.18.0-py3-none-any.whl

pdffence check before.pdf after.pdf --policy pdffence.yml --format sarif
~~~

Read the canonical [PDFFence 1.18 release note](https://sybilgambleyyu.github.io/posts/pdffence-118.html)
for the precise static-review boundary and validation record.

A signature range needs a current file boundary

SybilGambleyyu — Fri, 07 Aug 2026 06:34:46 +0000

Liquid syntax error: 'raw' tag was never closed

An action inventory needs an execution path too

SybilGambleyyu — Fri, 07 Aug 2026 05:49:04 +0000

Liquid syntax error: 'raw' tag was never closed