Skip to content

fix: Escape environment names in URL paths across 5 files - #4536

Open
prasanna8585 wants to merge 2 commits into
google:masterfrom
prasanna8585:fix/escape-environment-names-in-url-paths
Open

fix: Escape environment names in URL paths across 5 files#4536
prasanna8585 wants to merge 2 commits into
google:masterfrom
prasanna8585:fix/escape-environment-names-in-url-paths

Conversation

@prasanna8585

@prasanna8585 prasanna8585 commented Sep 10, 2026

Copy link
Copy Markdown

A sibling gap to the branch-name escaping fix in ListRulesForBranch (#4534): every method that takes a GitHub "environment name" and embeds it into a request path via fmt.Sprintf did so without url.PathEscape, unlike every branch-name usage in repos.go, which already escapes consistently.

GitHub environment names, like branch names, are free-form strings set by the repository owner (e.g. "staging", "team/staging") with no character restriction comparable to the one GitHub's own naming rules place on owner/repo segments. An environment name containing a / is silently reinterpreted as additional path segments rather than staying part of the environment-name segment, redirecting the request to a different, unintended path under the caller's own GitHub credentials.

Fixed 23 call sites across 5 files, all mapping to the same underlying REST resource shape (/repos/{owner}/{repo}/environments/{environment_name}/...), just with a different local parameter name per file (name, environment, or env):

  • github/repos_environments.go (3 sites: GetEnvironment, CreateUpdateEnvironment, DeleteEnvironment)
  • github/repos_deployment_branch_policies.go (5 sites)
  • github/repos_deployment_protection_rules.go (5 sites)
  • github/actions_secrets.go (5 sites)
  • github/actions_variables.go (5 sites)

One incidental fix needed along the way: ActionsService.GetEnvPublicKey in actions_secrets.go named its own local URL-path variable url, which would have shadowed the newly-imported net/url package within that function's scope. Renamed the local variable to u, matching the convention used by every other method in these files; no behavior change beyond that rename.

Verified: gofmt -l reports no issues on all 10 touched files (5 source, 5 test). Full go build/go test could not be run in this environment (this module's go.mod requires go >= 1.26, network egress to proxy.golang.org for module downloads is unavailable here), so this depends on CI to confirm compilation and test results; the change itself is a mechanical, well-precedented pattern (matching url.PathEscape usage already established for branch throughout repos.go and for branch in this same PR's own ListRulesForBranch fix), and every modified call site and its surrounding function was reviewed by hand for correct variable references.

Added one escape-path regression test per file (5 new tests total), following the same table-driven pattern PR #4534 established for ListRulesForBranch: each asserts both the escaped wire-format request path (r.URL.EscapedPath()) and the decoded path (r.URL.Path) for a plain environment name and one containing a /.

A sibling gap to the branch-name escaping fix in ListRulesForBranch
(google#4534): every method that takes a GitHub "environment name" and embeds
it into a request path via fmt.Sprintf did so without url.PathEscape,
unlike every branch-name usage in repos.go, which already escapes
consistently.

GitHub environment names, like branch names, are free-form strings set
by the repository owner (e.g. "staging", "team/staging") with no
character restriction comparable to the one GitHub's own naming rules
place on owner/repo segments. An environment name containing a `/` is
silently reinterpreted as additional path segments rather than staying
part of the environment-name segment, redirecting the request to a
different, unintended path under the caller's own GitHub credentials.

Fixed 23 call sites across 5 files, all mapping to the same underlying
REST resource shape (`/repos/{owner}/{repo}/environments/{environment_name}/...`),
just with a different local parameter name per file (`name`, `environment`,
or `env`):

  - github/repos_environments.go (3 sites: GetEnvironment,
    CreateUpdateEnvironment, DeleteEnvironment)
  - github/repos_deployment_branch_policies.go (5 sites)
  - github/repos_deployment_protection_rules.go (5 sites)
  - github/actions_secrets.go (5 sites)
  - github/actions_variables.go (5 sites)

One incidental fix needed along the way: ActionsService.GetEnvPublicKey
in actions_secrets.go named its own local URL-path variable `url`,
which would have shadowed the newly-imported net/url package within
that function's scope. Renamed the local variable to `u`, matching the
convention used by every other method in these files; no behavior
change beyond that rename.

Verified: gofmt -l reports no issues on all 10 touched files (5 source,
5 test). Full `go build`/`go test` could not be run in this environment
(this module's go.mod requires go >= 1.26, network egress to
proxy.golang.org for module downloads is unavailable here), so this
depends on CI to confirm compilation and test results; the change
itself is a mechanical, well-precedented pattern (matching url.PathEscape
usage already established for `branch` throughout repos.go and for
`branch` in this same PR's own ListRulesForBranch fix), and every
modified call site and its surrounding function was reviewed by hand for
correct variable references.

Added one escape-path regression test per file (5 new tests total),
following the same table-driven pattern PR google#4534 established for
ListRulesForBranch: each asserts both the escaped wire-format request
path (`r.URL.EscapedPath()`) and the decoded path (`r.URL.Path`) for a
plain environment name and one containing a `/`.
@gmlewis gmlewis changed the title fix: escape environment names in URL paths across 5 files fix: Escape environment names in URL paths across 5 files Sep 10, 2026

@gmlewis gmlewis left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All modified methods need to have their comments updated so that they explicitly state that path escaping is being performed for the user.

@codecov

codecov Bot commented Sep 10, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.54%. Comparing base (9b114ec) to head (b28e04f).
⚠️ Report is 4 commits behind head on master.

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #4536   +/-   ##
=======================================
  Coverage   98.53%   98.54%           
=======================================
  Files         195      196    +1     
  Lines       17875    17938   +63     
=======================================
+ Hits        17614    17677   +63     
  Misses        261      261           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Addresses gmlewis's review: all 23 modified methods across the 5 files
touched by this PR now explicitly state, in their doc comment, that the
environment name is URL path escaped for the caller -- matching the
exact wording and placement already used for the branch parameter in
ListRulesForBranch (PR google#4534):

  // Note: the environment name is URL path escaped for you. See: https://pkg.go.dev/net/url#PathEscape .

Placed directly after each method's one-line summary and before its
"GitHub API docs:" line, consistent with the branch-name precedent.

No logic changed -- doc comments only.
@gmlewis gmlewis added the NeedsReview PR is awaiting a review before merging. label Sep 11, 2026

@gmlewis gmlewis left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, @prasanna8585!
LGTM.
Awaiting second LGTM+Approval from any other contributor to this repo before merging.

cc: @stevehipwell - @Not-Dhananjay-Mishra

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

NeedsReview PR is awaiting a review before merging.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants