From 453d03d3cd3c7976d8a387fcabe9eae92d81457b Mon Sep 17 00:00:00 2001 From: wshallwshall Date: Wed, 12 Aug 2026 11:06:38 -0500 Subject: [PATCH] backlog: strike two premises in #1171 and #1114 that merged code has falsified Found by the ASVS tracking lane while reconciling PR #310 and PR #325, and routed here rather than edited there because docs/BACKLOG.md is a serialization point. Verified against origin/main before writing, not taken on report. #1171 -- claimed "RFC 6238 HMAC-SHA1 with no SHA-256 or SHA-512 option, and the enrolment URI advertises algorithm=SHA1 (totp.py:170)". Shipped: totp.py:84 is _TOTP_DIGEST = hashlib.sha256, :85 DERIVES _TOTP_ALGORITHM from it precisely so the two cannot be edited apart, and :91 says "SHA-256 since 2026-08-11". Neither cited token exists. RE-SCOPE, NOT A CLOSE: the BLAKE2b limb is untouched and still live. #1114 -- claimed "no message-rate or volume control exists on the data plane in any configuration". A pacer exists and ships OFF; mllp.py:109 calls that a deliberate deviation, ruled 2026-08-11, and NAMES ASVS 2.4.1 -- this item's own cell. The module knew about the item while the item did not know about the module. #1114 STAYS OPEN and its question HARDENS: not "does a control exist" (answered) but "can a control that ships OFF be an honest pass". Closing it on the pacer's existence would answer the easy question and drop the one worth researching. Both originals are STRUCK, not deleted, per the rule that a record of the wrong version is worth more than a clean right answer. TWO THINGS I GOT WRONG DOING THIS, recorded because the second is a real trap: - First attempt replaced the whole LINE carrying #1114's false sentence. That line also carried the item's status glyph, so the item silently declared NO status. The canonical parser caught it; reading by eye would not have. The false sentence was INSIDE the banner, which is exactly where a line-level edit is unsafe. - I was editing on a branch that merged mid-edit. Re-cut from origin/main and re-applied by content anchor rather than by patch, so nothing was carried across from a stale base. --- docs/BACKLOG.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/BACKLOG.md b/docs/BACKLOG.md index 66cfbcaa..e5d0ccb4 100644 --- a/docs/BACKLOG.md +++ b/docs/BACKLOG.md @@ -6025,7 +6025,7 @@ filing. ## 1114. research an honest pass for ASVS 2.4.1 -- anti-automation on a data plane whose senders are machines and whose intake has no authentication -> 🔢 **Filed 2026-08-08 - not started. RESEARCH item: the goal is an HONEST pass, and "cannot honestly reach pass" is a valid finding.** Value **8/10** · Difficulty **7/10**. ASVS **2.4.1** (L2) currently scores **partial**. The pinned verb asks for anti-automation controls against excessive calls leading to exfiltration, garbage data, quota exhaustion, denial of service, or overuse of costly resources. What holds it short is that no message-rate or volume control exists on the data plane in any configuration -- the product says so in its own documentation at `docs/SECURITY.md:1582`. +> 🔢 **Filed 2026-08-08 - not started. RESEARCH item: the goal is an HONEST pass, and "cannot honestly reach pass" is a valid finding.** Value **8/10** · Difficulty **7/10**. ASVS **2.4.1** (L2) currently scores **partial**. The pinned verb asks for anti-automation controls against excessive calls leading to exfiltration, garbage data, quota exhaustion, denial of service, or overuse of costly resources. What holds it short is that ~~no message-rate or volume control exists on the data plane in any configuration~~ **[FALSIFIED 2026-08-12 by `e0e979d5`/`b3b278e6` -- struck, not deleted. A pacer EXISTS and ships OFF by default; `transports/mllp.py:109` calls that *"a DELIBERATE DEVIATION from this module's key-absent-means-secure-default convention, ruled 2026-08-11 (ASVS 2.4.1 / 15.2.2)"* -- naming this very cell, so the module knew about this item while this item did not know about the module. THE ITEM STAYS OPEN AND ITS QUESTION HARDENS:** not *does a control exist* (answered, yes) but **can a control that ships OFF be an honest pass.** The `docs/SECURITY.md:1582` citation below also needs re-pointing -- the sentence it quotes was rewritten when the pacer landed, in the same edit that broke ASVS cell 2.1.3's anchor.]** -- the product says so in its own documentation at `docs/SECURITY.md:1582`. **Cluster:** Security / ASVS remediation research. **Priority:** P1. **Verdict:** research. **Severity:** on a first deployment, any sender able to reach the NIC-bound data plane could submit unbounded messages, each durably persisted before the ACK -- an unbounded store-growth and denial-of-service exposure. MLLP has neither intake authentication nor rate limiting, so there is no actor to charge a budget against. @@ -7009,7 +7009,7 @@ filing. **The pinned verb.** "Verify that only approved hash functions are used for general cryptographic use cases, including digital signatures, HMAC, KDF, and random bit generation. Disallowed hash functions, such as MD5, must not be used for any cryptographic purpose." -**What holds it short today.** The TOTP primitive is RFC 6238 HMAC-SHA1 with no SHA-256 or SHA-512 option, and the enrolment URI advertises `algorithm=SHA1` (`totp.py:170`). The de-identification seed is a keyed BLAKE2b with a 128-bit digest, twinned byte-identically at `tee/anon/keying.py` and formally inventoried at `scripts/security/crypto_inventory_check.py:86`; BLAKE2b is not on the NIST approved list. A third SHA-1 use, `auth/policy.py:150`, is marked `usedforsecurity=False` as the HIBP corpus index. No MD5 implementation exists; the token appears once as a rejected value in a test asserting `config/wiring.py:3885` refuses `ws_password_type='md5'`. +**What holds it short today.** ~~The TOTP primitive is RFC 6238 HMAC-SHA1 with no SHA-256 or SHA-512 option, and the enrolment URI advertises `algorithm=SHA1` (`totp.py:170`).~~ **[FALSIFIED 2026-08-12 by PR #325 (`0ace6bb6`) -- struck, not deleted.** `auth/totp.py:84` is `_TOTP_DIGEST = hashlib.sha256`; `:85` DERIVES `_TOTP_ALGORITHM` from it so the two cannot be edited apart; `:91` reads *"SHA-256 since 2026-08-11, not RFC 4226's SHA-1"*. **Neither cited token exists.** The research question it framed -- *app support is the blocker and nobody has measured it* -- is **MOOT**: it shipped as a hard cutover with the authenticator cost accepted. **This is a RE-SCOPE, not a close: the BLAKE2b limb is untouched and remains the live question, so the SP 800-131A contested-reading paragraph now bears ONLY on BLAKE2b.]** The de-identification seed is a keyed BLAKE2b with a 128-bit digest, twinned byte-identically at `tee/anon/keying.py` and formally inventoried at `scripts/security/crypto_inventory_check.py:86`; BLAKE2b is not on the NIST approved list. A third SHA-1 use, `auth/policy.py:150`, is marked `usedforsecurity=False` as the HIBP corpus index. No MD5 implementation exists; the token appears once as a rejected value in a test asserting `config/wiring.py:3885` refuses `ws_password_type='md5'`. **The research question.** SHA-1 is what makes TOTP universally interoperable, so the unknown is real authenticator-app support for SHA-256 TOTP across the apps a hospital workforce actually uses -- RFC 6238 permits it, app support is the blocker, and nobody has measured it. Separately and independently: is the keyed BLAKE2b doing a cryptographic job this verb reaches, or is it, like the HIBP index, a non-cryptographic use? Settle that before touching it. Third, prior to both: the scorecard records a contested reading -- NIST SP 800-131A Rev 2 still permits SHA-1 for HMAC until 2030 -- so establish which list "approved" binds to, because that answer changes the TOTP verdict and does not rescue BLAKE2b either way.