potiuk opened a new pull request, #131:
URL: https://github.com/apache/airflow-steward/pull/131
## Summary
- When a tracker's *Security mailing list thread* body field records **two
inbound threads** — typically the original direct report *and* a separate
forwarder/relay thread that landed afterwards (huntr.com bounty relay, GHSA
forward, HackerOne forward, ASF-security relay) — default reply drafts now
target the **primary reporter's** thread, not the forwarder's relay thread. The
relay thread stays on the tracker for record-keeping and is only used for the
rarer back-channel "please relay this question" message.
- Codifies the rule + detection signals in `tools/gmail/threading.md` as a
new section *"Selecting the inbound thread when multiple are recorded"*.
Signals are case-insensitive matches on the line's annotation text: `via
huntr.com` / `via GHSA` / `via HackerOne` / `ASF-relayed` / `relay` /
`forwarder` / `<provider>-class duplicate` / etc. Worked example uses the
airflow-s/airflow-s#351 shape (Vincent55 direct vs Aymane huntr.com relay).
- Scopes the existing `tools/gmail/asf-relay.md` shape to the
relay-thread-only case: the asf-relay drafting shape (different `To:`, brevity,
link to external reference) applies when the relay thread is the **only**
thread on the tracker; when a separate primary thread exists, asf-relay's shape
is reserved for the back-channel relay message instead.
- Adds one-paragraph pointers in the three drafting skills that reply on
existing trackers — `security-issue-sync` (status updates),
`security-cve-allocate` (CVE-allocated reporter notification),
`security-issue-invalidate` (close-as-invalid reply). Each pointer
cross-references the new threading.md section.
## Motivation
Surfaced by airflow-s/airflow-s#351 ("Variable masker depth-limit bypass"):
a primary report by Vincent55 (direct email to [email protected],
thread `19dc8d4675dfc1f1`) was followed by an Aymane Maguiti huntr.com bounty
relay (`@apache/security` forward, thread `19def0954b27ac31`). Both threads are
recorded on the tracker, but the framework had no documented rule for which one
outbound reply drafts should target. Without this rule a future reply could
land on the relay thread — leaking the ASF forwarder into a CVE-allocated
status notification or an advisory follow-up that should go directly to the
reporter.
## Scope choices
- **No body-field-format change.** The existing line-per-reporter shape
(from the dedupe skill) is already in the wild; the new rule reads it via
permissive string-matching of the annotation text rather than imposing a
structured `primary: true` flag. Avoids migrating existing trackers.
- **`security-issue-import` is not touched.** Import is the entry point that
*records* the second thread; the bug today is that downstream skills *select*
the wrong one. The fix where the second thread is read suffices. A follow-up PR
could tighten the import skill's annotation convention (always include explicit
`via <channel>` or `ASF-relayed` markers when appending) so detection is more
robust — opt-in for a later PR if needed.
- **Surface the selection in the proposal.** All three skills now surface
"drafting on primary reporter thread `<id>` (`<name>`); secondary relay thread
`<id>` excluded" in their per-draft proposal, so the user can override on the
rare per-message case where a relay-channel reply is actually wanted.
## Test plan
- [ ] Walk a real allocation on a tracker with two recorded threads
(airflow-s/airflow-s#351 or similar) through `security-cve-allocate`; confirm
the Step 5 proposal explicitly names the primary thread and excludes the relay
thread.
- [ ] Walk a sync run on the same tracker; confirm the Step 2b proposal
surfaces the primary/secondary selection.
- [ ] Walk a hypothetical invalid close on a multi-thread tracker; confirm
the email-draft step routes through the primary thread per the new row in the
look-up table.
- [ ] Confirm a relay-thread-only tracker (no separate primary) still
follows the existing `asf-relay.md` shape (the asf-relay scope clarifier should
not regress that path).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
