PR #4353 made MaxTags (default 1000) a hard ceiling on the `n` query
parameter — anything larger and the handler returns 400
PAGINATION_NUMBER_INVALID before the request ever reaches storage or
the proxy tag service. That broke clients like Renovate which use
n=10000 against pull-through caches. #4846 fixed a related 500 in
proxy mode but not this 400, so users reported the regression still
persisted.
The OCI distribution-spec describes pagination differently: a server
MAY return fewer than `n` results "when the total number of tags
attached to the repository is less than <int> or a Link header is
provided" — otherwise it MUST include `<int>` results. In other
words, the right answer for "client asked for more than we'll serve"
is `maxtags` results plus a Link header, not a rejection.
PAGINATION_NUMBER_INVALID isn't among the 14 error codes the spec
defines, either.
Drop the oversized-n rejection and clamp to MaxTags instead; the
existing Link-header path already handles continuation correctly.
Malformed (non-integer) and negative `n` values keep returning 400,
since the spec defines `n` as a non-negative integer and those
requests are genuinely invalid.
Verified end-to-end against registry-1.docker.io in proxy mode:
n=10000 now returns the tag list (or a clamped page with Link)
instead of 400. Also restores pre-3.1.0 behavior for Renovate-style
clients without needing proxy-specific logic.
Spec reference:
https://github.com/opencontainers/distribution-spec/blob/main/spec.md#listing-tags
Signed-off-by: Milos Gajdos <milosthegajdos@gmail.com>
Updated TLS configuration parameters to indicate that 'certificate' and 'key' are optional for mTLS. Added notes and examples for server-side TLS and mutual TLS.
Signed-off-by: Omar Trigui <omar.trigui.tn@gmail.com>
The newIgnoredSink function had a bug where it would return the
unfiltered sink when the mediatypes list was empty, even if
ignoreActions was populated. This made it impossible to filter
events by action alone.
This fix changes the early return condition to check both parameters:
- Only returns unfiltered sink when BOTH are empty
- Allows filtering by actions alone
- Allows filtering by mediatypes alone
- Maintains existing OR logic when both are specified
Added test cases specifically for the edge case of empty mediatypes
with populated actions list.
Updated documentation to clarify how the filtering works and that
the two parameters work independently.
Fixes: #4729
Signed-off-by: Adrian Callejas <acallejaszu@gmail.com>
square brackets and the respective parentheses for a markdown link were falsely typed in causing readability issues. This commit fixes the markdown syntax for the same
Signed-off-by: Shan Desai <shantanoo.desai@gmail.com>
`configureRedis` currently sets `RequireAndVerifyClientCert` and `ClientCAs`, however these are server side mTLS configurations, and do not apply for the client initiating the handshake.
Since we never actually set client side `RootCAs`, connecting to Redis with a self-signed CA results in:
```
"error": "tls: failed to verify certificate: x509: certificate signed by unknown authority",
```
Fixed by switching Redis TLS config to use `RootCAs` instead, and updating configuration accordingly.
Signed-off-by: ChandonPierre <cpierre@coreweave.com>
* Make copy poll max retry, a global driver max retry
* Get support for etags in Azure
* Fix storage driver tests
* Fix auth mess and update docs
* Refactor Azure client and enable Azure storage tests
We use Azurite for integration testing which requires TLS,
so we had to figure out how to skip TLS verification when running tests locally:
this required updating testsuites Driver and constructor due to TestRedirectURL
sending GET and HEAD requests to remote storage which in this case is Azurite.
Signed-off-by: Milos Gajdos <milosthegajdos@gmail.com>
- Add Unit tests for `token.newAccessController`
+ Implemented swappable implementations for `token.getRootCerts` and
`getJwks` to unit test their behavior over the accessController
struct.
- Use RFC7638 [0] mechanics to compute the KeyID of the rootcertbundle
provided in the token auth config.
- Extends token authentication docs:
+ Extend `jwt.md` write up on JWT headers & JWT Validation
+ Updated old reference to a draft that's now RFC7515.
+ Extended the JWT validation steps with the JWT Header validation.
+ Reference `jwt.md` in `token.md`
[0]: https://datatracker.ietf.org/doc/html/rfc7638#autoid-13
Signed-off-by: Jose D. Gomez R <jose.gomez@suse.com>
This change allows users to run the registry as a pull-through cache
that can use a credential helper to authenticate against the upstream
registry.
Signed-off-by: Chun-Hung Hsiao <chhsiao@google.com>
Huge help from @milosgajdos who figured out how to do the entire
marshalling/unmarshalling for the configs
Signed-off-by: Anders Ingemann <aim@orbit.online>
This bumps go-jose to the latest available version: v4.0.3.
This slightly breaks the backwards compatibility with the existing
registry deployments but brings more security with it.
We now require the users to specify the list of token signing algorithms in
the configuration. We do strive to maintain the b/w compat by providing
a list of supported algorithms, though, this isn't something we
recommend due to security issues, see:
* https://github.com/go-jose/go-jose/issues/64
* https://github.com/go-jose/go-jose/pull/69
As part of this change we now return to the original flow of the token
signature validation:
1. X2C (tls) headers
2. JWKS
3. KeyID
Signed-off-by: Milos Gajdos <milosthegajdos@gmail.com>
Enable configuration options that can selectively disable validation
that dependencies exist within the registry before the image index
is uploaded.
This enables sparse indexes, where a registry holds a manifest index that
could be signed (so the digest must not change) but does not hold every
referenced image in the index. The use case for this is when a registry
mirror does not need to mirror all platforms, but does need to maintain
the digests of all manifests either because they are signed or because
they are pulled by digest.
The registry administrator can also select specific image architectures
that must exist in the registry, enabling a registry operator to select
only the platforms they care about and ensure all image indexes uploaded
to the registry are valid for those platforms.
Signed-off-by: James Hewitt <james.hewitt@uk.ibm.com>
Harbor is using the distribution for it's (harbor-registry) registry component.
The harbor GC will call into the registry to delete the manifest, which in turn
then does a lookup for all tags that reference the deleted manifest.
To find the tag references, the registry will iterate every tag in the repository
and read it's link file to check if it matches the deleted manifest (i.e. to see
if uses the same sha256 digest). So, the more tags in repository, the worse the
performance will be (as there will be more s3 API calls occurring for the tag
directory lookups and tag file reads).
Therefore, we can use concurrent lookup and untag to optimize performance as described in https://github.com/goharbor/harbor/issues/12948.
P.S. This optimization was originally contributed by @Antiarchitect, now I would like to take it over.
Thanks @Antiarchitect's efforts with PR https://github.com/distribution/distribution/pull/3890.
Signed-off-by: Liang Zheng <zhengliang0901@gmail.com>
Update the formatting of links and add a Markdown render hook for
handling relative internal links. Cross-references between markdown
files are now resolved the same way in both GitHub and Hugo.
Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>
