Main #14
Assignees
d (Danila Fominykh)
Clear assignees
d (Danila Fominykh)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: x/m8sh#14
Reference in New Issue
Block a user
merge upstream
eslint-plugin-github(#38046) 804b9bf120Fixes five N+1 / O(n) query patterns found across common user paths. Each uses a bulk query that already existed elsewhere in the codebase. | Location | Problem | Introduced in | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | ------------- | | `IssueList.LoadIsRead` | `.In("issue_id")` missing its arg — xorm generates `WHERE 0=1`, so `IsRead` is **never** set; every issue always appears unread | #29515 | | `ParseCommitsWithStatus` | `GetLatestCommitStatus` called once per commit (O(n) queries on commit list / PR commits tab) | #33605 | | `getReleaseInfos` (release list) | `GetLatestCommitStatus` called once per release for CI badges | #29149 | | User milestone dashboard | O(n×m) nested loop matching milestones to repos | #26300 | | `findCodeComments` (PR diff) | `LoadResolveDoer` + `LoadReactions` called per inline comment — up to ~150 queries on a PR with 50 comments | #20821 | --------- Co-authored-by: Lauris B <lauris@nix.lv>jobs.<job_id>.continue-on-error(#38100) 7684221ed4### What `GetActionsUserRepoPermission` (`models/perm/access/repo_permission.go`) decides whether an Actions task token may access a target repo. Its cross-repo branches each enforce a fork-PR discriminator — except the collaborative-owner branch, which was missing the `!task.IsForkPullRequest` guard that its sibling `checkSameOwnerCrossRepoAccess` has. As a result, when a private repo **B** lists owner **A** as a collaborative owner, an attacker-controlled fork pull-request workflow whose base repo is owned by A was granted code-read on B — i.e. the fork's workflow could clone a third private repository it has no rights to (read-only confidentiality breach). ### Fix Add the same fork-PR guard the sibling path already enforces: ```go if taskRepo.IsPrivate && !task.IsForkPullRequest { actionsUnit := repo.MustGetUnit(ctx, unit.TypeActions) if actionsUnit.ActionsConfig().IsCollaborativeOwner(taskRepo.OwnerID) { return maxPerm, nil } } ```The repository commits API (`GET /repos/{owner}/{repo}/commits`) accepts `since` and `until` query parameters and filters the returned page of commits by commit date. However, the `X-Total-Count` and `X-Total` response headers reported the *unfiltered* total number of commits, so the advertised total could be far larger than the number of commits actually returned for the requested date range. With a range that matches no commits, the page is correctly empty while the headers still claim the full repository total. ## Root cause `gitrepo.CommitsCount` declared `Since` and `Until` options and the API handler populated them, but the function never appended `--since`/`--until` to the underlying `git rev-list --count` invocation. The date filters were silently dropped, so the count always reflected the entire revision history. ## Fix Pass the `Since`/`Until` options through to `git rev-list`, mirroring the existing commit-listing path (`commitsByRangeWithTime`). The reported total now matches the filtered range used to build the page. ## Testing Added `TestCommitsCountWithSinceUntil` in `modules/gitrepo/commit_test.go`, a table-driven unit test against the `repo1_bare` fixture covering `since`, `until`, and a bounded `since`+`until` range. It fails on the pre-fix code (every case returns the full count of 3) and passes after the change. Existing `CommitsCount` tests remain green. ## Notes - No new settings, no default changes; this corrects an incorrect header value and is backward compatible. Clients that depend on `since`/`until` already filter the returned commits, and the headers now agree with that filtering. Fixes #35886. --- *AI-assistance disclosure:* this change was developed with the assistance of Claude Code (Claude Opus 4.8). I have reviewed and understand the change and take responsibility for it.The `release-nightly-snapcraft` workflow’s `build-and-publish` job was failing because `snapcraft remote-build` fell back to interactive Launchpad authorization in CI. This change makes authentication explicit and non-interactive before the remote build step. - **Workflow change** - Add an `Authenticate snapcraft` step before `Remote build`. - Run `snapcraft login --with` using the existing `SNAPCRAFT_STORE_CREDENTIALS` secret. - Pin that step to `shell: bash` to support process substitution. - **Why this fixes the failure** - Prevents CI from entering browser-based Launchpad auth flow. - Ensures `remote-build` runs with preloaded credentials. ```yaml - name: Authenticate snapcraft shell: bash env: SNAPCRAFT_STORE_CREDENTIALS: ${{ secrets.SNAPCRAFT_STORE_CREDENTIALS }} run: snapcraft login --with <(printf '%s' "$SNAPCRAFT_STORE_CREDENTIALS") ``` --------- Signed-off-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>disable-2facommand (#38275) 67a6bd7fc0vue-bar-graphdependency with inlined SVG chart (#38292) e8654c7e06go-swaggerto v0.35.0 and enforce zero swagger warnings (#38299) 638e4bce09armhfbuild (#38311) c6184ed184eslint-plugin-unicornto v70 (#38310) e8d2c493bbDraft-release access control was enforced only on the API release endpoints (`/api/v1/repos/{owner}/{repo}/releases/...`) but not on the UUID-based web attachment endpoints (`/attachments/{uuid}`, `/{owner}/{repo}/attachments/{uuid}`, `/{owner}/{repo}/releases/attachments/{uuid}`). Anyone who obtained an attachment UUID — including unauthenticated callers — could download files belonging to a hidden draft release, since `ServeAttachment` only checked repo-level read permission and never the release's draft state.FileInfoinTestInitKeys(#38330) 2c2691b969FetchTask(#38343) e797a27d4ebranch-nameoption forDEFAULT_TITLE_SOURCE(#38356) 2b89e2ac97- **Locale DoS:** the `Locale` middleware passed the raw `Accept-Language` header to `ParseAcceptLanguage`, whose guard only counts `-` while the scanner aliases `_` to `-` — a large `_`-separated header on an unauthenticated request burned CPU. The header is now length-bounded before parsing. - **Public-only token scope:** `GET /teams/{id}/repos`, `.../repos/{org}/{repo}`, `/teams/{id}/activities/feeds`, and `/users/{username}/orgs/{org}/permissions` still returned private repo/activity/permission data to a public-only token. They now filter via `TokenCanAccessRepo` / `ApplyPublicOnly` and reject non-public org permissions. - **Push-option visibility:** `repo.private` / `repo.template` push options were applied to any existing repo, letting an owner/admin silently flip visibility bypassing audit, webhooks, and notifications. They are now honored only on push-to-create.github.eventfor scheduled runs (#38446) 0e4d93537acancelled()work in jobifevaluation (#38495) 2e0aa7ec74A `workflow_dispatch` job that has `needs:` **and** an `if:` comparing a boolean input against a boolean literal never runs — it stays `Blocked` forever even though its needs succeed. Minimal repro: ```yaml on: workflow_dispatch: inputs: deploy: type: boolean default: true jobs: build: runs-on: ubuntu-latest steps: [{ run: echo build }] deploy: needs: build if: ${{ inputs.deploy == true }} # never true on Gitea runs-on: ubuntu-latest steps: [{ run: echo deploy }] ``` On GitHub this runs; on Gitea `deploy` is stuck. Jobs **without** `needs` are unaffected, which makes it look like a matrix/`needs` bug — it isn't. ## Root cause `workflow_dispatch` stores boolean inputs as the strings `"true"`/`"false"` (`ctx.FormBool` → `strconv.FormatBool` in the web path, plain strings in the API path). Since #37478 (shipped in **v1.27.0**), `evaluateJobIf` runs **server-side** as part of the job-emitter resolver passes. For a `needs`-gated job the server therefore evaluates `inputs.deploy == true` with `inputs.deploy` being the string `"true"`; comparing a string to a boolean coerces to `NaN == 1` → `false`, so the job is never dispatched. Jobs without `needs` skip this server-side gate and are evaluated by the runner, which coerces the string to a real bool — that's why they keep working, and why the same input yields opposite results in the two paths. ## Fix Normalize `type: boolean` dispatch inputs to native JSON booleans in the shared `DispatchActionWorkflow` path, so it covers both the web and API entry points in one place. The coerced value flows into both the run's `EventPayload` (read back by the server-side `if` evaluation and by the runner) and the creation-time parse, so all consumers agree. This matches GitHub, whose `inputs` context "preserves Boolean values as Booleans instead of converting them to strings", and mirrors the native JSON types Gitea already sends for `workflow_call`. Only booleans are coerced; other input types are left untouched, and a value that is already a bool (JSON API request) passes through. Note: this makes dispatch payloads carry native booleans, which the runner consumes correctly as of gitea/runner#1087 (it accepts a native bool and keeps the string fallback) — the same expectation `workflow_call` already relies on. Fixes https://github.com/go-gitea/gitea/issues/38466Pull request closed