potiuk opened a new pull request, #372: URL: https://github.com/apache/airflow-steward/pull/372
## Summary The *"Short public summary for publish"* body field powers the published CVE description that end users read in the advisory. A summary that names the vulnerability accurately but lacks the concrete upgrade-target version (e.g. *"upgrade to the Airflow version that contains the fix"* without naming `3.3.0`) is a defect — it forces the reader to open another tab to figure out which version to pin, exactly the friction the advisory is supposed to remove. The skill already enforces this as a gate at the `pr merged → fix released` transition. This widens the rule so it fires on **every** sync pass that proposes a body-field update or a JSON regen, not only at one boundary. ## Real-world example On `airflow-s/airflow-s#244` ([CVE-2026-33264](https://cveprocess.apache.org/cve5/CVE-2026-33264)) the summary ended with the generic *"Users are advised to upgrade to the Airflow version that contains the fix."* — a string that survived multiple sync passes because none of them transitioned the tracker to `fix released`. The reviewer (`[email protected]`) flagged the affected-versions range twice on the CVE record before the summary itself got tightened in a manual sync, ahead of the next regen + push. ## Changes 1. **Step 2b paragraph** *"Short public summary for publish must include user-facing instructions"* — explicitly call out the "every sync pass" trigger plus the per-scope upgrade-target shapes: - core: `` `apache-airflow X.Y.Z or later` `` - providers: `` `apache-airflow-providers-<name> X.Y.Z or later` `` - chart: `` `apache-airflow-helm-chart X.Y.Z or later` `` 2. **Step 1d signal-table row** — detector for *"summary populated but does not name a concrete upgrade-target version"* (pattern: text mentions *"upgrade"* / *"upgrading"* but no `<package> <X.Y.Z>` match, OR ends with a generic phrase like *"the version that contains the fix"* / *"a later version"* / *"the next release"*). Surfaces the rewrite proposal on every qualifying pass so the tightening lands lock-step with the next JSON regen. ## Test plan - [x] Skill markdown is internally consistent — Step 2b paragraph cross-references the new Step 1d row, and the row cross-references the per-scope shapes in Step 2b. - [x] `skill-and-tool-validate` pre-commit hook green. - [ ] Manual end-to-end: next `/security-issue-sync` invocation against a tracker carrying a generic summary should surface the rewrite as a proposed body-field change. ## Follow-up A complementary CVE-tool-side check would refuse to push a CVE record whose `descriptions[0].value` lacks a `<package> X.Y.Z` token. Currently no such check exists — the generator emits whatever the body field contains. Deferred to a separate PR; this skill-level guard catches it earlier (at body-update proposal time) which is the cheaper fix. ##### Was generative AI tooling used to co-author this PR? - [x] Yes — Claude Opus 4.7 (1M context) -- 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]
