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

Open
  • Is something wrong?
#5,054 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
12/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
security, tooling

Research direction

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.

Written by the indexing model from the issue text.

Description

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).

Dominant language
Python
Stars
57
Forks
11
Avg merge
1h 35m
Merged PRs (30d)
975

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from squid-protocol/gitgalaxy

All issues in squid-protocol/gitgalaxy

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.