forgejo/routers/api/packages
Gusted 5a871f6095
[SEC] Ensure propagation of API scopes for Conan and Container authentication
- The Conan and Container packages use a different type of
authentication. It first authenticates via the regular way (api tokens
or user:password, handled via `auth.Basic`) and then generates a JWT
token that is used by the package software (such as Docker) to do the
action they wanted to do. This JWT token didn't properly propagate the
API scopes that the token was generated for, and thus could lead to a
'scope escalation' within the Conan and Container packages, read
access to write access.
- Store the API scope in the JWT token, so it can be propagated on
subsequent calls that uses that JWT token.
- Integration test added.
- Resolves #5128
2024-08-28 10:33:32 +02:00
..
alpine Remove hardcoded filenames for better readability 2024-07-17 23:20:48 +02:00
arch feat: support grouping by any path for arch package (#4903) 2024-08-11 10:35:11 +00:00
cargo remove util.OptionalBool and related functions (#29513) 2024-03-06 12:10:46 +08:00
chef remove util.OptionalBool and related functions (#29513) 2024-03-06 12:10:46 +08:00
composer remove util.OptionalBool and related functions (#29513) 2024-03-06 12:10:46 +08:00
conan [SEC] Ensure propagation of API scopes for Conan and Container authentication 2024-08-28 10:33:32 +02:00
conda Enable more revive linter rules (#30608) 2024-04-28 15:39:00 +02:00
container [SEC] Ensure propagation of API scopes for Conan and Container authentication 2024-08-28 10:33:32 +02:00
cran Enable more revive linter rules (#30608) 2024-04-28 15:39:00 +02:00
debian Enable more revive linter rules (#30608) 2024-04-28 15:39:00 +02:00
generic Enable more revive linter rules (#30608) 2024-04-28 15:39:00 +02:00
goproxy Enable more revive linter rules (#30608) 2024-04-28 15:39:00 +02:00
helm remove util.OptionalBool and related functions (#29513) 2024-03-06 12:10:46 +08:00
helper Move context from modules to services (#29440) 2024-03-06 12:10:43 +08:00
maven Ignore useless error message "broken pipe" (#30801) 2024-05-05 12:15:40 +01:00
npm Add support for npm bundleDependencies (#30751) 2024-05-05 08:24:01 +01:00
nuget Enable unparam linter (#31277) 2024-06-16 13:42:58 +02:00
pub Move context from modules to services (#29440) 2024-03-06 12:10:43 +08:00
pypi Move context from modules to services (#29440) 2024-03-06 12:10:43 +08:00
rpm fix: rpm sign resource leak (#4878) 2024-08-08 07:28:09 +00:00
rubygems Add minimal implementation for RubyGems compact index API. (#3811) 2024-05-19 23:30:41 +00:00
swift remove util.OptionalBool and related functions (#29513) 2024-03-06 12:10:46 +08:00
vagrant Move context from modules to services (#29440) 2024-03-06 12:10:43 +08:00
api.go feat: support grouping by any path for arch package (#4903) 2024-08-11 10:35:11 +00:00
README.md Add codespell support and fix a good number of typos with its help (#3270) 2024-05-09 13:49:37 +00:00

Gitea Package Registry

This document gives a brief overview how the package registry is organized in code.

Structure

The package registry code is divided into multiple modules to split the functionality and make code reuse possible.

Module Description
models/packages Common methods and models used by all registry types
models/packages/<type> Methods used by specific registry type. There should be no need to use type specific models.
modules/packages Common methods and types used by multiple registry types
modules/packages/<type> Registry type specific methods and types (e.g. metadata extraction of package files)
routers/api/packages Route definitions for all registry types
routers/api/packages/<type> Route implementation for a specific registry type
services/packages Helper methods used by registry types to handle common tasks like package creation and deletion in routers
services/packages/<type> Registry type specific methods used by routers and services

Models

Every package registry implementation uses the same underlying models:

Model Description
Package The root of a package providing values fixed for every version (e.g. the package name)
PackageVersion A version of a package containing metadata (e.g. the package description)
PackageFile A file of a package describing its content (e.g. file name)
PackageBlob The content of a file (may be shared by multiple files)
PackageProperty Additional properties attached to Package, PackageVersion or PackageFile (e.g. used if metadata is needed for routing)

The following diagram shows the relationship between the models:

Package <1---*> PackageVersion <1---*> PackageFile <*---1> PackageBlob

Adding a new package registry type

Before adding a new package registry type have a look at the existing implementation to get an impression of how it could work. Most registry types offer endpoints to retrieve the metadata, upload and download package files. The upload endpoint is often the heavy part because it must validate the uploaded blob, extract metadata and create the models. The methods to validate and extract the metadata should be added in the modules/packages/<type> package. If the upload is valid the methods in services/packages allow to store the upload and create the corresponding models. It depends if the registry type allows multiple files per package version which method should be called:

  • CreatePackageAndAddFile: error if package version already exists
  • CreatePackageOrAddFileToExisting: error if file already exists
  • AddFileToExistingPackage: error if package version does not exist or file already exists

services/packages also contains helper methods to download a file or to remove a package version. There are no helper methods for metadata endpoints because they are very type specific.