Skip to content

Upgrade self-tests to deal with github.com/oras-project/oras-go v2.6.2 security release: FAIL: TestPushSignature #587

Open

Description

@jas4711

Is your feature request related to a problem?

Hi! This project uses oras-go 2.6.0 and recently v2.6.2 was released which fixes several security bugs. However upgrading it leads to build failures in notation-go. Could you look into this? I help maintain this package for Debian, and to allow the security release to migrate, I'm going to disable these self tests -- but I prefer a proper fix.

Probably related to #585

https://salsa.debian.org/jas/golang-oras-oras-go/-/jobs/10025571#L1790

=== RUN   TestPushSignature
=== RUN   TestPushSignature/failed_to_upload_signature
=== RUN   TestPushSignature/successfully_uploaded_signature_manifest
    repository_test.go:421: error = blob upload Location "" is on a different host than the registry "localhost:5000", expectErr = false
--- FAIL: TestPushSignature (0.00s)
    --- PASS: TestPushSignature/failed_to_upload_signature (0.00s)
    --- FAIL: TestPushSignature/successfully_uploaded_signature_manifest (0.00s)
=== RUN   TestPushSignatureImageManifest
    repository_test.go:439: failed to push signature
--- FAIL: TestPushSignatureImageManifest (0.00s)

/Simon

What solution do you propose?

Fix tests

What alternatives have you considered?

Disabling tests

Any additional context?

Using notation-go v1.3.2

Activity

  1. added
    enhancementNew feature or request
    triageNeeds evaluation for feasibility, timeline, etc.
    on Jul 28, 2026
  2. siretart commented on Sep 25, 2026

    @siretart
    Contributor

    We investigated the root cause of this failure in Debian (tracking BTS #1148141).

    Root Cause

    In oras-go v2.6.2, PR #1152 added host validation on the Location header returned by the registry during blob uploads (completePushAfterInitialPost) to prevent credential leakage (GHSA-jxpm-75mh-9fp7).

    In registry/repository_test.go, mockRemoteClient.Do returned a mock http.Response for /v2/test/blobs/uploads/ with:

    Request: &http.Request{
        Header: map[string][]string{},
    },
    Header: map[string][]string{
        "Location": {"test"},
    },

    Because Request.URL is nil, Go's (*http.Response).Location() cannot resolve the relative URL "test" against the base request URL. This leaves location.Host == "" (location.Hostname() == ""), which fails sameUploadHost comparison against req.URL.Hostname() ("localhost"), triggering:

    error = blob upload Location "" is on a different host than the registry "localhost:5000", expectErr = false
    

    Fix

    Passing the incoming Request: req allows resp.Location() to resolve the URL relative to the request. Providing a path under /v2/test/blobs/uploads/test and returning 201 Created for the subsequent PUT satisfies oras-go's host and scheme checks.

    Here is the patch we applied in Debian, which resolves the failure and passes cleanly with both oras-go v2.5.0 and v2.6.2 (and should unblock #585):

    --- a/registry/repository_test.go
    +++ b/registry/repository_test.go
    @@ -156,11 +156,9 @@ func (c mockRemoteClient) Do(req *http.Request) (*http.Response, error) {
     		case validRegistry:
     			return &http.Response{
     				StatusCode: http.StatusAccepted,
     				Body:       io.NopCloser(bytes.NewReader([]byte(msg))),
    -				Request: &http.Request{
    -					Header: map[string][]string{},
    -				},
    +				Request:    req,
     				Header: map[string][]string{
    -					"Location": {"test"},
    +					"Location": {"/v2/test/blobs/uploads/test"},
     				},
     			}, nil
     		default:
    @@ -202,7 +200,7 @@ func (c mockRemoteClient) Do(req *http.Request) (*http.Response, error) {
     				URL:    &url.URL{Path: "/v2/test/referrers/" + zeroDigest},
     			},
     		}, nil
    -	case validRepo:
    +	case "/v2/test/blobs/uploads/test", validRepo:
     		return &http.Response{
     			StatusCode: http.StatusCreated,
     			Body:       io.NopCloser(bytes.NewReader([]byte(msg))),
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requesttriageNeeds evaluation for feasibility, timeline, etc.

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions