KB-3984

Packet Tree Pin Policy

3 min read Revision 1
<!-- DOC_STATUS: ACTIVE_NON_AUTHORITY -->

Checker Policy — Packet Tree Pin (L0/L1)

Generalizes: v0.2 packet_tree.sha256 = sha256(HASH_MANIFEST.txt) (single tree-pin) and the tamper class (manifest tamper → breaks pin → reconstruct fails closed). Level: 0 (integrity) and 1 (reconstruction).

The rule

A packet has exactly one tree pin: packet_tree.sha256 contains sha256(HASH_MANIFEST.txt) and nothing else. Because HASH_MANIFEST.txt contains a hash for every governed file, any byte change to any governed file changes a manifest line, which changes sha256(HASH_MANIFEST.txt), which breaks the pin. The pin is therefore a single value that certifies the whole tree.

Determinism requirements for the pin to be reproducible

  1. Stable manifest order. Generate lines in a deterministic order (lexical sort of relpaths). Do not depend on filesystem walk order.
  2. Stable path normalization. Strip the leading ./ so paths are dir/file, not ./dir/file. Pick one form and keep it.
  3. No volatile content in governed files. Governed files must not embed wall-clock timestamps, random ids, or absolute temp paths that change between build and reconstruction. Use the fixed macro date only.
  4. Trailing-newline discipline. Decide whether files carry a trailing newline and apply it consistently; a store that normalizes newlines must be verified to round-trip byte-exact (run the forward check after reconstruction).

Procedure

# build
( for f in $(find . -type f ! -name HASH_MANIFEST.txt ! -name packet_tree.sha256 | sort); \
    do shasum -a 256 "$f"; done ) | sed 's# \./# #' > HASH_MANIFEST.txt
shasum -a 256 HASH_MANIFEST.txt | awk '{print $1}' > packet_tree.sha256

# verify (any byte drift anywhere → mismatch)
test "$(shasum -a 256 HASH_MANIFEST.txt | awk '{print $1}')" = "$(cat packet_tree.sha256)"

Tamper behavior (must hold)

  • Mutate one byte of any governed file → manifest line changes → pin mismatch → FAIL.
  • Mutate the manifest text → pin mismatch → FAIL.
  • Mutate packet_tree.sha256 → pin mismatch → FAIL.
  • A reconstruction whose pin does not match the published pin is not the same packet; treat as FAIL and do not proceed to higher levels.

Cross-store reconstruction

When the packet is republished to a content store (e.g. KB) and fetched back into a clean dir, recompute the pin from the fetched manifest and assert it equals the published packet_tree.sha256. This is the L1 byte-exact round-trip proof.

Back to Knowledge Hub knowledge/dev/laws/tool-kiem-thu/base/tkt-base-structural-evidence-governance-pack-2026-06-11/checkers/packet_tree_policy.md