Merge remote-tracking branch 'upstream/main'

Author: kasbah

.drone.yml

@@ -39,16 +39,6 @@ steps:
       - make lint-frontend
     depends_on: [deps-frontend]
 
-  - name: security-check
-    image: golang:1.19
-    pull: always
-    commands:
-      - make security-check
-    depends_on: [deps-backend]
-    volumes:
-      - name: deps
-        path: /go
-
   - name: lint-backend
     image: gitea/test_env:linux-amd64  # https://gitea.com/gitea/test-env
     pull: always

.eslintrc.yaml

@@ -199,7 +199,7 @@ rules:
   newline-per-chained-call: [0]
   no-alert: [0]
   no-array-constructor: [2]
-  no-async-promise-executor: [2]
+  no-async-promise-executor: [0]
   no-await-in-loop: [0]
   no-bitwise: [0]
   no-buffer-constructor: [0]

Makefile

@@ -333,7 +333,7 @@ checks: checks-frontend checks-backend
 checks-frontend: lockfile-check svg-check
 
 .PHONY: checks-backend
-checks-backend: tidy-check swagger-check fmt-check misspell-check swagger-validate
+checks-backend: tidy-check swagger-check fmt-check misspell-check swagger-validate security-check
 
 .PHONY: lint
 lint: lint-frontend lint-backend
@@ -745,7 +745,7 @@ generate-go: $(TAGS_PREREQ)
 
 .PHONY: security-check
 security-check:
-	govulncheck -v ./...
+	go run $(GOVULNCHECK_PACKAGE) -v ./...
 
 $(EXECUTABLE): $(GO_SOURCES) $(TAGS_PREREQ)
 	CGO_CFLAGS="$(CGO_CFLAGS)" $(GO) build $(GOFLAGS) $(EXTRA_GOFLAGS) -tags '$(TAGS)' -ldflags '-s -w $(LDFLAGS)' -o $@

cmd/admin.go

@@ -727,7 +727,7 @@ func runRepoSyncReleases(_ *cli.Context) error {
 
 	log.Trace("Synchronizing repository releases (this may take a while)")
 	for page := 1; ; page++ {
-		repos, count, err := repo_model.SearchRepositoryByName(&repo_model.SearchRepoOptions{
+		repos, count, err := repo_model.SearchRepositoryByName(ctx, &repo_model.SearchRepoOptions{
 			ListOptions: db.ListOptions{
 				PageSize: repo_model.RepositoryListDefaultPageSize,
 				Page:     page,

custom/conf/app.example.ini

@@ -2234,7 +2234,9 @@ ROUTER = console
 ;; Show template execution time in the footer
 ;SHOW_FOOTER_TEMPLATE_LOAD_TIME = true
 ;; Generate sitemap. Defaults to `true`.
-; ENABLE_SITEMAP = true
+;ENABLE_SITEMAP = true
+;; Enable/Disable RSS/Atom feed
+;ENABLE_FEED = true
 
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

docs/content/doc/advanced/config-cheat-sheet.en-us.md

@@ -289,8 +289,13 @@ The following configuration set `Content-Type: application/vnd.android.package-a
    This includes CSS files, images, JS files and web fonts.
    Avatar images are dynamic resources and still served by Gitea.
    The option can be just a different path, as in `/static`, or another domain, as in `https://cdn.example.com`.
-   Requests are then made as `%(ROOT_URL)s/static/css/index.css` and `https://cdn.example.com/css/index.css` respective.
+   Requests are then made as `%(ROOT_URL)s/static/assets/css/index.css` or `https://cdn.example.com/assets/css/index.css` respectively.
    The static files are located in the `public/` directory of the Gitea source repository.
+   You can proxy the STATIC_URL_PREFIX requests to Gitea server to serve the static
+   assets, or copy the manually built Gitea assets from `$GITEA_BUILD/public` to
+   the assets location, eg: `/var/www/assets`, make sure `$STATIC_URL_PREFIX/assets/css/index.css`
+   points to `/var/www/assets/css/index.css`.
+
 - `HTTP_ADDR`: **0.0.0.0**: HTTP listen address.
   - If `PROTOCOL` is set to `fcgi`, Gitea will listen for FastCGI requests on TCP socket
      defined by `HTTP_ADDR` and `HTTP_PORT` configuration settings.
@@ -1283,3 +1288,4 @@ PROXY_HOSTS = *.github.com
 - `SHOW_FOOTER_VERSION`: **true**: Show Gitea and Go version information in the footer.
 - `SHOW_FOOTER_TEMPLATE_LOAD_TIME`: **true**: Show time of template execution in the footer.
 - `ENABLE_SITEMAP`: **true**: Generate sitemap.
+- `ENABLE_FEED`: **true**: Enable/Disable RSS/Atom feed.

docs/content/doc/advanced/repo-mirror.en-us.md

@@ -41,13 +41,15 @@ For an existing remote repository, you can set up pull mirroring as follows:
 
 The repository now gets mirrored periodically from the remote repository. You can force a sync by selecting **Synchronize Now** in the repository settings.
 
+:exclamation::exclamation: **NOTE:** You can only set up pull mirroring for repos that don't exist yet on your instance. Once the repo is created, you can't convert it into a pull mirror anymore. :exclamation::exclamation:
+
 ## Pushing to a remote repository
 
 For an existing repository, you can set up push mirroring as follows:
 
 1. In your repository, go to **Settings** > **Repository**, and then the **Mirror Settings** section.
 2. Enter a repository URL.
-3. If the repository needs authentication expand the **Authorization** section and fill in your authentication information.
+3. If the repository needs authentication expand the **Authorization** section and fill in your authentication information. Note that the requested **password** can also be your access token.
 4. Select **Add Push Mirror** to save the configuration.
 
 The repository now gets mirrored periodically to the remote repository. You can force a sync by selecting **Synchronize Now**. In case of an error a message displayed to help you resolve it.
@@ -59,9 +61,11 @@ The repository now gets mirrored periodically to the remote repository. You can
 To set up a mirror from Gitea to GitHub, you need to follow these steps:
 
 1. Create a [GitHub personal access token](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token) with the *public_repo* box checked.
-2. Fill in the **Git Remote Repository URL**: `https://github.com/<your_github_group>/<your_github_project>.git`.
-3. Fill in the **Authorization** fields with your GitHub username and the personal access token.
-4. Select **Add Push Mirror** to save the configuration.
+2. Create a repository with that name on GitHub. Unlike Gitea, GitHub does not support creating repositories by pushing to the remote. You can also use an existing remote repo if it has the same commit history as your Gitea repo.
+3. In the settings of your Gitea repo, fill in the **Git Remote Repository URL**: `https://github.com/<your_github_group>/<your_github_project>.git`.
+4. Fill in the **Authorization** fields with your GitHub username and the personal access token as **Password**.
+5. (Optional, available on Gitea 1.18+) Select `Sync when new commits are pushed` so that the mirror will be updated as well as soon as there are changes. You can also disable the periodic sync if you like.
+6. Select **Add Push Mirror** to save the configuration.
 
 The repository pushes shortly thereafter. To force a push, select the **Synchronize Now** button.
 

docs/content/doc/features/authentication.en-us.md

@@ -166,11 +166,47 @@ Uses the following fields:
 
 ## PAM (Pluggable Authentication Module)
 
-To configure PAM, set the 'PAM Service Name' to a filename in `/etc/pam.d/`. To
-work with normal Linux passwords, the user running Gitea must have read access
-to `/etc/shadow`.
-
-**Note**: PAM support is added via [build-time flags](https://docs.gitea.io/en-us/install-from-source/#build), and the official binaries provided do not have this enabled.
+This procedure enables PAM authentication.  Users may still be added to the
+system manually using the user administration.  PAM provides a mechanism to
+automatically add users to the current database by testing them against PAM
+authentication.  To work with normal Linux passwords, the user running Gitea
+must also have read access to `/etc/shadow` in order to check the validity of
+the account when logging in using a public key.
+
+**Note**: If a user has added SSH public keys into Gitea, the use of these
+keys _may_ bypass the login check system.  Therefore, if you wish to disable a user who
+authenticates with PAM, you _should_ also manually disable the account in Gitea using the
+built-in user manager.
+
+1. Configure and prepare the installation.
+    - It is recommended that you create an administrative user.
+    - Deselecting automatic sign-up may also be desired.
+1. Once the database has been initialized, log in as the newly created
+administrative user.
+1. Navigate to the user setting (icon in top-right corner), and select
+`Site Administration` -> `Authentication Sources`, and select
+`Add Authentication Source`.
+1. Fill out the field as follows:
+    - `Authentication Type` : `PAM`
+    - `Name` : Any value should be valid here, use "System Authentication" if
+    you'd like.
+    - `PAM Service Name` : Select the appropriate file listed under `/etc/pam.d/`
+    that performs the authentication desired.[^1]
+    - `PAM Email Domain` : The e-mail suffix to append to user authentication.
+    For example, if the login system expects a user called `gituser`, and this
+    field is set to `mail.com`, then Gitea will expect the `user email` field
+    for an authenticated GIT instance to be `gituser@mail.com`.[^2]
+
+**Note**: PAM support is added via [build-time flags](https://docs.gitea.io/en-us/install-from-source/#build),
+and the official binaries provided do not have this enabled.  PAM requires that
+the necessary libpam dynamic library be available and the necessary PAM
+development headers be accessible to the compiler.
+
+[^1]: For example, using standard Linux log-in on Debian "Bullseye" use
+`common-session-noninteractive` - this value may be valid for other flavors of
+Debian including Ubuntu and Mint, consult your distribution's documentation.
+[^2]: **This is a required field for PAM**.  Be aware: In the above example, the
+user will log into the Gitea web interface as `gituser` and not `gituser@mail.com`
 
 ## SMTP (Simple Mail Transfer Protocol)
 

docs/content/doc/installation/from-source.en-us.md

@@ -94,7 +94,7 @@ are provided to keep the build process as simple as possible.
 
 Depending on requirements, the following build tags can be included.
 
-- `bindata`: Build a single monolithic binary, with all assets included.
+- `bindata`: Build a single monolithic binary, with all assets included. Required for production build.
 - `sqlite sqlite_unlock_notify`: Enable support for a
   [SQLite3](https://sqlite.org/) database. Suggested only for tiny
   installations.
@@ -103,11 +103,10 @@ Depending on requirements, the following build tags can be included.
   available to PAM.
 - `gogit`: (EXPERIMENTAL) Use go-git variants of Git commands.
 
-Bundling assets into the binary using the `bindata` build tag is recommended for
-production deployments. It is possible to serve the static assets directly via a reverse proxy,
-but in most cases it is not necessary, and assets should still be bundled in the binary.
-You may want to exclude bindata while developing/testing Gitea.
-To include assets, add the `bindata` tag:
+Bundling all assets (JS/CSS/templates, etc) into the binary. Using the `bindata` build tag is required for
+production deployments. You could exclude `bindata` when you are developing/testing Gitea or able to separate the assets correctly.
+
+To include all assets, use the `bindata` tag:
 
 ```bash
 TAGS="bindata" make build

docs/content/doc/packages/storage.en-us.md

@@ -0,0 +1,84 @@
+---
+date: "2022-11-01T00:00:00+00:00"
+title: "Storage"
+slug: "packages/storage"
+draft: false
+toc: false
+menu:
+  sidebar:
+    parent: "packages"
+    name: "storage"
+    weight: 5
+    identifier: "storage"
+---
+
+# Storage
+
+This document describes the storage of the package registry and how it can be managed.
+
+**Table of Contents**
+
+{{< toc >}}
+
+## Deduplication
+
+The package registry has a build-in deduplication of uploaded blobs.
+If two identical files are uploaded only one blob is saved on the filesystem.
+This ensures no space is wasted for duplicated files.
+
+If two packages are uploaded with identical files, both packages will display the same size but on the filesystem they require only half of the size.
+Whenever a package gets deleted only the references to the underlaying blobs are removed.
+The blobs get not removed at this moment, so they still require space on the filesystem.
+When a new package gets uploaded the existing blobs may get referenced again.
+
+These unreferenced blobs get deleted by a [clean up job]({{< relref "doc/advanced/config-cheat-sheet.en-us.md#cron---cleanup-expired-packages-croncleanup_packages" >}}).
+The config setting `OLDER_THAN` configures how long unreferenced blobs are kept before they get deleted.
+
+## Cleanup Rules
+
+Package registries can become large over time without cleanup.
+It's recommended to delete unnecessary packages and set up cleanup rules to automatically manage the package registry usage.
+Every package owner (user or organization) manages the cleanup rules which are applied to their packages.
+
+|Setting|Description|
+|-|-|
+|Enabled|Turn the cleanup rule on or off.|
+|Type|Every rule manages a specific package type.|
+|Apply pattern to full package name|If enabled, the patterns below are applied to the full package name (`package/version`). Otherwise only the version (`version`) is used.|
+|Keep the most recent|How many versions to *always* keep for each package.|
+|Keep versions matching|The regex pattern that determines which versions to keep. An empty pattern keeps no version while `.+` keeps all versions. The container registry will always keep the `latest` version even if not configured.|
+|Remove versions older than|Remove only versions older than the selected days.|
+|Remove versions matching|The regex pattern that determines which versions to remove. An empty pattern or `.+` leads to the removal of every package if no other setting tells otherwise.|
+
+Every cleanup rule can show a preview of the affected packages.
+This can be used to check if the cleanup rules is proper configured.
+
+### Regex examples
+
+Regex patterns are automatically surrounded with `\A` and `\z` anchors.
+Do not include any `\A`, `\z`, `^` or `$` token in the regex patterns as they are not necessary.
+The patterns are case-insensitive which matches the behaviour of the package registry in Gitea.
+
+|Pattern|Description|
+|-|-|
+|`.*`|Match every possible version.|
+|`v.+`|Match versions that start with `v`.|
+|`release`|Match only the version `release`.|
+|`release.*`|Match versions that are either named or start with `release`.|
+|`.+-temp-.+`|Match versions that contain `-temp-`.|
+|`v.+\|release`|Match versions that either start with `v` or are named `release`.|
+|`package/v.+\|other/release`|Match versions of the package `package` that start with `v` or the version `release` of the package `other`. This needs the setting *Apply pattern to full package name* enabled.|
+
+### How the cleanup rules work
+
+The cleanup rules are part of the [clean up job]({{< relref "doc/advanced/config-cheat-sheet.en-us.md#cron---cleanup-expired-packages-croncleanup_packages" >}}) and run periodicly.
+
+The cleanup rule:
+
+1. Collects all packages of the package type for the owners registry.
+1. For every package it collects all versions.
+1. Excludes from the list the # versions based on the *Keep the most recent* value.
+1. Excludes from the list any versions matching the *Keep versions matching* value.
+1. Excludes from the list the versions more recent than the *Remove versions older than* value.
+1. Excludes from the list any versions not matching the *Remove versions matching* value.
+1. Deletes the remaining versions.