Response to incident WA-2026-10-27 (the std::vector max_size() crash). Deep research archived under research/safe-cpp-practices (8 Tier 1, 37 Tier 2, 2 conclusions) on production-safe C++ that keeps development speed: OpenSSF compiler hardening, the C++ Core Guidelines bounds profile, integer-overflow practice, libFuzzer/sanitizer CI, the sanitizer overhead ladder, clang-tidy ratchets. The research prescribed an ASan+UBSan+_GLIBCXX_ASSERTIONS build of the parsers. Standing it up immediately caught a second, independent undefined-behavior bug that two manual reviews had missed: a protobuf varint loop that shifted by up to 70 bits (shift >= 64 is UB) on malformed input. Fixed and guarded by a deterministic test and the sanitizer net. - src/whatsapp/wa_proto.cpp: guard the wire-0 varint shift (the UB). - tests/whatsapp_test.cpp: add an overlong-varint hostile case. - tools/san-whatsapp.sh: the standing sanitizer net for detz::wa parsers. - WaClient frame capture: a frame that fails to decode/dispatch has its exact bytes recorded to <home>/whatsapp/last-error.log (bounded), so the still unreproduced live <iq> failure becomes a one-paste deterministic fix. Wired from the wizard and the whatsapp_send tool. - docs/cpp-safety.md: the project-wide playbook and design decisions (four layers: overflow-safe checked-reader parsing, cheap release hardening, the sanitizer test net, capture). docs/whatsapp.md section 13.6 records the follow-up and the honest open item. AGENTS.md makes it a standing rule; cap.md and mcp.md inherit it for their wire parsers. Verified: build, whatsapp_test (incl. hostile+fuzz), make lint, and tools/san-whatsapp.sh all green; research audit PASS. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2.4 KiB
2.4 KiB
OpenSSF Compiler Options Hardening Guide for C and C++
Metadata
| Field | Value |
|---|---|
| Institute | Molodetz Institute — Research & Retrieval Division |
| Subject | safe-cpp-practices |
| Document type | Source Dossier |
| Tier | 1 |
| Source title | OpenSSF Compiler Options Hardening Guide for C and C++ |
| Source URL | https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++.html |
| Source publisher / author | Open Source Security Foundation (OpenSSF) Best Practices WG |
| Source type | standard |
| Source date (published) | Unknown — not stated (living document) |
| Date researched | 2026-10-27 |
| Researched by | tai (agent), model: Claude Opus 4.8, on behalf of retoor |
| Research method | web search synthesis |
| Confidence | High |
| Status | Active |
Summary
The authoritative, vendor-neutral list of compiler and linker flags that harden a C/C++ binary in production. It pairs library precondition checks with stack and fortification protections and states the cost of each.
Key findings
- Recommended production set pairs
_GLIBCXX_ASSERTIONSwith_FORTIFY_SOURCE=3,-fstack-protector-strong, and-fstack-clash-protection. _GLIBCXX_ASSERTIONSturns libstdc++ preconditions (container bounds, valid iterators) into checks; it has a small, roughly constant-time cost suitable for release.- The full set also includes RELRO, noexecstack, PIE, and
-fstrict-flex-arrays=3. - The standard library's 'fast' hardening mode is security-critical constant-time checks meant to stay on in production; heavier fortification can cost performance.
-fstack-protector-strongis called out as the balance point between coverage and cost._FORTIFY_SOURCEis not general memory safety, and sanitizers can misbehave when combined with source fortification.
Pros / strengths
Authoritative, concrete flag lists, honest about cost, separates cheap-always-on from expensive-test-only.
Cons / limitations / caveats
A menu, not a policy: a project still must decide which flags gate release vs test. Says little about C++-level API design.
Relevance to tai
Directly answers 'how do we make release builds catch the length_error/over-index class cheaply': _GLIBCXX_ASSERTIONS plus fortification. detz adopts the cheap subset for release and the full sanitizer set for the test net.
Changelog
| Date | Change |
|---|---|
| 2026-10-27 | Initial dossier created (web search synthesis). |