fix: Escape environment names in URL paths across 5 files - #4536
Open
prasanna8585 wants to merge 2 commits into
Open
fix: Escape environment names in URL paths across 5 files#4536prasanna8585 wants to merge 2 commits into
prasanna8585 wants to merge 2 commits into
Conversation
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
requested changes
Sep 10, 2026
gmlewis
left a comment
Collaborator
There was a problem hiding this comment.
All modified methods need to have their comments updated so that they explicitly state that path escaping is being performed for the user.
Codecov Report✅ All modified and coverable lines are covered by tests. 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. 🚀 New features to boost your workflow:
|
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
approved these changes
Sep 11, 2026
gmlewis
left a comment
Collaborator
There was a problem hiding this comment.
Thank you, @prasanna8585!
LGTM.
Awaiting second LGTM+Approval from any other contributor to this repo before merging.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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, orenv):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 tou, 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 testcould 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 forbranchthroughout repos.go and forbranchin 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/.