Blocker report: a full version for the customer plus an anonymized version they can send us to feed the engine-fix loop

Aperta
  • Qualcosa non va?
#5,054 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
12/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
security, tooling

Direzione di ricerca

The payload names no source files, so the first step is to read #4493 (the generated blocker page this extends), #5051 (the ledger the ingestion writes to) and the churn/shepherd harness it mentions. Done means one run writes a full and an anonymized report with matching counts, a leak test over the fixture estate fails on any leaked identifier, literal, comment or path, and salted hashes are stable for one salt and change with another. Scope is design-heavy, so a newcomer should not start here.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement enterprise legacy-modernization priority: medium scope:infra tier:customer

Why. When a customer runs a zero-gap scan on their own machine, two people need the blocker list:

  1. The customer, who needs every detail (files, programs, symbols, copybooks, tables) to work through their own tickets.
  2. Us, because their blockers are what tell us where the engine has to improve next. Customers won't send us source code or their names for things, so today we have no way of seeing what blocked them.

So the report should come in two forms from one run: a full report that stays with the customer, and an anonymized one they can send to us safely. The anonymized report then feeds our own engine-fixing loop (the churn/shepherd harness), the same way our own estates do today.

What.

  • Full report. Everything #4493 describes: coverage, run status per program, and blockers stated as fixes, with the files, symbols and unlock counts named. This one never leaves the customer's machine.
  • Anonymized report. Generated from the same data in the same run (--anonymize, or always written next to the full one) as Markdown + JSON. It keeps the shape of each blocker and removes anything that identifies the customer:
    • Kept: the blocker category and sub-class (layout / non-VSAM input / cross-record rule / unresolved link / environment / CICS command family / dialect …), the construct signature (e.g. EXEC CICS READQ TS … NUMITEMS, REDEFINES selected by sibling field, RECFM V), counts (programs blocked, tests unlocked, how often it occurs), the engine and rule-catalogue version, and refusal codes.
    • Removed: program, copybook, file, dataset, table, queue, transaction and field names; literals and comments; paths; and any source lines.
    • Hashed instead of dropped: identifiers become a salted hash (PGM_7f3a, TBL_19c2), with one salt per customer kept on their side. Their runs can then be compared over time ("this blocker is still open after 3 releases"), but nothing can be matched across customers or reversed.
    • A small minimal repro where possible. For example, a synthetic COBOL/CICS snippet built from the construct signature with made-up names, so we can reproduce the blocker without their code.
  • A manifest the customer can review. It's a short list of exactly what fields the anonymized file contains, so their security team can approve sending it, plus a --redact-more option to drop sub-classes or counts if they want.
  • Ingestion on our side. We need a command that takes a customer's anonymized report and turns each blocker into a ledger row (#5051, with estate: customer:<hash>), linking it to an existing issue when the construct signature matches one, or opening a new one when it doesn't. The anonymized report becomes one more input to the churn queue.

Done when:

  1. One run writes both reports. Every blocker in the full report appears in the anonymized one under the same category, with the same counts.
  2. A leak test passes. On a fixture estate, scan the anonymized output for every identifier, literal, comment and path in the source, and fail if any of them appear. This runs in CI on the crucible estates (CardDemo, GenApp, CBSA, zECS, cics-crucible).
  3. The hashes don't change between runs with the same salt, and they do change with a different salt.
  4. Ingesting an anonymized report from one of our own estates creates ledger rows that match the blockers we already know that estate has.
  5. The anonymized format is documented as a public schema with a version, so customers can audit it.

Related: #4493 (generated blocker page; this is its full form plus a twin that's safe to send), #5051 (port-blocker ledger; where ingested reports land), #5052 (economics of the iterative loop), #4724 (readiness scanner support matrix), #4055 (product is the proof).

Lingua principale
Python
Stelle
57
Fork
11
Merge medio
1h 42m
PR unite (30g)
966

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di squid-protocol/gitgalaxy

Tutte le issue di squid-protocol/gitgalaxy

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.