[VaibhavUpreti]

Fixes https://github.com/Tracer-Cloud/opensre/security/dependabot/60

Describe the changes you have made in this PR -

• Release workflow (release.yml): the workflow_run trigger's branches: [main] filter matches the CI run's head branch name. A fork PR opened from the fork's own main has that same name, and CI runs on fork PRs (automatically for returning contributors), with the PR's own copy of ci.yml. If such a run reached prepare, Release would build the fork's commit and publish it as the rolling main-build release using MAIN_BUILD_TAG_TOKEN. That release is the build the installer's main channel and the hosted gateway image take. prepare now also requires workflow_run.event == 'push' and head_repository == github.repository, and the metadata step refuses a workflow_run commit that is not on origin/main.
  • Not exploited: since the trigger was added (2026-09-15), Release has 468 workflow_run runs against 473 CI pushes to main, and none came from the 11 fork-main CI runs (one of which succeeded on 2026-11-05). The guard stops relying on that platform behaviour.
  • Every legitimate trigger still passes: of the last 100 successful CI runs on main, 99 were same-repo pushes (pass) and 1 was a fork PR (now refused).
• oauthlib 4.0.0 → 4.0.1 (GHSA-3jp2-3mrg-2vxc, high, via kubernetes → requests-oauthlib), floored in [tool.uv].constraint-dependencies.
• integrations/neon/client.py: drop the unused logger, which clears the open CodeQL py/unused-global-variable alert.

Demo/Screenshot for feature changes and bug fixes -

$ uv run pytest -q tests/packaging/test_release_manifest.py tests/github_ci tests/integrations/neon
57 passed / 44 passed
$ git merge-base --is-ancestor <origin/main~3> origin/main  -> publish
$ git merge-base --is-ancestor <commit not on main> origin/main -> refuse
$ uvx pip-audit (osv + pypi) over uv export --all-extras --all-groups
No known vulnerabilities found

---

Code Understanding and AI Usage

Did you use AI assistance (ChatGPT, Claude, Copilot, etc.) to write any part of this code?

• No, I wrote all the code myself
• Yes, I used AI assistance (continue below)

If you used AI assistance:

• I have reviewed every single line of the AI-generated code
• I can explain the purpose and logic of each function/component I added
• I have tested edge cases and understand how the code handles them
• I have modified the AI output to follow this project's coding standards and conventions

Explain your implementation approach:
The job-level if stops a fork-triggered run before any step executes (so no fork code is checked out or run), and the ancestor check is a second, trigger-independent guard that a workflow_run release only ever ships a commit on main. test_release_workflow_does_not_run_on_pull_requests now asserts both. workflow_dispatch and schedule are unchanged.

---

Checklist before requesting a review

• I have added proper PR title and linked to the issue
• I have performed a self-review of my code
• I can explain the purpose of every function, class, and logic block I added
• I understand why my changes work and have tested them thoroughly
• I have considered potential edge cases and how my code handles them
• If it is a core feature, I have added thorough tests
• My code follows the project's style guidelines and conventions

[github-actions]

Greptile code review

This repo uses Greptile for automated review. Before merge, aim for Confidence Score: 5/5 with zero unresolved review threads — see CONTRIBUTING.md.

Run a review — add a PR comment with:

@greptile review

Give it ~5-10 minutes (sometimes longer) for results, then fix feedback and re-trigger until you reach Confidence Score: 5/5.

Optional: automate with the greploop skill.

[github-actions]

🚀 Houston, we have a merge. VaibhavUpreti your PR is in orbit. Thanks for launching this one!

---

👋 Join us on Discord - OpenSRE : hang out, contribute, or hunt for features and issues. Everyone's welcome.

[greptile-apps]

Confidence Score: 4/5

[High impact] The PR changes which commits can feed the automatic rolling release and updates a dependency used by the application.

The PR appears safe to merge, with a non-blocking gap in tests for the release guards.

Findings

1.  Disabled guards still pass tests ▶

Summary

This PR narrows automatic rolling releases to successful CI pushes from the same repository and checks that the source commit belongs to main.

• Automatic main builds accept only pushes from this repository that are on main.
• Dependency resolution now keeps oauthlib at version 4.0.1 or newer.
• The lockfile now limits several package dependencies by platform.
• The Neon client no longer creates an unused module logger.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[CI run completes] --> B{Successful same-repository push?}
  B -->|No| C[Skip prepare and publishing]
  B -->|Yes| D[Check out source commit with full history]
  D --> E{Commit belongs to main?}
  E -->|No| F[Stop release]
  E -->|Yes| G[Existing release checks]
  G --> H[Build and publish rolling main release]

Loading

_{Reviews (1) · Last reviewed commit: "fix(security): publish main builds only ..." · Reviewed by Greptile}

[greptile-apps]

Disabled guards still pass tests

The new assertions check only that guard text exists. They still pass if prepare.if gains || true, or if the ancestor check stops exiting on failure. A later edit could disable either release guard while these tests stay green.

Add cases that check the result for a fork PR, a same-repository push, and commits both on and outside main, using the actual workflow expression and shell block.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!