mirror of https://codeberg.org/forgejo/forgejo.git synced 2024-11-23 13:55:42 +03:00

History

Zettat123 6b74043b85 Fix `missing signature key` error when pulling Docker images with `SERVE_DIRECT` enabled (#32365 ) Fix #28121 I did some tests and found that the `missing signature key` error is caused by an incorrect `Content-Type` header. Gitea correctly sets the `Content-Type` header when serving files. `348d1d0f32/routers/api/packages/container/container.go (L712-L717)` However, when `SERVE_DIRECT` is enabled, the `Content-Type` header may be set to an incorrect value by the storage service. To fix this issue, we can use query parameters to override response header values. https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html <img width="600px" src="https://github.com/user-attachments/assets/f2ff90f0-f1df-46f9-9680-b8120222c555" /> In this PR, I introduced a new parameter to the `URL` method to support additional parameters. ``` URL(path, name string, reqParams url.Values) (*url.URL, error) ``` --- Most S3-like services support specifying the content type when storing objects. However, Gitea always use `application/octet-stream`. Therefore, I believe we also need to improve the `Save` method to support storing objects with the correct content type. `b7fb20e73e/modules/storage/minio.go (L214-L221)` (cherry picked from commit 0690cb076bf63f71988a709f62a9c04660b51a4f) Conflicts: - modules/storage/azureblob.go Dropped the change, as we do not support Azure blob storage. - modules/storage/helper.go Resolved by adjusting their `discardStorage` to our `DiscardStorage` - routers/api/actions/artifacts.go routers/api/actions/artifactsv4.go routers/web/repo/actions/view.go routers/web/repo/download.go Resolved the conflicts by manually adding the new `nil` parameter to the `storage.Attachments.URL()` calls. Originally conflicted due to differences in the if expression above these calls.		2024-11-05 09:33:15 +01:00
..
alpine
arch
cargo
chef
composer
conan
conda
container
cran
debian
generic
goproxy
helm
helper
maven
npm
nuget
pub
pypi
rpm
rubygems
swift
vagrant
api.go
README.md

README.md

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.