security: repo-flags endpoints build API paths with raw, unescaped segments #711
Labels
No labels
breaking
bug
documentation
enhancement
epic
good first issue
help wanted
refactoring
resolution/duplicate
resolution/invalid
resolution/wontfix
security
severity/critical
severity/high
severity/low
severity/medium
status/abandoned
status/blocked
status/needs-decision
status/needs-info
status/needs-verification
testing
upstream
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Blocks
Reference
sixfold-space/madtea#711
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What happens
The repo-flags client builds its API paths with raw
fmt.Sprintf, not the segment-wise escaping the other builders use. Ininternal/gitea/client_repo_flags.go,ListRepoFlags(:18),GetRepoFlag(:24),AddRepoFlag(:30), andRemoveRepoFlag(:36) each interpolateowner,repo, andflagdirectly, e.g.fmt.Sprintf("/repos/%s/%s/flags/%s", owner, repo, flag). Every other request-path builder routes its segments through the package'sescapePath(segment-wiseurl.PathEscape); this family was missed.Scope
Same-origin path reshaping only; the repo-scope boundary is unaffected. Hygiene. Per the #708 sweep this is the one raw request-path builder left after the rest were migrated. The fix is non-breaking: escaping a slug with no special characters is a no-op.
Fix (direction)
Route
owner,repo, andflagthroughescapePath, as the sibling builders do.Acceptance criteria
hexajon referenced this issue2026-10-05 12:34:16 +00:00