Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mod: what should happen when an OCI server returns a 401 response? #2955

Closed
rogpeppe opened this issue Mar 18, 2024 · 2 comments
Closed

mod: what should happen when an OCI server returns a 401 response? #2955

rogpeppe opened this issue Mar 18, 2024 · 2 comments
Assignees
Labels
modules Issues related to CUE modules and the experimental implementation NeedsInvestigation

Comments

@rogpeppe
Copy link
Member

What version of CUE are you using (cue version)?

$ cue version
v0.8.0

Does this issue reproduce with the latest stable release?

N/A

What did you do?

This isn't the actual reproducer because I don't have access to the registry, but
this is the gist:

env CUE_REGISTRY=foo.example/modules
env CUE_DEBUG=http
env CUE_EXPERIMENT=modules

exec cue mod tidy

-- cue.mod/module.cue
module: "main.example"

-- main.cue --
package main

import e "x.example"

e

What did you expect to see?

An error saying that the module is unavailable.

What did you see instead?

failed to resolve "x.example": 401 Unauthorized: unauthorized: authentication required; detail: [{"Type":"repository","Class":"","Name":"provid/x.example","ProjectPath":"","Action":"pull"}]

The server is returning a 401 error rather than a 404, even though the client has acquired a valid auth token.

The HTTP log looks like this (names changed, cleaned up somewhat and run through jq .):

{
  "time": "2024-03-18T14:59:08.35335+01:00",
  "level": "INFO",
  "msg": "http client->",
  "info": {
    "id": 1,
    "method": "GET",
    "url": "https://foo.example/v2/provid/x.example/tags/list?n=1000",
    "contentLength": 0,
    "header": {
      "User-Agent": [
        "Cue/v0.8.0 (cmd/cue) Go/go1.22.1 (darwin/arm64)"
      ]
    }
  }
}
{
  "time": "2024-03-18T14:59:08.426175+01:00",
  "level": "INFO",
  "msg": "http client<-",
  "info": {
    "id": 1,
    "method": "GET",
    "url": "https://foo.example/v2/provid/x.example/tags/list?n=1000",
    "statusCode": 401,
    "header": {
      "Content-Length": [
        "176"
      ],
      "Content-Type": [
        "application/json"
      ],
      "Date": [
        "Mon, 18 Mar 2024 13:59:08 GMT"
      ],
      "Docker-Distribution-Api-Version": [
        "registry/2.0"
      ],
      "Server": [
        "nginx"
      ],
      "Www-Authenticate": [
        "Bearer realm=\"https://tokenserver.example/jwt/auth\",service=\"container_registry\",scope=\"repository:provid/x.example:pull\""
      ],
      "X-Content-Type-Options": [
        "nosniff"
      ]
    },
    "body": "{\"errors\":[{\"code\":\"UNAUTHORIZED\",\"message\":\"authentication required\",\"detail\":[{\"Type\":\"repository\",\"Class\":\"\",\"Name\":\"provid/x.example\",\"ProjectPath\":\"\",\"Action\":\"pull\"}]}]}\n"
  }
}
{
  "time": "2024-03-18T14:59:08.426259+01:00",
  "level": "INFO",
  "msg": "http client->",
  "info": {
    "id": 2,
    "method": "GET",
    "url": "https://tokenserver.example/jwt/auth?scope=repository:provid/x.example:pull&service=container_registry",
    "contentLength": 0,
    "header": {
      "Authorization": [
        "Basic REDACTED"
      ],
      "User-Agent": [
        "Cue/v0.8.0 (cmd/cue) Go/go1.22.1 (darwin/arm64)"
      ]
    }
  }
}
{
  "time": "2024-03-18T14:59:08.516768+01:00",
  "level": "INFO",
  "msg": "http client<-",
  "info": {
    "id": 2,
    "method": "GET",
    "url": "https://tokenserver.example/jwt/auth?scope=repository:provid/x.example:pull&service=container_registry",
    "statusCode": 200,
    "header": {
      "Cache-Control": [
        "max-age=0, private, must-revalidate"
      ],
      "Content-Security-Policy": [
        ""
      ],
      "Content-Type": [
        "application/json; charset=utf-8"
      ],
      "Date": [
        "Mon, 18 Mar 2024 13:59:08 GMT"
      ],
      "Etag": [
        "W/\"0398676f0e4e99a35643c00d645cca58\""
      ],
      "Permissions-Policy": [
        "interest-cohort=()"
      ],
      "Referrer-Policy": [
        "strict-origin-when-cross-origin"
      ],
      "Server": [
        "nginx"
      ],
      "Strict-Transport-Security": [
        "max-age=63072000"
      ],
      "Vary": [
        "Accept-Encoding"
      ],
      "X-Content-Type-Options": [
        "nosniff"
      ],
      "X-Download-Options": [
        "noopen"
      ],
      "X-Frame-Options": [
        "SAMEORIGIN"
      ],
      "X-Gitlab-Meta": [
        "{\"correlation_id\":\"01HS8XQREB85JDA6TX2BGT77RC\",\"version\":\"1\"}"
      ],
      "X-Permitted-Cross-Domain-Policies": [
        "none"
      ],
      "X-Request-Id": [
        "01HS8XQREB85JDA6TX2BGT77RC"
      ],
      "X-Runtime": [
        "0.035188"
      ],
      "X-Ua-Compatible": [
        "IE=edge"
      ],
      "X-Xss-Protection": [
        "1; mode=block"
      ]
    },
    "body": "REDACTED",
    "bodyTruncated": true
  }
}
{
  "time": "2024-03-18T14:59:08.516947+01:00",
  "level": "INFO",
  "msg": "http client->",
  "info": {
    "id": 3,
    "method": "GET",
    "url": "https://foo.example/v2/provid/x.example/tags/list?n=1000",
    "contentLength": 0,
    "header": {
      "Authorization": [
        "Bearer REDACTED"
      ],
      "User-Agent": [
        "Cue/v0.8.0 (cmd/cue) Go/go1.22.1 (darwin/arm64)"
      ]
    }
  }
}
{
  "time": "2024-03-18T14:59:08.537749+01:00",
  "level": "INFO",
  "msg": "http client<-",
  "info": {
    "id": 3,
    "method": "GET",
    "url": "https://foo.example/v2/provid/x.example/tags/list?n=1000",
    "statusCode": 401,
    "header": {
      "Content-Length": [
        "176"
      ],
      "Content-Type": [
        "application/json"
      ],
      "Date": [
        "Mon, 18 Mar 2024 13:59:08 GMT"
      ],
      "Docker-Distribution-Api-Version": [
        "registry/2.0"
      ],
      "Server": [
        "nginx"
      ],
      "Www-Authenticate": [
        "Bearer realm=\"https://tokenserver.example/jwt/auth\",service=\"container_registry\",scope=\"repository:provid/x.example:pull\",error=\"insufficient_scope\""
      ],
      "X-Content-Type-Options": [
        "nosniff"
      ]
    },
    "body": "{\"errors\":[{\"code\":\"UNAUTHORIZED\",\"message\":\"authentication required\",\"detail\":[{\"Type\":\"repository\",\"Class\":\"\",\"Name\":\"provid/x.example\",\"ProjectPath\":\"\",\"Action\":\"pull\"}]}]}\n"
  }
}
@rogpeppe rogpeppe added NeedsInvestigation Triage Requires triage/attention modules Issues related to CUE modules and the experimental implementation and removed Triage Requires triage/attention labels Mar 18, 2024
@mvdan
Copy link
Member

mvdan commented Mar 19, 2024

What do other clients do in this scenario, e.g. docker pull?

@mxey
Copy link

mxey commented Mar 25, 2024

@mvdan The difference is that CUE tries to look up multiple OCI repos, while docker pull only ever talks to one.

porcuepine pushed a commit to cue-labs/oci that referenced this issue Mar 27, 2024
Some registries will return a 401 Unauthorized error, indicating that no valid
auth credentials have been provided, even when valid auth
credentials _have_ been provided. Although this goes
against [the HTTP status code conventions](https://stackoverflow.com/a/6937030)
we need to deal with this somehow, because otherwise
a client cannot distinguish between a "bad auth credentials error"
(meaning that if the user does authenticate, the error might go away)
and an "auth credentials not valid for resource error"
(meaning that the user is authenticated but cannot access the resource
despite that).

The `ociauth` package is in a unique position to be able to make this
determination because it the only place that knows that auth
credentials have been freshly acquired, therefore a subsequent
401 error is almost certainly because the privileges were insufficient
for the authenticated user rather than because there is no authenticated
user.

So, we change `ociauth` to return 403 Forbidden in this case.

Fixes cue-lang/cue#2955

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: Ie50bb826e266d3b26f06881d41da36f740bc43ab
porcuepine pushed a commit to cue-labs/oci that referenced this issue Mar 27, 2024
Some registries will return a 401 Unauthorized error, indicating that no valid
auth credentials have been provided, even when valid auth
credentials _have_ been provided. Although this goes
against [the HTTP status code conventions](https://stackoverflow.com/a/6937030)
we need to deal with this somehow, because otherwise
a client cannot distinguish between a "bad auth credentials error"
(meaning that if the user does authenticate, the error might go away)
and an "auth credentials not valid for resource error"
(meaning that the user is authenticated but cannot access the resource
despite that).

The `ociauth` package is in a unique position to be able to make this
determination because it the only place that knows that auth
credentials have been freshly acquired, therefore a subsequent
401 error is almost certainly because the privileges were insufficient
for the authenticated user rather than because there is no authenticated
user.

So, we change `ociauth` to return 403 Forbidden in this case.

Fixes cue-lang/cue#2955

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: Ie50bb826e266d3b26f06881d41da36f740bc43ab
porcuepine pushed a commit to cue-labs/oci-trybot that referenced this issue Mar 27, 2024
Some registries will return a 401 Unauthorized error, indicating that no valid
auth credentials have been provided, even when valid auth
credentials _have_ been provided. Although this goes
against [the HTTP status code conventions](https://stackoverflow.com/a/6937030)
we need to deal with this somehow, because otherwise
a client cannot distinguish between a "bad auth credentials error"
(meaning that if the user does authenticate, the error might go away)
and an "auth credentials not valid for resource error"
(meaning that the user is authenticated but cannot access the resource
despite that).

The `ociauth` package is in a unique position to be able to make this
determination because it the only place that knows that auth
credentials have been freshly acquired, therefore a subsequent
401 error is almost certainly because the privileges were insufficient
for the authenticated user rather than because there is no authenticated
user.

So, we change `ociauth` to return 403 Forbidden in this case.

Fixes cue-lang/cue#2955

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: Ie50bb826e266d3b26f06881d41da36f740bc43ab
Dispatch-Trailer: {"type":"trybot","CL":1188182,"patchset":2,"ref":"refs/changes/82/1188182/2","targetBranch":"main"}
porcuepine pushed a commit to cue-labs/oci that referenced this issue Mar 27, 2024
Some registries will return a 401 Unauthorized error, indicating that no valid
auth credentials have been provided, even when valid auth
credentials _have_ been provided. Although this goes
against [the HTTP status code conventions](https://stackoverflow.com/a/6937030)
we need to deal with this somehow, because otherwise
a client cannot distinguish between a "bad auth credentials error"
(meaning that if the user does authenticate, the error might go away)
and an "auth credentials not valid for resource error"
(meaning that the user is authenticated but cannot access the resource
despite that).

The `ociauth` package is in a unique position to be able to make this
determination because it the only place that knows that auth
credentials have been freshly acquired, therefore a subsequent
401 error is almost certainly because the privileges were insufficient
for the authenticated user rather than because there is no authenticated
user.

So, we change `ociauth` to return 403 Forbidden in this case.

Fixes cue-lang/cue#2955

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: Ie50bb826e266d3b26f06881d41da36f740bc43ab
porcuepine pushed a commit to cue-labs/oci-trybot that referenced this issue Mar 27, 2024
Some registries will return a 401 Unauthorized error, indicating that no valid
auth credentials have been provided, even when valid auth
credentials _have_ been provided. Although this goes
against [the HTTP status code conventions](https://stackoverflow.com/a/6937030)
we need to deal with this somehow, because otherwise
a client cannot distinguish between a "bad auth credentials error"
(meaning that if the user does authenticate, the error might go away)
and an "auth credentials not valid for resource error"
(meaning that the user is authenticated but cannot access the resource
despite that).

The `ociauth` package is in a unique position to be able to make this
determination because it the only place that knows that auth
credentials have been freshly acquired, therefore a subsequent
401 error is almost certainly because the privileges were insufficient
for the authenticated user rather than because there is no authenticated
user.

So, we change `ociauth` to return 403 Forbidden in this case.

Fixes cue-lang/cue#2955

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: Ie50bb826e266d3b26f06881d41da36f740bc43ab
Dispatch-Trailer: {"type":"trybot","CL":1188182,"patchset":3,"ref":"refs/changes/82/1188182/3","targetBranch":"main"}
porcuepine pushed a commit to cue-labs/oci that referenced this issue Mar 28, 2024
Some registries will return a 401 Unauthorized error, indicating that no valid
auth credentials have been provided, even when valid auth
credentials _have_ been provided. Although this goes
against [the HTTP status code conventions](https://stackoverflow.com/a/6937030)
we need to deal with this somehow, because otherwise
a client cannot distinguish between a "bad auth credentials error"
(meaning that if the user does authenticate, the error might go away)
and an "auth credentials not valid for resource error"
(meaning that the user is authenticated but cannot access the resource
despite that).

The `ociauth` package is in a unique position to be able to make this
determination because it the only place that knows that auth
credentials have been freshly acquired, therefore a subsequent
401 error is almost certainly because the privileges were insufficient
for the authenticated user rather than because there is no authenticated
user.

So, we change `ociauth` to return 403 Forbidden in this case.

Fixes cue-lang/cue#2955

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: Ie50bb826e266d3b26f06881d41da36f740bc43ab
porcuepine pushed a commit to cue-labs/oci-trybot that referenced this issue Mar 28, 2024
Some registries will return a 401 Unauthorized error, indicating that no valid
auth credentials have been provided, even when valid auth
credentials _have_ been provided. Although this goes
against [the HTTP status code conventions](https://stackoverflow.com/a/6937030)
we need to deal with this somehow, because otherwise
a client cannot distinguish between a "bad auth credentials error"
(meaning that if the user does authenticate, the error might go away)
and an "auth credentials not valid for resource error"
(meaning that the user is authenticated but cannot access the resource
despite that).

The `ociauth` package is in a unique position to be able to make this
determination because it the only place that knows that auth
credentials have been freshly acquired, therefore a subsequent
401 error is almost certainly because the privileges were insufficient
for the authenticated user rather than because there is no authenticated
user.

So, we change `ociauth` to return 403 Forbidden in this case.

Fixes cue-lang/cue#2955

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: Ie50bb826e266d3b26f06881d41da36f740bc43ab
Dispatch-Trailer: {"type":"trybot","CL":1188182,"patchset":4,"ref":"refs/changes/82/1188182/4","targetBranch":"main"}
porcuepine pushed a commit to cue-labs/oci that referenced this issue Mar 28, 2024
Some registries will return a 401 Unauthorized error, indicating that no
valid auth credentials have been provided, even when valid auth
credentials _have_ been provided. Although this goes against [the HTTP
status code conventions](https://stackoverflow.com/a/6937030) we need to
deal with this somehow, because otherwise a client cannot distinguish
between a "bad auth credentials error" (meaning that if the user does
authenticate, the error might go away) and an "auth credentials not
valid for resource error" (meaning that the user is authenticated but
cannot access the resource despite that).

The `ociauth` package is in a unique position to be able to make this
determination because it the only place that knows that auth credentials
have been freshly acquired, therefore a subsequent 401 error is almost
certainly because the privileges were insufficient for the authenticated
user rather than because there is no authenticated user.

So, we change `ociauth` to return 403 Forbidden in this case.

Fixes cue-lang/cue#2955

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: Ie50bb826e266d3b26f06881d41da36f740bc43ab
porcuepine pushed a commit to cue-labs/oci-trybot that referenced this issue Mar 28, 2024
Some registries will return a 401 Unauthorized error, indicating that no
valid auth credentials have been provided, even when valid auth
credentials _have_ been provided. Although this goes against [the HTTP
status code conventions](https://stackoverflow.com/a/6937030) we need to
deal with this somehow, because otherwise a client cannot distinguish
between a "bad auth credentials error" (meaning that if the user does
authenticate, the error might go away) and an "auth credentials not
valid for resource error" (meaning that the user is authenticated but
cannot access the resource despite that).

The `ociauth` package is in a unique position to be able to make this
determination because it the only place that knows that auth credentials
have been freshly acquired, therefore a subsequent 401 error is almost
certainly because the privileges were insufficient for the authenticated
user rather than because there is no authenticated user.

So, we change `ociauth` to return 403 Forbidden in this case.

Fixes cue-lang/cue#2955

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: Ie50bb826e266d3b26f06881d41da36f740bc43ab
Dispatch-Trailer: {"type":"trybot","CL":1188182,"patchset":5,"ref":"refs/changes/82/1188182/5","targetBranch":"main"}
porcuepine pushed a commit to cue-labs/oci that referenced this issue Mar 28, 2024
Some registries will return a 401 Unauthorized error, indicating that no
valid auth credentials have been provided, even when valid auth
credentials _have_ been provided. Although this goes against [the HTTP
status code conventions](https://stackoverflow.com/a/6937030) we need to
deal with this somehow, because otherwise a client cannot distinguish
between a "bad auth credentials error" (meaning that if the user does
authenticate, the error might go away) and an "auth credentials not
valid for resource error" (meaning that the user is authenticated but
cannot access the resource despite that).

The `ociauth` package is in a unique position to be able to make this
determination because it the only place that knows that auth credentials
have been freshly acquired, therefore a subsequent 401 error is almost
certainly because the privileges were insufficient for the authenticated
user rather than because there is no authenticated user.

So, we change `ociauth` to return 403 Forbidden in this case.

Fixes cue-lang/cue#2955

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: Ie50bb826e266d3b26f06881d41da36f740bc43ab
Reviewed-on: https://review.gerrithub.io/c/cue-labs/oci/+/1188182
TryBot-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Tianon Gravi <admwiggin@gmail.com>
Reviewed-by: Paul Jolly <paul@myitcv.io>
porcuepine pushed a commit to cue-labs/oci that referenced this issue Apr 4, 2024
The current logic triggers the 401->403 logic even when the
credentials are not acquired from a token server. We want
to be more specific than that.

For cue-lang/cue#2955.

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: I8d826cff31554ecdb78bb580e72a2d8258ae6565
porcuepine pushed a commit to cue-labs/oci-trybot that referenced this issue Apr 4, 2024
The current logic triggers the 401->403 logic even when the
credentials are not acquired from a token server. We want
to be more specific than that.

For cue-lang/cue#2955.

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: I8d826cff31554ecdb78bb580e72a2d8258ae6565
Dispatch-Trailer: {"type":"trybot","CL":1191614,"patchset":2,"ref":"refs/changes/14/1191614/2","targetBranch":"main"}
porcuepine pushed a commit to cue-labs/oci-trybot that referenced this issue Apr 4, 2024
The current logic triggers the 401->403 logic even when the
credentials are not acquired from a token server. We want
to be more specific than that.

For cue-lang/cue#2955.

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: I8d826cff31554ecdb78bb580e72a2d8258ae6565
Dispatch-Trailer: {"type":"trybot","CL":1191614,"patchset":3,"ref":"refs/changes/14/1191614/3","targetBranch":"main"}
porcuepine pushed a commit to cue-labs/oci that referenced this issue Apr 4, 2024
The current logic triggers the 401->403 logic even when the
credentials are not acquired from a token server. We want
to be more specific than that.

For cue-lang/cue#2955.

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: I8d826cff31554ecdb78bb580e72a2d8258ae6565
cueckoo pushed a commit that referenced this issue Apr 4, 2024
When considering what repositories might contain a module,
the module resolution logic is careful to distinguish between
a simple "not found" error (discarded silently) and any other
kind of error (triggers an error in the whole module
resolution process).

When a user has authenticated but does not have access to
a given module, the HTTP standard allows the server to
return a 403 (Forbidden) error to indicate that the user
doesn't have permission to access a page.

When considering possible candidates for modules, we
don't want to fail if there are some modules that exist
that we can't access, so this CL changes the logic to
treat any 403 error the same as "not found" in this respect.

We also add tests for this and for token-server-based authentication,
verifying that with the OCI dependency updated as it
is in this CL, issue #2955 is actually fixed.

Fixes #2955.

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: I665b1aa28be255bb2e4a00bfc606b0899575fec1
cueckoo pushed a commit that referenced this issue Apr 4, 2024
When considering what repositories might contain a module, the module
resolution logic is careful to distinguish between a simple "not found"
error (discarded silently) and any other kind of error (triggers an
error in the whole module resolution process).

When a user has authenticated but does not have access to a given
module, the HTTP standard allows the server to return a 403 (Forbidden)
error to indicate that the user doesn't have permission to access a
page.

When considering possible candidates for modules, we don't want to fail
if there are some modules that exist that we can't access, so this CL
changes the logic to treat any 403 error the same as "not found" in this
respect.

We also add tests for this and for token-server-based authentication,
verifying that with the OCI dependency updated as it is in this CL,
issue #2955 is actually fixed. The `registrytest` package API is changed
to allow this, because the previous `AuthHandler` function was not
sufficient to allow an independent token handler server listening on a
different port.

Fixes #2955.

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: I665b1aa28be255bb2e4a00bfc606b0899575fec1
cueckoo pushed a commit that referenced this issue Apr 4, 2024
When considering what repositories might contain a module, the module
resolution logic is careful to distinguish between a simple "not found"
error (discarded silently) and any other kind of error (triggers an
error in the whole module resolution process).

When a user has authenticated but does not have access to a given
module, the HTTP standard allows the server to return a 403 (Forbidden)
error to indicate that the user doesn't have permission to access a
page.

When considering possible candidates for modules, we don't want to fail
if there are some modules that exist that we can't access, so this CL
changes the logic to treat any 403 error the same as "not found" in this
respect.

We also make the error message when there is a permanent error
more specific so it actually mentions the module that it's trying to
resolve.

We also add tests for this and for token-server-based authentication,
verifying that with the OCI dependency updated as it is in this CL,
issue #2955 is actually fixed. The `registrytest` package API is changed
to allow this, because the previous `AuthHandler` function was not
sufficient to allow an independent token handler server listening on a
different port.

Fixes #2955.

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: I665b1aa28be255bb2e4a00bfc606b0899575fec1
porcuepine pushed a commit to cue-labs/oci that referenced this issue Apr 4, 2024
The current logic triggers the 401->403 logic even when the
credentials are not acquired from a token server. We want
to be more specific than that.

For cue-lang/cue#2955.

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: I8d826cff31554ecdb78bb580e72a2d8258ae6565
Reviewed-on: https://review.gerrithub.io/c/cue-labs/oci/+/1191614
TryBot-Result: CUE porcuepine <cue.porcuepine@gmail.com>
Reviewed-by: Rustam Abdullaev <rustam@cue.works>
cueckoo pushed a commit that referenced this issue Apr 4, 2024
When considering what repositories might contain a module, the module
resolution logic is careful to distinguish between a simple "not found"
error (discarded silently) and any other kind of error (triggers an
error in the whole module resolution process).

When a user has authenticated but does not have access to a given
module, the HTTP standard allows the server to return a 403 (Forbidden)
error to indicate that the user doesn't have permission to access a
page.

When considering possible candidates for modules, we don't want to fail
if there are some modules that exist that we can't access, so this CL
changes the logic to treat any 403 error the same as "not found" in this
respect.

We also make the error message when there is a permanent error
more specific so it actually mentions the module that it's trying to
resolve.

We also add tests for this and for token-server-based authentication,
verifying that with the OCI dependency updated as it is in this CL,
issue #2955 is actually fixed. The `registrytest` package API is changed
to allow this, because the previous `AuthHandler` function was not
sufficient to allow an independent token handler server listening on a
different port.

Fixes #2955.

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: I665b1aa28be255bb2e4a00bfc606b0899575fec1
cueckoo pushed a commit that referenced this issue Apr 5, 2024
When considering what repositories might contain a module, the module
resolution logic is careful to distinguish between a simple "not found"
error (discarded silently) and any other kind of error (triggers an
error in the whole module resolution process).

When a user has authenticated but does not have access to a given
module, the HTTP standard allows the server to return a 403 (Forbidden)
error to indicate that the user doesn't have permission to access a
page.

When considering possible candidates for modules, we don't want to fail
if there are some modules that exist that we can't access, so this CL
changes the logic to treat any 403 error the same as "not found" in this
respect.

We also make the error message when there is a permanent error
more specific so it actually mentions the module that it's trying to
resolve.

We also add tests for this and for token-server-based authentication,
verifying that with the OCI dependency updated as it is in this CL,
issue #2955 is actually fixed. The `registrytest` package API is changed
to allow this, because the previous `AuthHandler` function was not
sufficient to allow an independent token handler server listening on a
different port.

Fixes #2955.

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: I665b1aa28be255bb2e4a00bfc606b0899575fec1
cueckoo pushed a commit that referenced this issue Apr 5, 2024
When considering what repositories might contain a module, the module
resolution logic is careful to distinguish between a simple "not found"
error (discarded silently) and any other kind of error (triggers an
error in the whole module resolution process).

When a user has authenticated but does not have access to a given
module, the HTTP standard allows the server to return a 403 (Forbidden)
error to indicate that the user doesn't have permission to access a
page.

When considering possible candidates for modules, we don't want to fail
if there are some modules that exist that we can't access, so this CL
changes the logic to treat any 403 error the same as "not found" in this
respect.

We also make the error message when there is a permanent error
more specific so it actually mentions the module that it's trying to
resolve.

We also add tests for this and for token-server-based authentication,
verifying that with the OCI dependency updated as it is in this CL,
issue #2955 is actually fixed. The `registrytest` package API is changed
to allow this, because the previous `AuthHandler` function was not
sufficient to allow an independent token handler server listening on a
different port.

Fixes #2955.

Signed-off-by: Roger Peppe <rogpeppe@gmail.com>
Change-Id: I665b1aa28be255bb2e4a00bfc606b0899575fec1
@cueckoo cueckoo closed this as completed in d8067eb Apr 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
modules Issues related to CUE modules and the experimental implementation NeedsInvestigation
Projects
Archived in project
Development

No branches or pull requests

3 participants