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.
