This is an automated email from the ASF dual-hosted git repository.
potiuk pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/airflow-steward.git
The following commit(s) were added to refs/heads/main by this push:
new e3ac5d2 feat(security-issue-sync): auto-propose backtick-wrap for
Affected versions field (#367)
e3ac5d2 is described below
commit e3ac5d22f0eff64b5f498481a635fc796856d8ad
Author: Jarek Potiuk <[email protected]>
AuthorDate: Fri May 29 00:43:25 2026 +0200
feat(security-issue-sync): auto-propose backtick-wrap for Affected versions
field (#367)
The ``Affected versions`` body field on tracker issues holds version
expressions like ``>= 3.0.0, < 3.2.2``. Without backticks the leading
``>`` is interpreted by GitHub as a markdown blockquote, so the
rendered field shows as a quoted single line. Maintainers editing via
the issue-form UI then see the visible (un-quoted) text and "fix" it
by removing the ``>=`` prefix, silently turning a bounded range into a
misleading single-version entry like ``3.2.1`` — and the CVE record
that follows publishes with the wrong affected range.
Surface the un-wrapped state as a Step 1d signal so the sync proposes
the wrap on every run that encounters one, and reinforce on the
auto-derived ``Affected versions`` value (Step 2b) that the emitter
must wrap. The generate-cve-json parser already strips backticks at
parse time (``cleaned = value.strip().strip("\`").strip()``), so this
is a pure-cosmetic + edit-resilience fix with no semantic change.
Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>
---
.claude/skills/security-issue-sync/SKILL.md | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/.claude/skills/security-issue-sync/SKILL.md
b/.claude/skills/security-issue-sync/SKILL.md
index 31746c2..5691083 100644
--- a/.claude/skills/security-issue-sync/SKILL.md
+++ b/.claude/skills/security-issue-sync/SKILL.md
@@ -758,7 +758,8 @@ update, label change, or next-step recommendation in Step 2:
| The referenced `<upstream>` PR has been opened but is still in `open` state
| Propose `pr created` label; update the *"PR with the fix"* body field with
the PR URL. |
| The referenced `<upstream>` PR moved to `merged` | Propose swapping `pr
created` → `pr merged`; update milestone to the shipping release if now known.
**Also**: check whether all six mandatory CVE body fields are populated (*CWE*,
*Affected versions*, *Severity*, *Reporter credited as*, *Short public summary
for publish*, *PR with the fix*). If any is empty / `_No response_`, propose
posting (or PATCH-updating) the *Remediation-developer fill-fields comment* per
[the dedicated bullet i [...]
| The *"PR with the fix"* body field has at least one PR URL **and** the
*"Remediation developer"* body field is missing the PR author's name (or is
`_No response_`) | Propose appending the PR author's display name (`gh pr view
<N> --repo <upstream> --json author --jq '.author.name // .author.login'`) to
the *"Remediation developer"* body field. **Append, never overwrite** — manual
edits (co-authors added by the triager, name spelling corrections, "Anonymous"
overrides) must survive subs [...]
-| The *"Affected versions"* body field is missing, holds a pre-convention
shape, or carries the project's pre-release sentinel, and the tracker is
**not** at `fix released` yet | Propose populating / refining *"Affected
versions"* per the project's convention. The per-scope shape, the pre-release
sentinel (if any), and the lifecycle live in
[`<project-config>/scope-labels.md` — *Affected versions convention by
scope*](../../../<project-config>/scope-labels.md#affected-versions-convention
[...]
+| The *"Affected versions"* body field is missing, holds a pre-convention
shape, or carries the project's pre-release sentinel, and the tracker is
**not** at `fix released` yet | Propose populating / refining *"Affected
versions"* per the project's convention. The per-scope shape, the pre-release
sentinel (if any), and the lifecycle live in
[`<project-config>/scope-labels.md` — *Affected versions convention by
scope*](../../../<project-config>/scope-labels.md#affected-versions-convention
[...]
+| The *"Affected versions"* body field has a value but it is **not
backtick-wrapped** (the raw value, as returned by `gh issue view --json body`,
starts with a `>` character or contains a bare `>=` / `<=` / `<` / `>` token
outside a `` ` `` … `` ` `` span) | Propose wrapping the value in backticks
(e.g. `` `>= 3.0.0, < 3.2.2` ``, `` `< 3.2.2` ``, `` `<= 3.2.1` ``). **Why:**
the leading `>` is the markdown blockquote marker — without backticks, GitHub
renders the rendered field as a quote [...]
| A tracker is transitioning to `fix released` (per the row below) and
*"Affected versions"* still carries the project's pre-release sentinel |
Propose replacing the sentinel with the concrete released version per the
project's convention; see [`<project-config>/scope-labels.md` — *Affected
versions convention by
scope*](../../../<project-config>/scope-labels.md#affected-versions-convention-by-scope)
for the recipe. After the body update, regenerate the CVE JSON attachment so
`versions[] [...]
| A release carrying the fix has shipped. Detection is **scope-dependent** —
different scope labels on a project can ride different release trains, each
with its own *"is it released?"* signal (which artifact registry to consult,
what to query, how to map a tracker's milestone to that registry,
partial-release edge cases). The per-scope detection recipe lives in
[`<project-config>/scope-labels.md` — *Detecting that a fix release has
shipped*](../../../<project-config>/scope-labels.md#det [...]
| GHSA state transition (opened, accepted, published, rejected) in a
GHSA-forwarded email | If the GHSA is closed as "not accepted" but the security
team accepted the report on `security@`, flag the divergence in the status
comment so it is not lost. |
@@ -1413,7 +1414,12 @@ will change and *why*. Group them by category:
convention by
scope*](../../../<project-config>/scope-labels.md#affected-versions-convention-by-scope)).
Propose only when the milestone uniquely determines the affected
range; flag ambiguity (e.g. multiple backport milestones with
- partial coverage) rather than guessing.
+ partial coverage) rather than guessing. **Always emit the proposed
+ value wrapped in backticks** (e.g. `` `>= X.Y.Z, < A.B.C` ``,
+ `` `< A.B.C` ``); see the *"`Affected versions` body field has a
+ value but it is not backtick-wrapped"* row in the Step 1d signal
+ table for why this matters (raw `>=` renders as a markdown
+ blockquote and form-UI edits silently lose the prefix).
All other mandatory fields stay on the *external-signal* path:
propose values only when the discussion, mail thread, PR, or GHSA
