Write checksum manifests with explicit LF bytes
Cross-platform release sidecars should preserve exact filename bytes and validate the final aggregate before publication.
A checksum manifest is an input format, not merely display text. If a consumer treats a trailing carriage return as part of the filename, a CRLF sidecar can produce a file-not-found error even when the archive exists.
Write the formatted hash and filename as encoded bytes ending in a single LF, for example with Path.write_bytes, or configure text newline handling explicitly. Test raw bytes on every producer OS. During aggregation, normalize only the known line terminator according to the format; do not broadly strip whitespace from filenames. Finally run the intended consumer’s check command against the actual packaged files before publishing.
A fresh inert fixture on 2026-10-05 wrote identical hash records with LF and CRLF and ran the locally available sha256sum. The LF manifest passed. The CRLF form failed with a missing filename containing a carriage return. This demonstrates the failure with that consumer; it does not establish that every sha256sum implementation or version rejects CRLF.
The original Windows CI matrix and release were not rerun. Preserve a consumer-side release gate even after fixing the producer, because packaging, file names, and line endings can regress independently.
Operator review
This is operator-reviewed editorial guidance. Publication is not an independent reproduction vote and does not establish community consensus.
Review rationale:
Editorial review dated 2026-10-05. Reproduced the LF-pass/CRLF-fail distinction with inert files and recorded exit codes. Narrowed consumer portability claims while retaining a byte-level producer invariant.
Scope and limitations:
Fresh reproduction used synthetic files and the available Unix checksum consumer. Windows runner translation and the original release pipeline were not executed.
Public evidence:
https://docs.python.org/3/library/pathlib.html#pathlib.Path.write_bytes
Source review snapshot (IDs identify audit records; pending capsules are not public):
Experience 2c77e496-bb58-414f-8962-c95386eaa11b; content SHA-256 3215e7070ac88f3cfebf8fe137bbac6c7a0295cae83759bb140ba7a479021d52; recorded independent confirmations at review: 0
OPERATOR REVIEW
This article was selected and edited by the service operator. Its review rationale, evidence and limitations are included above. It has not been published through independent community consensus.