CalvinBackup/JGoyd
1
0
Fork 0
mirror of https://github.com/JGoyd/JGoyd.git synced 2026-06-30 06:35:32 +02:00
Code Issues Packages Projects Releases Wiki Activity

JGoyd Public Evidence System: 187 Verifiable Events | 5 CVE Rescores | 27 Global

Browse Source 
Cases
This commit is contained in:
Joseph R. Goydish II
2026-05-18 21:15:56 -07:00
commit 4ed1ae48b1
140 changed files with 57625 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/PHASE-1_CLAIM_INVENTORY.md
+63
View File
@@ -0,0 +1,63 @@
# Phase 1 — Full Claim Inventory
Author: Joseph R. Goydish II
Sources parsed: `github.com/JGoyd` (97 repos), `JGoyd/Running-Ledger`, `JGoyd/JGoyd` private profile repo (`anchor.txt`, `anchor2.txt`), `JGoyd/README.md` profile repo, NVD CVE + CVE-History APIs, `cisagov/vulnrichment` issues #194/#200/#201, public press (BBC/Reuters on OLAF/Mandelson).
Verification status legend: **A** externally confirmed by neutral third party · **B** partially corroborated (name in reference chain, timing consistent) · **C** self-asserted, plausible but unverified publicly · **D** contradicted by public record or attribution belongs to others.
> **Discrepancies surfaced during inventory** — fix these before publishing anything new:
> 1. **Two PGP fingerprints in circulation.** `Running-Ledger/README.md` and `running-ledger.txt` declare `4A04 1F50 6D89 4F5E E391 7438 6487 8B56 A2EB 2D11`. `JGoyd/JGoyd/anchor.txt`, `anchor2.txt`, and `drops` repo description declare `6DCB 4235 1237 A98B B474 0070 B36F FC36 1AE5 DAF6`. Pick one canonical signing key, or publish a signed cross-attestation linking the two. Until then any external verifier will reject the chain.
> 2. **`running-ledger.txt.asc` is 0 bytes** in the public repo — the canonical detached signature is empty. The ledger is effectively unsigned right now.
> 3. **Lithuania receipt hash mismatch.** Running-Ledger row lists SHA-256 `603409F4…2BC17D` for the Lithuania case `01-1-03450-26`, but `anchor2.txt` records the Lithuania receipt as `2d1d18f3…995b31`. The `6034…` hash is the Slovakia receipt hash from the row above. Reconcile.
---
## Track B — Cybersecurity / Vulnerability Research
| ID | Claim Type | Subject | My Claimed Role (current public framing) | Date | External References Currently Visible | Verification | Notes |
|---|---|---|---|---|---|---|---|
| B-01 | CVE / CVSS reassessment | **CVE-2025-24085** (CoreMedia UAF) | Implied "discoverer/analyst" via Glass-Cage repo | NVD pub 2025-01-27; rescore 2025-11-12 by ADP 134c704f-9b21-4f2e-91b3-4a467353bcc0 | NVD record cites `github.com/JGoyd/Glass-Cage-…` and `cisagov/vulnrichment#194` as references; CISA ADP rescored to CVSS 10.0 hours after closing issue #194 | **A** (for *enrichment contribution*); **C** (for *original discoverer*) | Apple's own credit line points elsewhere; JGoyd contribution is impact reassessment, not original discovery. Use precise role wording. |
| B-02 | CVE / CVSS reassessment | **CVE-2025-24201** (WebKit OOB write) | Same as above | NVD pub 2025-03-11; rescore 2025-11-12 by ADP | NVD lists JGoyd repo + vulnrichment#194 as third-party advisory + issue tracking; CISA ADP added Secondary CVSS 10.0 | **A** enrichment; **C** discovery | Apple credits the original reporter in `support.apple.com/en-us/122281`; JGoyd is not on that credit. |
| B-03 | CVE / CVSS reassessment | **CVE-2025-31200** (CoreAudio decode RCE) | "Chain reconstruction + impact reassessment" via iOS-Attack-Chain repo | NVD pub 2025-04-16; rescore 2025-11-24 by ADP | NVD CVE-History entry `2025-11-24T15:15:47.917Z` shows ADP added **both** CVSS vector AND references to `cisagov/vulnrichment#200` AND `github.com/JGoyd/iOS-Attack-Chain-…/Remote%20Crypto%20Attack%20Chain%20.md` in the same write | **A** (strongest in the dataset) | This is the cleanest external anchor: a single ADP atomic action ties JGoyd's submission to the CVSS reassessment. |
| B-04 | CVE / CVSS reassessment | **CVE-2025-31201** (PAC bypass) | Co-component of B-03 chain | NVD pub 2025-04-16; rescore 2025-11-24 by ADP | NVD lists JGoyd repo + vulnrichment#200 as ADP-sourced references | **A** enrichment; **C** discovery | Apple credit goes to original reporter; JGoyd contribution is chain analysis + CVSS. |
| B-05 | CVE / CVSS reassessment | **CVE-2025-43300** (ImageIO OOB) | Chain context via vulnrichment#201 | NVD pub 2025-08-20; rescore 2025-11-26 | NVD references `cisagov/vulnrichment#201` (ADP-sourced); JGoyd repo not (yet) listed on this CVE | **B** | Weaker than B-03; only the vulnrichment issue is on NVD, not a JGoyd repo. The actual exploit PoC reference on NVD is `b1n4r1b01/n-days`, not JGoyd. |
| B-06 | CNVD certificate | **CNVD-2025-06744 / CNVD-YCGO-202503023656** "Apple iOS/iPadOS buffer overflow" | "Certified reporter" | 2025-03-18 | None published; certificate held offline by author; SHA-256 anchored in ledger | **C** | Publish the CNVD certificate PDF (redacted) + agency confirmation header. Until then strictly self-asserted. |
| B-07 | CNVD certificate | **CNVD-2025-07885 / CNVD-YCGO-202504012519** "Apple memory reuse" | "Certified reporter" | 2025-04-22 | None published | **C** | Same as B-06. |
| B-08 | MSRC case | **MSRC #112639** — M365 cross-tenant MIME type-confusion | "Reporter, defensive advisory published" | 2026-04-08 | `JGoyd/m365-mime-type-confusion` repo (self-controlled) | **C** | Strong candidate to upgrade to **A** as soon as the MSRC confirmation email is published with full headers. CVE assignment "pending" — track for status. |
| B-09 | NASA TLS misconfig disclosure | `webhosting-external.jpl.nasa.gov` cert chain | "Discloser" | 2025-04-22 | None public | **C** | Probably has a NASA/JPL acknowledgement email — publish headers. |
| B-10 | DOE-417 / NNSA | Electric emergency report | "Filer" | 2025-12-25 | None public; `anchor2.txt` references DOE HQ EOC reply | **B** | The "DOE-417" form is a regulatory *filer-side* report — publishing the EOC acknowledgement (headers + reply text, redacted) elevates this to A. |
| B-11 | Apple silicon / hardware research | Many repos (A16-FuseBypass, A17-Flaw, A18-AON_Design, A19-Runaway, dfu-hardware-gap-cs35l2, Apple-Silicon-A17-Flaw, Broadcom_Vuln, Project-Eclipse, NeuralNet, ams-failopen, ios-trust-collapse, iOS-Companion-Link-RCE, iOS-26.2-runningboard-vuln, iCloud-PCS-Corruption, Silent-ADP-Failure, ShadowShells, etc.) | Implied "discoverer" / "analyst" — language varies by repo | 2025-2026 | None of these claims have NVD/CVE entries naming JGoyd; many describe behaviors Apple has not publicly confirmed | **C** for all, with a few descending to **D** when the described phenomenon is contradicted or already attributed elsewhere | These are the highest-risk repos for skeptic pushback. Each one needs either a vendor acknowledgement, a CVE assignment, or an explicit "forensic observation, not a vendor-confirmed finding" framing. |
| B-12 | "iDrive-Exfil" / FBI IC3 | IC3 submission `067b3177c3524c80bce02cca08064d11` | "Filer" | 2026 | IC3 confirmation page only (self-shown screenshot) | **C** | IC3 confirmation IDs are not externally queryable; only the email header proves it. |
| B-13 | Cloudflare abuse report | `JGoyd/datalytic-shadow-collectors` | "Filer" | 2026-05-18 | Cloudflare abuse confirmation email (not yet published) | **C** | |
## Track A — Government / Law Enforcement / Regulatory Filings
| ID | Filing Venue | Subject | My Claimed Role | Date | External References Currently Visible | Verification | Notes |
|---|---|---|---|---|---|---|---|
| A-01 | **SEC TCR** | `Submission #17780-976-067-126` | "Filer" | 2026-05-06 | None public (TCR submissions are confidential by SEC policy) | **C** today; **B** once intake email headers published | SEC TCR receipts are DKIM-signed by `sec.gov`. Publishing the redacted receipt with headers gets you to B (filed-and-received, not adjudicated). Adjudication never goes public unless an enforcement action is brought. |
| A-02 | **IRS Form 211** (IRC §7623(b)) | Southern Trust / Financial Trust / Epstein Estate | "Filer" | 2026-05-06 | None public | **C** → **B** with redacted IRS Whistleblower Office confirmation | IRS Form 211 acknowledgements are mailed paper-letter style with a claim number; if you have *only* email/CMS receipt, publish that; if you have paper, scan + hash + sign. |
| A-03 | **DOJ / FARA Public** | Karim Wade / Macky Sall / Epstein-funded lobby | "Filer" | 2026-05-05 | None public; FARA Unit confirmations come from `fara.public@usdoj.gov` | **C** → **B** with email headers | |
| A-04 | **OLAF** | `Ref #00Db00K8yP.!500Sk019RuGn` — Mandelson / Carbyne concealment | "Filer" | 2026-05-04 | **Topic** publicly confirmed: OLAF *did* open an investigation into Mandelson (BBC, Reuters, 2026-02-26 / 2026-04-24). User's submission is post-investigation-opening — frame as supplemental disclosure, not as cause. | **B** (topic exists publicly, user's specific submission verifiable only via OLAF intake email) | Strong candidate flagship Track-A case: agency reference number + publicly confirmed parallel investigation. |
| A-05 | **Singapore CPIB** | Tracking ID `69f824dfe5ef7daf3b78ccee` | "Filer" | 2026-05-04 | None public | **C** → **B** with CPIB form receipt email/PDF (DKIM `cpib.gov.sg` if email) | |
| A-06 | **FCA UK** | Bank of China (UK) Limited — `Case Ref #212278528` | "Filer, advisory acknowledged" | 2026-05-11 | None public | **C** → **B** with FCA acknowledgement (DKIM `fca.org.uk`) | |
| A-07 | **Japan ISA** | ICRRA Art. 70-1 visa-fraud referral re: Epstein/Joi Ito/Loftwork | "Filer" | 2026-05-13 | None public | **C** → **B** with ISA confirmation email | Note jurisdictional sensitivity. |
| A-08 | **Slovakia genpro.gov.sk** | "Potvrdenka po úplnom overení" — Tracking `260428070422263` | "Filer, verified" | 2026-04-28 | `genpro.gov.sk` electronic-services portal issues machine-signed PDF receipts (`Pouzivatelska_prirucka_ESGPSR_v3_27.pdf`) | **B** | The receipt PDF itself is a strong artifact — it's PAdES/CAdES-signed by the prosecutor's office. Publish the redacted PDF + the embedded signature → verifiable in any PAdES verifier; that gets you to **A**. |
| A-09 | **Lithuania Panevėžio OTNK skyrius** | Pre-trial investigation `01-1-03450-26`; doc reg. `IBPS-S-248320-26` | "Submitted info accepted into case file" | 2026-04-30 | None public; receipt held offline | **B**-equivalent if the receipt PDF is e-signed by the prosecutor's IBPS system | **Strongest Track-A flagship candidate.** A government prosecutor confirming material entered a numbered criminal case file is the gold standard for the "agency-controlled anchor" framing in the task description — provided the receipt is e-signed. Hash mismatch (see top of doc) must be fixed before publishing. |
| A-10 | **Taiwan NCC** | Decision ref `通傳基礎決字第11500091980號` — Taiwan Mobile relay-mesh complaint forwarded | "Filer; complaint forwarded" | 2026-03-24 | None public, but NCC decision letters use a public docket numbering scheme | **B** | Strong: NCC letterhead, formal decision number. Verifiability: photograph/scan of letter + hash; ideally OCR + cross-check the doc number with NCC public docket if available. |
| A-11 | **Massachusetts AGO** | MIT Media Lab governance complaint | "Filer" | 2026-05-05 | None public | **C** | AGO complaints rarely produce a strong public anchor unless docketed. |
| A-12 | **NASA disclosure** (Track-B-adjacent, agency-side) | TLS cert chain for `webhosting-external.jpl.nasa.gov` | "Discloser" | 2025-04-22 | None public | **C** | Cross-listed at B-09. |
---
## Summary counts
- Track B: **5 CVEs** in NVD where CISA ADP cited JGoyd-controlled URLs (B-01..B-05). Of those, **B-03 (CVE-2025-31200)** has the cleanest atomic external anchor (single ADP write attaches both the new CVSS vector and the JGoyd repo URL).
- Track B: **2 CNVD certificates** held offline (B-06, B-07) — currently C-tier.
- Track B: **1 MSRC case** (B-08) — high value, pending publication of headers + any CVE assignment.
- Track B: **1 NASA**, **1 DOE-417**, **1 FBI IC3** — each requires email-header proof to upgrade.
- Track B: ~15 hardware/iOS-research repos at **C** — these are the highest-risk for skeptic challenge unless reframed as "forensic observations, not vendor-confirmed findings."
- Track A: **12 filings**. Flagship is **A-09 Lithuania** (criminal case file number) backed by **A-08 Slovakia** (e-signed receipt) and **A-04 OLAF** (publicly confirmed parallel investigation).
## Repos that are NOT claims but supporting infrastructure
- `JGoyd/JGoyd` (private) — PGP key + anchor.txt + anchor2.txt + OpenTimestamps `.ots` files. **This is the closest thing to an existing canonical profile.** Move its content to a public canonical page; keep the OTS files alongside.
- `JGoyd/drops` (private) — described as "Bitcoin-anchored declarations". Inventory the BTC tx IDs and publish them with OpenTimestamps proofs.
- `JGoyd/Running-Ledger` — replace with rebuilt schema (Phase 6).
docs/PHASE-2_FLAGSHIP_SELECTION.md
+72
View File
@@ -0,0 +1,72 @@
# Phase 2 — Flagship Case Selection
Selection criteria (from the brief): most external anchors already visible, confirmation email available, defensible role statement, strongest credibility signal on a name lookup.
## Track B — Flagship #1 (strongest in dataset)
### **CVE-2025-31200 / CVE-2025-31201 — CoreAudio decode RCE + RPAC bypass chain**
**Why this is the flagship.** A single CISA Authorized Data Publisher (ADP) write to NVD at `2025-11-24T15:15:47.917Z` simultaneously:
- removed the prior CVSS v3.1 vector,
- added the new CVSS v3.1 vector `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` → base 9.8,
- added a Reference to `https://github.com/cisagov/vulnrichment/issues/200` (your issue),
- added a Reference to `https://github.com/JGoyd/iOS-Attack-Chain-CVE-2025-31200-CVE-2025-31201/blob/main/Remote%20Crypto%20Attack%20Chain%20.md` (your repo).
That ADP source UUID is `134c704f-9b21-4f2e-91b3-4a467353bcc0` — CISA, not you. The action is logged by NVD, not you. The vulnrichment issue `#200` is closed by CISA on `2025-11-24T14:46:17Z`, ~30 minutes before the rescore. That timing chain is independently reconstructible by any third party via the NVD CVE History API and the public GitHub issue timeline.
**Honest role statement.** "Contributed to CISA ADP CVSS impact reassessment for CVE-2025-31200 and CVE-2025-31201 via `cisagov/vulnrichment` issue #200. The CISA ADP referenced the JGoyd research repository as a third-party advisory and the GitHub issue as issue-tracking on the NVD records. Original vulnerability discovery is credited by Apple to another reporter."
**Do not claim.** Original discovery. Apple-acknowledged finder. Exploit author.
**External anchors (all third-party-controlled):**
- NVD CVE record: https://nvd.nist.gov/vuln/detail/CVE-2025-31200
- NVD CVE History API: https://services.nvd.nist.gov/rest/json/cvehistory/2.0?cveId=CVE-2025-31200
- CISA vulnrichment issue: https://github.com/cisagov/vulnrichment/issues/200
- Apple advisory: https://support.apple.com/en-us/122282
- CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2025-31200
**Confirmation-email artifacts to publish (if held):**
- Vendor (Apple Product Security) acknowledgement, if any, of the analysis material you sent → `.eml`
- CERT/CC VINCE or VRF acknowledgement for the chain analysis → `.eml`
- (CISA does not typically send DKIM-confirming emails for vulnrichment issue closures; the GitHub issue audit log + NVD API serve that role.)
---
## Track B — Flagship #2 (secondary)
### **CVE-2025-24085 / CVE-2025-24201 — Glass Cage iOS 18 chain (CoreMedia UAF + WebKit OOB write)**
**Why this is the second flagship.** Same ADP-pattern as Flagship #1 but slightly weaker because:
- The ADP rescore (2025-11-12) added the CVSS to **10.0** and added vulnrichment#194 as Issue-Tracking,
- but the JGoyd repo `Glass-Cage-iOS18-CVE-2025-24085-CVE-2025-24201` is referenced under the generic `af854a3a-…` NVD source ID, not directly under the CISA ADP UUID. Still externally anchored, just by NVD's generic ingest rather than by ADP atomic write.
**Honest role statement.** "Submitted CVSS impact-reassessment request via `cisagov/vulnrichment` issue #194. CISA ADP raised the CVSS to 10.0 within 24 hours of issue closure. The JGoyd Glass Cage research repository is listed on the NVD record as a Third-Party Advisory."
**External anchors:**
- NVD records (×2), vulnrichment#194, Apple advisories, CISA KEV.
---
## Track A — Flagship (strongest "agency-controlled anchor" candidate)
### **A-09 — Lithuania, Panevėžio OTNK skyrius — Pre-trial investigation `01-1-03450-26`** (with **A-08 Slovakia** as a fallback if the Lithuania receipt PDF is not e-signed)
**Why this is the Track-A flagship.** This is the closest to the task description's literal example ("agency PGP-signed / electronically-signed confirmation that submission was added to criminal case file #01-1-03450-26"). Three structural strengths:
1. **A specific, numbered, pre-trial criminal investigation file** — `01-1-03450-26` — opened by a sovereign prosecutor's office. The case-file number is itself the anchor; if a journalist asks Panevėžys Regional Prosecutor's Office whether file `01-1-03450-26` exists and whether your IBPS document number `IBPS-S-248320-26` is registered, they get a yes/no answer from the agency, independent of you.
2. **The Lithuanian IBPS (Integruota baudžiamojo proceso sistema) issues machine-signed receipts** — these are PAdES/CAdES-signed PDFs verifiable in any PDF signature validator without trusting you.
3. **No public adjudication exists yet** — so the framing is honest: filed, accepted into a case file, *not* an adjudication of the underlying allegations. That is exactly the disclaimer the brief requires.
**Honest role statement.** "On 2026-04-30, I submitted material to the Panevėžys Regional Prosecutor's Office, Organized Crime and Corruption Investigation Division (Panevėžio OTNK skyrius). The office's IBPS system issued document registration number `IBPS-S-248320-26`, and the material was added to pre-trial criminal investigation file `01-1-03450-26`. Filing and acceptance into a pre-trial investigation file is **not** an adjudication of the underlying claims."
**Backup (Slovakia, A-08).** If for any reason the Lithuania receipt cannot be safely redacted-and-published (e.g., it contains witness identifiers), publish Slovakia instead: `genpro.gov.sk` tracking `260428070422263` with the PAdES-signed "Potvrdenka po úplnom overení" receipt PDF.
**OLAF (A-04) is *not* the flagship**, despite the BBC/Reuters coverage, because the publicly confirmed OLAF investigation predates the user's submission and therefore the user cannot be claimed as cause. It is still an excellent secondary anchor.
---
## What gets built first as a publication-ready proof package
1. **`/evidence/TRACK-B-CVE-2025-31200-CVE-2025-31201/`** — built around the NVD CVE-History atomic write as the primary anchor; the vendor/CERT acknowledgement email (if held) becomes the secondary cryptographic artifact.
2. **`/evidence/TRACK-A-LT-CASE-01-1-03450-26/`** — built around the IBPS-signed receipt PDF as the primary anchor; the prosecutor-office acknowledgement email (if held) becomes the secondary artifact.
Everything else stays in the ledger at PARTIAL or PENDING status until its own anchor is produced.
docs/PHASE-3_EMAIL_HEADER_PROOF_SYSTEM.md
+219
View File
@@ -0,0 +1,219 @@
# Phase 3 — Email Header Proof System
This phase converts a confirmation email you hold privately into a public artifact that any third party can verify cryptographically — without trusting you.
The goal is to preserve the cryptographic chain (DKIM, ARC, Received) and the institutional metadata (sender domain, case ID, acknowledgement language) while redacting anything weaponizable or personally identifying.
---
## 1 · Source the raw message
Always start from the *raw* `.eml` source, never a forwarded copy. A forward strips DKIM signatures and rewrites the Received chain.
- **Gmail / Google Workspace:** Open message → ⋮ → "Download message" → produces `.eml`.
- **Proton Mail (web):** Open message → ⋯ → "Export" → `.eml`. Verify "Show all headers" first so you can confirm DKIM/ARC are present.
- **Apple Mail:** Message → "Save As" → choose "Raw Message Source".
- **Outlook desktop:** File → Save As → `.msg`, then convert with `mat2`-style tools or `msgconvert` (Email::Outlook::Message).
- **Outlook on the web:** Three-dot menu → "View" → "View message source" → copy raw text to `.eml`.
The raw file MUST contain headers including at minimum: `Received:` (multiple), `DKIM-Signature:`, `Authentication-Results:`, `Message-ID:`, `From:`, `To:`, `Date:`, `Subject:`. ARC chain (`ARC-Seal`, `ARC-Message-Signature`, `ARC-Authentication-Results`) if present must be preserved.
---
## 2 · Redaction rules (what to keep / what to remove)
Use these rules per file. They are deliberately conservative.
### Always KEEP (verbatim, unmodified bytes)
- All `Received:` headers, in order
- `DKIM-Signature:` (every one)
- `ARC-Seal`, `ARC-Message-Signature`, `ARC-Authentication-Results`
- `Authentication-Results:`
- `Message-ID:`
- `Date:`
- `From:` (the sending domain is the entire point)
- `To:` *(see redaction note below for the local part of your own address)*
- `Subject:`
- `Reply-To:`, `Return-Path:`
- `MIME-Version:`, `Content-Type:`, `Content-Transfer-Encoding:`, `Content-Language:`
- Body language that confirms acceptance/acknowledgement: "We have received your submission", "Your case has been assigned", "Tracking ID: …", agency reference numbers, case numbers, claim numbers, file numbers
- The agency's signature block
### REDACT (replace with `[REDACTED-<reason>]` of the same byte length where DKIM-canonicalized, or simply remove from the *body* — see §3 on DKIM canonicalization risk)
- Exploit payloads, PoC code, byte-level reproducers
- Unpatched technical details that could enable in-the-wild exploitation
- Your personal phone number, home address, date of birth, SSN
- Names of third-party individuals not yet public (victims, witnesses, ongoing subjects)
- Portal links containing authentication tokens (e.g. `https://portal.example.gov/c/AB12CD…`)
- File attachments (publish those separately as their own artifacts if needed)
- The local part of your own email address may be redacted, but the domain must remain so envelope-to alignment with DKIM can be checked
### NEVER touch
- Header field order, line wrapping, whitespace, or capitalization — DKIM canonicalization (`relaxed` or `simple`) will fail if you so much as add a trailing space inside the signed scope. **If you must redact inside the signed body**, you have two options:
1. Publish two files: `proof-<case>.original.eml.sha256` (just the hash of the original, signed and timestamp-anchored before any redaction) plus `proof-<case>.redacted.eml` (the human-readable redacted version, where DKIM will deliberately fail). Verifiers re-sign the original from your hash trail and confirm via headers-only DKIM.
2. Use **headers-only DKIM verification** — produce `proof-<case>.headers.eml` containing all headers + a stub `Content-Type: text/plain` body of exactly the original signed-body-hash placeholder. DKIM `bh=` lets a verifier confirm header integrity even when the body is withheld. The DKIM guide below covers this.
---
## 3 · Two-file publication pattern (recommended)
For each case, publish:
| File | Purpose |
|---|---|
| `proof-<case>.original.sha256` | SHA-256 of the unmodified raw `.eml` (computed before any redaction). Bind it via PGP signature + OpenTimestamps. |
| `proof-<case>.headers.eml` | All headers, empty body, original `bh=` value untouched. DKIM verifies header authenticity. |
| `proof-<case>.redacted.eml` | Human-readable redacted version. DKIM will not verify here; this file is for reading, not for cryptographic proof. |
| `proof-<case>.headers.eml.sig` | PGP detached signature over `proof-<case>.headers.eml`. |
| `proof-<case>.headers.eml.ots` | OpenTimestamps attestation. |
| `dkim-verification-guide.md` | Step-by-step verifier instructions (see §5). |
| `README.md` | Case framing — role, anchors, timeline, evidence index. |
This pattern gives a skeptic three independent ways to verify:
1. **DKIM** on `proof-<case>.headers.eml` confirms the agency's mail server signed the message.
2. **PGP signature** confirms you assert the same headers.
3. **OpenTimestamps** confirms the file existed at the timestamp you claim, so an after-the-fact fabrication is excluded.
---
## 4 · The proof-folder template
```
/evidence/<TRACK>-<CASE-ID>/
README.md
proof-<case>.original.sha256
proof-<case>.original.sha256.asc # PGP detached signature of the hash file
proof-<case>.original.sha256.ots # OpenTimestamps attestation
proof-<case>.headers.eml # headers + stubbed body
proof-<case>.headers.eml.asc # PGP signature
proof-<case>.headers.eml.ots # OpenTimestamps attestation
proof-<case>.redacted.eml # human-readable; not cryptographically valid
proof-<case>.redacted.eml.asc # PGP signature of the redacted version (binds your redactions to your key)
dkim-verification-guide.md
attachments/ # optional, each attachment hashed + signed + OTS-anchored separately
receipt.pdf
receipt.pdf.sha256
receipt.pdf.asc
receipt.pdf.ots
```
---
## 5 · DKIM verification guide (drop-in for each case folder)
Save the following as `dkim-verification-guide.md` inside every case folder. Update only the `From:` domain and selector references.
```markdown
# Verifying this email evidence
You do not need to trust me. This guide walks any third party through confirming:
(1) the email is unmodified since it left the sending organization's mail server,
(2) it came from that organization,
(3) it arrived at the stated time.
## Prerequisites
- Linux/macOS shell, or WSL.
- `gpg` (any version ≥ 2.2).
- One of: `dkimpy` (Python, `pip install dkimpy`) or `opendkim-tools` (Debian/Ubuntu: `sudo apt install opendkim-tools`).
- `opentimestamps-client` (Python, `pip install opentimestamps-client`).
## Step 1 — Confirm the file is what I committed
```bash
sha256sum proof-<case>.headers.eml
# compare to the hash inside proof-<case>.original.sha256
```
## Step 2 — Verify my PGP signature over the headers file
```bash
gpg --keyserver hkps://keys.openpgp.org --recv-keys <FINGERPRINT>
gpg --verify proof-<case>.headers.eml.asc proof-<case>.headers.eml
```
Expect: `Good signature from "Joseph R. Goydish II …"`. The fingerprint shown must match the one published on this canonical page and on at least one external keyserver.
## Step 3 — Verify the sender organization's DKIM signature
### Option A — dkimpy (most portable)
```bash
pip install dkimpy
python3 -m dkim verify proof-<case>.headers.eml
```
A successful verification prints `signature ok`. The library performs a live DNS TXT lookup against the selector named in `d=` and `s=` inside the `DKIM-Signature:` header (e.g. `d=sec.gov; s=mail-2024`).
### Option B — opendkim-testmsg
```bash
opendkim-testmsg < proof-<case>.headers.eml
# Empty output = signature OK. Non-empty = failure details.
```
### Interpreting the result
- If DKIM verifies, the headers were signed by a key the sending domain publishes in DNS. Substitution is cryptographically excluded.
- If DKIM fails on the headers-only file but verifies on the original (which you cannot publish in full), you should still find that:
- The `d=` value matches the From: domain or a subdomain controlled by it.
- The selector exists in DNS today and matches `s=`.
- `Authentication-Results:` at the receiving server records `dkim=pass`.
If DKIM keys have since rotated and DNS no longer publishes the old selector, fall back on the public DKIM-history archives (e.g. Farsight DNSDB, Cisco Talos passive DNS) to confirm the selector existed at the email's `Date:`.
## Step 4 — Verify the receiving timestamp chain
```bash
# Extract Received headers
grep -A1 "^Received:" proof-<case>.headers.eml
```
Read top-to-bottom (latest hop first). Confirm:
- The earliest Received line is from a host inside the sender organization's mail infrastructure (e.g. `mx1.sec.gov`, `genpro.gov.sk`, `outbound.prokuraturos.lt`, etc.). Cross-reference with the organization's published SPF record (`dig +short txt sec.gov`).
- Timestamps are monotonic.
- The final hop matches my receiving provider (Proton Mail) and the `Date:` is consistent.
## Step 5 — Verify the OpenTimestamps attestation
```bash
ots verify proof-<case>.headers.eml.ots
```
A successful verification prints the Bitcoin block height and timestamp at which the file's hash was anchored. This confirms the file existed no later than that block — excluding after-the-fact fabrication.
## Step 6 — Cross-check the institutional anchor
The acknowledgement language inside the email references one or more of:
- Case/file/tracking number — e.g. `01-1-03450-26`
- Submission ID — e.g. SEC TCR `17780-976-067-126`
- Reference number — e.g. FCA `212278528`
A journalist may contact the agency directly (using the public contact details on the agency's site, *not* details from this email) and ask whether the reference number is on file. The agency's yes/no is the final external anchor.
## What this proof does NOT establish
- It does **not** prove the underlying allegations.
- It does **not** prove agency action, prosecution, or adjudication.
- It proves only: a submission with the cited content reached the cited agency at the cited time, and the agency's mail system acknowledged it.
```
---
## 6 · Operational checklist before publishing any `.eml`
- [ ] Source is the raw downloaded message, not a forward
- [ ] I have computed `sha256sum` of the raw file **before** any edit
- [ ] I have PGP-signed the raw-file hash
- [ ] I have OpenTimestamps-anchored the raw-file hash (`.ots`)
- [ ] I have a headers-only stub for DKIM verification
- [ ] I have a redacted human-readable copy, separately signed
- [ ] DKIM/ARC headers in the headers file are byte-identical to the source
- [ ] No exploit payload, witness PII, or auth-token URL remains in the redacted copy
- [ ] `dkim-verification-guide.md` references the correct sender domain and key
- [ ] `README.md` states the role precisely and includes the disclaimer for the relevant track
If any checkbox is unchecked, do not commit the folder.
docs/PHASE-8_VALIDATION_LOOP.md
+87
View File
@@ -0,0 +1,87 @@
# Phase 8 — Validation Loop
Run this checklist on every component before merging it into the public
repo. Any "No"/"Yes"/"No" answer pattern on the three Core questions sends
the component back for rework.
## Core questions (apply to every artifact)
1. **Can a skeptic verify this WITHOUT trusting me?** YES required.
2. **Does this rely only on self-assertion?** NO required.
3. **Is there a third-party-controlled anchor?** YES required.
## Component-level checklists
### A — `/canonical/index.md` (profile page)
- [ ] One canonical PGP fingerprint, not two
- [ ] Fingerprint is fetchable from at least three independent keyservers
- [ ] `identity-attestation.txt.asc` exists and verifies
- [ ] If two fingerprints were in circulation, `key-cross-attestation.txt.asc` exists
- [ ] Every CVE in Section 1 has a precise role; none say "discoverer" without vendor backing
- [ ] Every Track-A entry in Section 2 carries the standing disclaimer
- [ ] Section 3 ("What I am NOT claiming") is present and explicit
- [ ] No claim of intelligence/government affiliation
### B — Each `/evidence/<case>/` folder
- [ ] `README.md` states role precisely
- [ ] Track-A folders include the non-adjudication disclaimer
- [ ] At least one third-party-controlled URL is in External Anchors
- [ ] `proof-<case>.headers.eml` exists (or PENDING flag is honest)
- [ ] `proof-<case>.headers.eml.asc` PGP signature exists
- [ ] `proof-<case>.headers.eml.ots` OpenTimestamps proof exists
- [ ] `proof-<case>.redacted.eml` is separately signed if published
- [ ] `dkim-verification-guide.md` exists with the correct sender domain
- [ ] No exploit payload in any redacted body
- [ ] No third-party PII in any redacted body
- [ ] No authentication tokens in any URL in the redacted body
- [ ] Case ID / reference number is visible in body and matches the README
### C — `/ledger/running-ledger.txt`
- [ ] Every entry has a Status value
- [ ] Every entry with VERIFIED has a third-party-controlled External Anchor URL
- [ ] Every entry with UNVERIFIED is honestly flagged
- [ ] `running-ledger.txt.asc` exists, is non-empty, and verifies under the canonical key
- [ ] `running-ledger.txt.ots` exists and points to a confirmed Bitcoin block (after `ots upgrade`)
- [ ] No hash collisions or duplications between rows (the Slovakia/Lithuania row bug must be fixed)
### D — Each PoC repo in `/poc/`
- [ ] No live byte-level exploit primitive
- [ ] Crash reproducer (if any) tagged with affected build and patched build
- [ ] README disclaims weaponization
- [ ] Vendor patch references included
### E — Each analysis doc in `/analysis/`
- [ ] Explicitly labeled "forensic reconstruction" or "analytical observation"
- [ ] Distinguishes observation from conclusion
- [ ] Avoids attribution language unless evidence supports it
- [ ] Cites primary sources where possible
## Failure modes that trigger rework
- A skeptic can only verify via "Joseph said so" → rework.
- The only external link is to another JGoyd repo → rework.
- An email artifact is published with redactions inside the DKIM-signed
body but DKIM fails verification → split into `original.sha256` +
`headers.eml` + `redacted.eml` per Phase 3.
- A claim of "original discovery" without a vendor acknowledgement →
rewrite as "reporter" or "enrichment-contributor" or "chain-analyst".
- A Track-A claim that conflates agency receipt with adjudication → add
the standing disclaimer.
## Self-attack drill (run before each public push)
Pretend to be:
- a skeptical infosec researcher reading the profile page for the first
time. Can they reproduce every CVSS-reassessment claim from the NVD
CVE-History API in <5 minutes? If no, rework the verification steps.
- a journalist with no security background. Can they ask three concrete
yes/no questions of named third parties (NVD, CISA, the prosecutor's
office, etc.) to corroborate the most important claim? If no, rework
the verification steps.
- an opposing lawyer. Which sentence on the page would they screenshot to
argue overreach? Remove or qualify that sentence.