potiuk opened a new pull request, #196: URL: https://github.com/apache/airflow-steward/pull/196
## Summary `vulnogram-api-check` was returning `error: HTTP 302` whenever the probe URL redirected to a non-login destination. Upstream Vulnogram now 302-redirects `/cve5/new` → `/allocatecve` (the PMC-gated allocation page), and the probe code treated *any* non-OAuth 3xx as an unknown error. This was producing **false-negative "expired" diagnoses on adopter machines whose sessions were actually working** — `vulnogram-api-record-update` (which hits a different endpoint) kept succeeding, so `security-issue-sync` was incorrectly falling back to the "manual paste required" release-manager hand-off variant on trackers whose CVE JSON had in fact been auto-pushed. ## Fix `_is_login_redirect` already encodes the only failure mode worth detecting (3xx to `oauth.apache.org` or `/users/login` → session expired). Any *other* 3xx means the app processed the session cookie successfully and chose to redirect to a different authenticated page — the session is valid; only the post-auth landing page changed. The fix is a one-line additive condition in `probe()` plus a regression test covering the `/cve5/new` → `/allocatecve` case. ## Diff | File | Δ | |---|---| | `tools/vulnogram/oauth-api/src/vulnogram_api/client.py` | +8 −1 (`probe()` accepts non-login 3xx as valid, with docstring explaining why) | | `tools/vulnogram/oauth-api/tests/test_client.py` | +9 (new `test_probe_valid_on_non_login_redirect`) | ## Test plan - [x] `pytest tests/test_client.py` — 14 tests pass (was 13 + the new regression test). - [x] Live probe with my Apache OAuth session: previously returned `error: HTTP 302`, now returns `valid` (URL redirects to `/allocatecve` as expected). - [x] Live push via `vulnogram-api-record-update` for 3 CVEs (`CVE-2026-27173`, `CVE-2026-42359`, `CVE-2026-42526`) — all succeeded, demonstrating that the session is functional and the probe was the false negative. - [ ] Other adopters with valid sessions confirm `vulnogram-api-check` flips from `error: HTTP 302` → `valid` after this lands. ## Why "treat as valid" instead of changing the probe URL The alternatives considered: - **Change probe URL to `/cve5` (dashboard)** — would work for now but breaks again the next time Vulnogram reshuffles routing. - **Follow redirects in `_request`** — invasive change to `_request`'s contract; other call sites rely on seeing the raw 3xx. - **Accept non-login 3xx as valid (this PR)** — minimal change, doesn't pin to a specific URL, and the semantic is correct: "we got past auth" *is* what we wanted to probe. 🤖 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]
