AV smoke test: record that the Bearfoos verdict was TRANSIENT and self-corrected (#190 closed). The false positive lived in exactly one definition set -- 1.457.172.0 (8/14 19:34) deleted the 4.11.957 exe from a normal Desktop install four times; 1.457.177.0 (8/15 03:41) passes the identical binary (sha256 6081B9BA..) with zero detections -- which also explains a second tester seeing no problem at all on midnight-updated definitions. No Microsoft submission needed, no tester instructions, no risk to the next session. The smoke test STAYS (75 seconds, and this will recur -- we ship an unsigned binary rebuilt every session), but the framing now leads with the response rather than the incident: an ML antivirus verdict is a time-varying OPINION about a file, not a fact about it, so update definitions and retest before warning testers, resigning or rebuilding. Independently, PE forensics ruled out tampering: identical section layout and entropy vs a known-good build, no added imports (419 functions vs 913's 420), no new DLLs, entry point in .text, byte-identical shipped DLLs.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Joe DiPrima
2026-08-15 08:25:26 -05:00
co-authored by Claude Opus 5
parent b93f1e903f
commit e1ffc4a991
+7 -2
View File
@@ -200,8 +200,13 @@ default (`-DBT_STEAM=ON` is the documented dev-checkout state). `BT_EXPIRE=ON` (
zip somewhere clean and booting it with no repo present — that is what catches a missing runtime DLL.
**ANTIVIRUS SMOKE TEST — do this before handing a zip to anyone (#190, 2026-08-15).** Windows
Defender's ML classifier flagged `btl4.exe` as `Trojan:Win32/Bearfoos.A!ml` and DELETED it. This is
a false positive, and it is **per-binary, not per-project**: of 17 archived builds extracted side by
Defender's ML classifier flagged `btl4.exe` as `Trojan:Win32/Bearfoos.A!ml` and DELETED it. False
positive, and **it corrected itself within hours** — the verdict lived in definition set
1.457.172.0 (8/14 19:34) and was gone by 1.457.177.0 (8/15 03:41), same binary passing cleanly;
a second tester on midnight-updated definitions never saw it at all. **The lesson is the response,
not the incident: an ML verdict is a time-varying opinion about a file, not a fact about it — update
definitions and retest BEFORE warning testers, resigning, or rebuilding.** It is also
**per-binary, not per-project**: of 17 archived builds extracted side by
side, only **4.11.957** was condemned — 622 through 913 all survived — plus that evening's fresh
build. Our exe fits the profile that trips these classifiers (unsigned, rebuilt every session so it
never accrues reputation, opens raw sockets, enumerates processes, writes beside itself), so any