Backport #38956 by @bircni
Fixes https://github.com/go-gitea/gitea/issues/38950
`POST /-/web-theme/apply` used the `optSignIn` middleware, which forces
sign-in when `REQUIRE_SIGNIN_VIEW` is enabled. This made theme switching
unusable for anonymous users (e.g. on the sign-in page), even though the
handler already supports anonymous users by storing the choice in a
cookie.
This was an unintended regression from
https://github.com/go-gitea/gitea/pull/36183, which replaced the route's
CSRF-only middleware with `optSignIn`, incidentally pulling in the
sign-in requirement meant for content routes.
The fix drops the sign-in requirement for this route while keeping
cross-origin protection and the usual signed-in-user checks
(inactive/prohibited login, forced password change).
Co-authored-by: bircni <bircni@icloud.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Backport #38893 by @HsukqiLee
Closes#38872
Labels in the label selection dropdown (issue/PR sidebar, new issue
form) were always listed alphabetically, so a scoped set like the
default Priority labels showed up as Critical, High, Low, Medium even
though each label carries an exclusive order.
This adds `CompareLabelForDisplay`/`SortLabelsForDisplay` in
`models/issues`: labels are grouped by their exclusive scope and sorted
by exclusive order within a scope (unordered ones last), falling back to
name order. The sorting is applied to the issue page sidebar data and
the shared label filter data, so the filter dropdown on the issue list
gets the same ordering.
Unscoped labels are unaffected and still sort by name. Includes a unit
test covering the default Priority label set.
Co-authored-by: Hsukqi Lee <team@tsinbei.com>
Backport #38935 by @bircni
The dashboard activity feed was paginated with `[ui.user]
REPO_PAGING_NUM`
instead of `[ui] FEED_PAGING_NUM`.
The wrong setting was picked up when the page size was hoisted into a
local
variable in https://github.com/go-gitea/gitea/pull/34994, most likely
copied
from the `dashboardRepoList` block a few lines above. `REPO_PAGING_NUM`
should
only control repository lists.
Fixes https://github.com/go-gitea/gitea/issues/38925
Co-authored-by: bircni <bircni@icloud.com>
Backport #38928 to `release/v1.27`.
The automatic backport failed because `release/v1.27` still pins an
older `aws-actions/configure-aws-credentials` SHA, so the change is
applied manually here.
Release binaries have been served from Cloudflare R2 for a while, so the
`configure aws` and `upload binaries to s3` steps are removed from the
nightly, RC and version release workflows. Since
`configure-aws-credentials` no longer runs in those jobs, the
`AWS_REGION: auto` workaround in the R2 step is dropped as well.
Backport #38880 by @lunny
This is a prepare and required step for upcoming Gitea Official Mobile
APP which supports login with OAuth2.
Gitea already pre-registers OAuth2 applications for a few universally
useful clients (`git-credential-oauth`, Git Credential Manager and
`tea`), so those tools can run an Authorization Code + PKCE login
against any instance without the user having to create an OAuth
application by hand.
The official Gitea mobile app needs the same mechanism. This adds a
builtin application for it:
| | |
|---|---|
| client ID | `b757811a-05c8-4c76-8d74-a5ee3d2073f2` |
| config name | `gitea-app` |
| display name | `Gitea App` |
| redirect URI | `com.gitea.app://oauth/callback` |
Unlike the existing entries, which are CLIs and can therefore use a
loopback `http://127.0.0.1` redirect, a mobile app authorises through a
system browser session (`ASWebAuthenticationSession` on iOS, Custom Tabs
on Android) that can only receive a custom-scheme callback, hence the
custom scheme here.
Notes:
* Builtin applications are inserted directly by `auth.Init`, so they do
not pass through `DetectInvalidOAuth2ApplicationRedirectURI`, which is
only applied to user- and API-created applications. No `[oauth2]
CUSTOM_SCHEMES` configuration is required for this to work, and
`ContainsRedirectURI` matches the URI by normalised string comparison.
* Instances that do not want the application pre-registered can drop
`gitea-app` from `[oauth2] DEFAULT_APPLICATIONS`, exactly as with the
existing entries; `auth.Init` then deletes it again.
* The client is public: no client secret, PKCE `S256` required.
---
Generated by Codet
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Backport #38899
`github.event.inputs` must mirror the raw `workflow_dispatch` payload,
where
GitHub keeps every input as a string. Only the separate `inputs` context
preserves declared types, e.g. booleans. A previous fix coerced boolean
inputs in the single map that fed both contexts, so
`github.event.inputs.someBool` became a real boolean and comparisons
like
`== 'true'` stopped matching.
`github.event.inputs` now stays string-only again. The `inputs` context
used
for server-side `if:` evaluation of needs-gated/matrix-deferred jobs
re-coerces booleans independently, from the job's own workflow
declaration,
so that path keeps working correctly.
Fixes https://github.com/go-gitea/gitea/issues/38896
Backport #38857Fixes#38773
## Background
Artifacts became attempt-scoped in #37119, and the runner-facing
artifact APIs filter strictly by the attempt of the running job. "Re-run
failed jobs" creates a new attempt whose passed-through jobs never
upload their artifacts again, so a re-run job that downloads one of them
fails with "artifact not found".
## Fix
The read paths (v3 and v4 list and download) now resolve artifacts
across the running job's attempt plus the attempts it inherits from, and
an inherited artifact is shadowed by a same-named one from a newer
attempt.
## Note
GitHub's documentation does not document these behaviors. The
conclusions below are based on manual testing, so consistency with
GitHub cannot be guaranteed.
- In a "partial re-run", a job can download artifacts uploaded by an
earlier attempt, every attempt keeps its own copy of a name, and a
lookup by name resolves to the newest one.
- A full "Re-run all jobs" never downloads artifacts from earlier
attempts.
Backport #38885 by @wxiaoguang
make the "command variable replacement" more accurate and
OS-independent, add a test for it.
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Backport #38886
For a `pull_request_target` (PRT) run, Gitea loads the top-level
workflow from the trusted base branch, but any local reusable workflow
it calls (`uses: ./...`) was read from the PR **head** commit, which the
fork author controls.
**Record the source commit where the content is read.**
`DetectedWorkflow` now carries a `SourceCommitSHA` filled in next to
`Content`, so the PRT detection pass at the base commit records the base
SHA automatically.
**Defense in depth.** `loadReusableWorkflowSource` pins the PR base
commit for a PRT run's local `uses: ./...` rather than trusting the
stored SHA. This also covers runs recorded before this change, whose
rows still hold the head SHA and would otherwise resolve from the fork
on rerun.
Existing run rows are not migrated.
Co-authored-by: bircni <bircni@icloud.com>
Backport #38826 by @silverwind
The npm packument left `time`, `keywords` and `maintainers` empty
although the data was available. `created` and `modified` are derived
from the versions currently served, as there is no package-level
timestamp to read them from.
Co-authored-by: silverwind <me@silverwind.io>
Backport #38788 by @terriblegoodday
Nested `Package.swift` files overwrote the real package manifest. The
parser matched on the base name and kept the last entry in ZIP order.
`apple/swift-collections` ships `Benchmarks/Package.swift` and
`Utils/Debugger/FormatterFixtures/Package.swift`. The latter sorts after
the root `Package.swift`, so the registry stored a fixture manifest with
the wrong `swift-tools-version`, causing a toolchain mismatch and a
failed build. GRDB, swift-markdown, swift-syntax, sentry-cocoa and
SDWebImage share this layout.
The parser now keeps only manifests from the shallowest directory
holding one. That covers both a package at the archive root and the
single top level directory `swift package archive-source` produces. At
equal depth the first directory by name wins, so an archive always
yields the same metadata.
A nested manifest above the size limit no longer rejects the upload.
Assisted by Claude Opus 5 and Claude Fable.
Co-authored-by: Eduard Dzhumagaliev <ed_dzhumagaliev@icloud.com>
Co-authored-by: silverwind <me@silverwind.io>
Backport #38805
Registration omitted `userVerification`, so Chromium raised the
credential to credProtect level 3 and the authenticator then hid it from
the second-factor login, which asked for `discouraged`. Registration and
each login now set their own value, with `preferred` on the second
factor so credentials already registered at level 3 keep working without
re-enrollment.
Also add relevant e2e test coverage for webauthn, one test is chromium
only because Firefox lacks the APIs needed.
Fixes https://github.com/go-gitea/gitea/issues/33531
Fixes https://github.com/go-gitea/gitea/issues/36019
Fixes https://github.com/go-gitea/gitea/issues/38139
Backport #38102 by @metsw24-max
The arch parser keeps tar member names verbatim. The index writer joins
those values one per line into the pacman database. So a member name
with a newline adds lines to that package's own `files` entry, which
libalpm reads as further fields.
The scope is one package record. An uploader cannot forge entries for
another package, and can set the same fields in `.PKGINFO` anyway. This
is input validation, not a privilege boundary.
`ParsePackage` now drops names that contain CR or LF. `joinFields` drops
such values again when writing the index, which also covers packages
that are already stored. Real packages never carry newlines in file
paths, so well-formed uploads are unaffected.
Co-authored-by: metsw24-max <metsw24@gmail.com>
Co-authored-by: silverwind <me@silverwind.io>
Backport of https://github.com/go-gitea/gitea/pull/38754
Every `${{ }}` part was spliced as raw text into a synthesized
`format('...', <raw>)` call and re-parsed, so unbalanced parentheses
restructured the whole expression:
```yaml
run-name: ${{ 1) && (2 }} # panicked, aborting workflow parsing for the push
if: ${{ 1 }} ${{ 0) && (0 }} # silently skipped the job
runs-on: ${{ nosuchcontext.x }} # silently queued the job against the label ""
```
One scanner shaped like GitHub's template reader now splits every value
and each part is evaluated on its own, so nothing builds an expression
out of text. A part that fails is an error instead of an empty string.
`expressionCallsFunction` is self-contained here, since this branch has
no `expressionsMatch` to build it on. That makes
`github.com/rhysd/actionlint` a direct dependency, which it already is
on `main`.
Backport #38792 by @silverwind
`UpdateTaskByState` wrote the task, its job and its steps in separate
statements. An interruption in between left the task finished with a
running job, so the run stayed in progress, and the "state is final"
early return made every retry, cancel and cleanup a no-op.
Fixes https://github.com/go-gitea/gitea/issues/38790
Co-authored-by: silverwind <me@silverwind.io>
Backport #38753 by @Zettat123
## Background
`MinioStorage.Save` is called with `size = -1` on several paths,
including Actions logs, Actions artifacts, repository archives, avatars
and attachments. With an unknown size (-1) minio-go assumes a 5TiB
object and allocates a single part-sized buffer of 528MiB per upload,
regardless of the real payload size, which can exhaust the memory of
small instances.
Measured against a local S3 stub, five sequential uploads of a 4KiB
payload grew RSS by 1041MiB before the fix and by 34MiB after it.
## Fix
Pass an explicit 16MiB part size in that case, the same value minio-go
uses as minimum part size
(https://github.com/minio/minio-go/blob/v7.2.1/constants.go#L28).
Uploads with a known size are left untouched, since minio-go already
derives a part size proportional to the real object size.
## Note:
One behaviour change: with an unknown size the object is now limited to
16MiB * 10000 parts = 156.25GiB
(https://github.com/minio/minio-go/blob/v7.2.1/api-put-object-common.go#L112-L116).
`putObjectMultipartStreamNoLength` completes the upload once it runs out
of parts without checking that the reader was drained, so a stream past
that limit is silently truncated rather than rejected. The previous
limit was 5TiB. No payload Gitea uploads comes close to either.
Parts are also uploaded serially, so a smaller part size means
proportionally more round trips for large unknown-size uploads.
Co-authored-by: Zettat123 <zettat123@gmail.com>
Co-authored-by: silverwind <me@silverwind.io>
Backport #38707 by @silverwind
`.markup del code { text-decoration: inherit }` makes inline code inside
`<del>` paint its own line-through in addition to the one already
propagating from the parent. Since `code` is `font-size: 85%`, the two
land at different heights and render as a doubled strikethrough.
The rule was inherited from primer-markdown, where it was added in
https://github.com/primer/css/commit/762b8b8264aa4c4beed0a7f842f90c142eb2b310
("so that `<del>` or `<a>` has the same effects on `<code>` tags") at a
time when inline `code` was `display: inline-block`, a box that text
decorations do not propagate into. That `display: inline-block` was
removed 11 days later in
https://github.com/primer/css/commit/f1131d5ab618ac41d4097823b511ca0b373b2ee2,
which made the rule redundant, but it survived the squashed import into
primer/css and every copy downstream of it.
No other popular markdown stylesheet carries an equivalent rule, GitHub
still ships it and shows the same doubled line.
Fixes: https://github.com/go-gitea/gitea/issues/34786
Co-authored-by: silverwind <me@silverwind.io>
Backport #38689
Show only author and co-authors without committer, and deduplicate the
same user with multiple email addresses.
The commit list "Author" column should not show the committer. This is
somewhat misleading, and arguably showing it on the individual commit
page is sufficient and consistent with other forges.
The same user with multiple email addresses often happens when
DEFAULT_KEEP_EMAIL_PRIVATE is enabled and Gitea does not use an actual
email address by default for edits. Showing the same avatar and name
twice is not helpful then.
Ref #37594Fix#38488
Co-authored-by: bircni <bircni@icloud.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Backport #38686 by @waterWang
### Description
Fixes#38676
The Alpine package registry registers for only, so a request returns .
Clients that probe the index with before fetching it (like and other
-based tools) fail outright.
**Fix:** Change to for the APKINDEX.tar.gz route, matching the pattern
already used by the i386 registry a few lines below.
### Related issue
Closes#38676
Co-authored-by: water <672684719@qq.com>
Co-authored-by: waterWang <waterWang@users.noreply.github.com>
Backport #38439 by @Otto-Deviant1904
Fixes#38209
OAuth2-linked accounts that sign in via the password form were still
redirected to the provider end_session_endpoint on logout because the
redirect was keyed off account LoginType.
Store the session sign-in method (password vs oauth2) and only use
RP-initiated OIDC logout when this session was authenticated via OAuth2.
Sessions without the new key keep the previous LoginType behavior.
Co-authored-by: Harsh Satyajit Thakur <f20240223@goa.bits-pilani.ac.in>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Backport #38658 by @lunny
## What to build
Fix the Cloudflare R2 upload steps added in #38635, which currently fail
on every release run:
```
fatal error: An error occurred (InvalidRegionName) when calling the ListObjectsV2 operation:
The region name '***' is not valid. Must be one of: wnam, enam, weur, eeur, apac, oc, auto
```
### Root cause
The `configure-aws-credentials` step earlier in the same job exports
**both** `AWS_DEFAULT_REGION` and `AWS_REGION` into `$GITHUB_ENV`
(verified in `exportRegion()` at the pinned SHA `517a711`), so
`secrets.AWS_REGION` (the real AWS region) stays set for every later
step in that job.
The AWS CLI v2 region resolution order is `--region` > `AWS_REGION` >
`AWS_DEFAULT_REGION`. The R2 step only set `AWS_DEFAULT_REGION: auto`,
so the leaked `AWS_REGION` won and R2 rejected it, since R2 only accepts
`wnam`, `enam`, `weur`, `eeur`, `apac`, `oc` or `auto`.
The failure log shows both `AWS_DEFAULT_REGION: auto` and `AWS_REGION:
***` in the step env, which confirms the leak.
### Fix
Set `AWS_REGION: auto` explicitly in the R2 upload step env of all three
release workflows. Step-level `env:` is applied after
`GITHUB_ENV`-derived variables, so this reliably overrides the leaked
value.
No other variable leaks from `configure-aws-credentials` matter here:
`AWS_SESSION_TOKEN` is only exported when a session token exists, and
these workflows use static access keys without `role-to-assume`;
`AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` are already overridden
in the R2 step.
Consolidating the three duplicated upload steps into a composite action
remains a follow-up, as noted in #38635.
## Acceptance criteria
- [x] `AWS_REGION: auto` set in the R2 upload step of
`release-nightly.yml`, `release-tag-rc.yml` and
`release-tag-version.yml`
- [x] No other behaviour changed; the existing S3 upload steps are
untouched
- [x] All three workflows still pass `actionlint` and YAML parsing
- [ ] The next nightly release run syncs to R2 without
`InvalidRegionName`
## Blocked by
- None -- can start immediately.
---
Generated by Codet
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Backport #38659fix#38652
UI part (`.log-msg`) uses "white-space: break-spaces;" so the new line
can be correctly rendered.
Signed-off-by: silverwind <me@silverwind.io>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: silverwind <me@silverwind.io>
Backport #38636 by @SudhanshuMatrix
Fixes a bug in Actions context generation for `pull_request_target`
workflows where `github.ref` / `gitea.ref` was incorrectly populated
with `refs/heads/owner:branch` instead of `refs/heads/branch`.
### Problem Statement
In `services/actions/context.go`, when constructing the `ref` string for
`pull_request_target` events:
```go
ref = git.BranchPrefix + pullPayload.PullRequest.Base.Name
Signed-off-by: Sudhanshu Singh <sudhanshuwriterblc@gmail.com>
Signed-off-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: Shudhanshu Singh <sudhanshuwriterblc@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Backport #38653 by @Zettat123
The handler of `/actions/runs/{run}/approve` doesn't check if the run is
already approved. If a run is re-approved, its jobs' status will be
reset to `StatusWaiting`, causing incorrect job status.
Co-authored-by: Zettat123 <zettat123@gmail.com>
wxiaoguang