russell@unturf.com
0a580b313d
Authors: russell@unturf.com · brackishbert@gmail.com · foxhop.net · TimeHexOn.com Patches, unit tests, benchmarks, whitepaper, and outreach briefs. Public domain — no copyright claimed. Use freely.
125 lines
5.4 KiB
ReStructuredText
125 lines
5.4 KiB
ReStructuredText
Responsible Disclosure Timeline
|
|
=================================
|
|
|
|
.. contents:: :local:
|
|
|
|
Overview
|
|
--------
|
|
|
|
This research involves CWE-407 defects across 16+ ecosystems. Some of the affected tools
|
|
accept untrusted input (compilers, package managers, routing daemons) and are therefore
|
|
candidates for CVE filing. The disclosure process must be complete, coordinated, and respect
|
|
upstream maintainers' time to respond.
|
|
|
|
**Current status as of 2026-03-23:** Phase 1 in progress.
|
|
|
|
Phases
|
|
------
|
|
|
|
Phase 1 — Complete Patches, Tests, and Benchmarks
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
**Status: IN PROGRESS**
|
|
|
|
For every confirmed defect site:
|
|
|
|
- [ ] Write the patch
|
|
- [ ] Write unit tests with exact operation-count verification
|
|
- [ ] Write integration tests (before/after timing at multiple V values)
|
|
- [ ] Write functional tests (end-to-end correctness on the real tool)
|
|
- [ ] Run and record benchmarks
|
|
|
|
Completion criteria: all 30 confirmed defect sites have patches and passing tests. Pending
|
|
defects (all networking, database, and several compiler/tool sites) must be either patched
|
|
or explicitly classified as out-of-scope before Phase 2 begins.
|
|
|
|
Phase 2 — White Paper Complete
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
**Status: IN PROGRESS (this document)**
|
|
|
|
- [ ] All vector .rst files complete with defect data and complexity proofs
|
|
- [ ] Proof section complete (complexity model, fix pattern, benchmarks)
|
|
- [ ] Disclosure section complete (this file, cve-strategy.rst)
|
|
- [ ] Sphinx build passes cleanly (``make html`` from ``whitepaper/``)
|
|
- [ ] Internal review complete
|
|
|
|
Phase 3 — Private Notification to Upstream Maintainers
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
**Status: Not started**
|
|
|
|
Notification sequence (order by blast radius — lowest-surface first):
|
|
|
|
1. Erlang/OTP (erlang-0001, erlang-0002) — stdlib only; Erlang is niche
|
|
2. Linux kernel scripts (linux-0001) — build-time tooling only; very low blast radius
|
|
3. GCC (gcc-0001) — gcov path; medium blast radius
|
|
4. LLVM/Clang (llvm-0001) — LTO path; medium blast radius
|
|
5. Cargo (cargo-0001) — display only; low blast radius
|
|
6. pip/distlib (distlib-0001) — HIGH priority; runs on every pip install with cycle detection
|
|
7. npm Arborist (npm-0001, npm-0002) — HIGH priority; runs on every npm install
|
|
8. CMake (cmake-0001) — HIGH priority; link ordering for all C/C++ builds
|
|
9. Maven (maven-0001, maven-0002, maven-0003) — HIGH priority; Java build ecosystem
|
|
10. GHC (ghc-0001 through ghc-0004) — HIGH priority; Haskell compiler
|
|
11. TypeScript/tsc (ts-0001, ts-0002, ts-0003) — HIGH priority; JS/TS compiler
|
|
12. Kotlin/kotlinc (kotlin-0001) — HIGH priority; JVM compiler
|
|
13. rustc (rustc-0001, rustc-0002) — HIGH priority; systems language compiler
|
|
14. Scala 3 (scala3-0001) — CRITICAL; O(n³)
|
|
15. Networking vendors (FRRouting, BIRD, ExaBGP, ONOS, OpenDaylight) — if defects confirmed
|
|
|
|
**For each notification:**
|
|
|
|
- Send private email to the project's security contact or maintainer list
|
|
- Include: defect description, affected file and line, complexity analysis, proposed patch,
|
|
unit test demonstrating the defect, benchmark results
|
|
- Request: 90-day response window; acknowledgment within 14 days
|
|
- Attach this white paper (PDF) as supporting documentation
|
|
|
|
**Routing/networking vendors** are notified in Phase 3 alongside compiler vendors if scan
|
|
results confirm defects. Given the potential for routing convergence impact, treat networking
|
|
defects as security-critical (see frrouting.rst threat model).
|
|
|
|
Phase 4 — Coordinated Public Disclosure
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
**Status: Not started**
|
|
|
|
After the 90-day window has elapsed (or all maintainers have acknowledged and merged
|
|
or declined):
|
|
|
|
- Publish white paper on research blog / arxiv
|
|
- Submit to compiler/tools conferences if appropriate (PLDI, EuroLLVM, etc.)
|
|
- Post summary to relevant mailing lists (OpenJDK-dev, ghc-devs, typescript-contributors, etc.)
|
|
- File CVEs for tools that accept untrusted input (see :doc:`cve-strategy`)
|
|
- Notify CWE/MITRE with the defect map as supporting data for CWE-407 documentation
|
|
|
|
Public disclosure sequence mirrors Phase 3 notification sequence — lowest blast radius first.
|
|
Do not announce routing/networking defects until those vendors have had their full 90-day window.
|
|
|
|
Phase 5 — CVE Filing
|
|
~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
**Status: Not started**
|
|
|
|
File CVEs for confirmed defects in tools that accept untrusted input. See
|
|
:doc:`cve-strategy` for the full analysis.
|
|
|
|
CVE filing happens after maintainer notification (Phase 3) — either when the 90-day window
|
|
expires or when the patch is merged, whichever comes first.
|
|
|
|
Key Constraints
|
|
---------------
|
|
|
|
- **No partial disclosure.** Do not announce any defect until all defects in that tool's
|
|
ecosystem are ready. Announcing javac defects without the routing defects is acceptable;
|
|
announcing only some javac defects is not.
|
|
|
|
- **No disclosure before patches.** A defect without a patch is a vulnerability notice,
|
|
not a research contribution. Every disclosed defect must come with a working fix.
|
|
|
|
- **Coordinated timing.** Sequence the announcements so that low-blast-radius disclosures
|
|
do not implicitly reveal the higher-blast-radius findings before their maintainers are ready.
|
|
|
|
- **Routing vendors get security treatment.** FRRouting, BIRD, and similar projects should
|
|
be notified through their security disclosure channels (not public mailing lists), and the
|
|
initial notification should be marked confidential.
|