oras-project/oras-go

What Five of the six workflows declare no permissions block, so each one runs with whatever the repository default grants. That default is currently write: $ gh api repos/oras-project/oras-go/actions/permissions/workflow {"default_workflow_permissions":"write","can_approve_pull_request_reviews":true} So build, codeql-analysis, lint, release and stale each receive a GITHUB_TOKEN with write access to every scope — contents, issues, pull requests, packages — regardless of what they actually do. lint.yml, for example, hands a repo-writable token to a third-party linter action for a job whose only output is a pass/fail. Workflow Today Needs build.yml (none — write all) contents: read lint.yml (none — write all) contents: read codeql-analysis.yml (none — write all) contents: read, security-events: write release.yml (none — write all) contents: write stale.yml (none — write all) issues: write, pull-requests: write license-checker.yml contents: write, pull-reques

What ErrReferrersCapabilityAlreadySet in registry/remote/referrers.go is exported but never returned by anything in the tree: $ git grep -n ErrReferrersCapabilityAlreadySet -- '*.go' registry/remote/referrers.go:52: ErrReferrersCapabilityAlreadySet = errors.New(...) SetReferrersCapability silently ignores a conflicting set rather than reporting one, and the error's own doc comment describes it as "reserved to signal" — dead public surface. v3 is the moment to drop it rather than carry it for the life of the major release. Proposed change Delete the ErrReferrersCapabilityAlreadySet var from registry/remote/referrers.go. Reword the SetReferrersCapability doc comment in registry/remote/repository.go so the no-op-on-conflict behaviour reads as deliberate instead of as an oversight, and point callers at ReferrersCapability to read back the effective value. Why the signature should stay as it is The obvious companion change would be restoring an error return on SetReferrersCapability so

What buildMirrorRepositories in registry/remote/builder.go is at 14.3% statement coverage (2 of 14). Only the empty-mirrors guard is exercised: if len(props.Mirrors) == 0 { return nil, nil } Everything after that — the per-mirror loop that assembles mirrorProps, calls builder.Build, constructs the Registry, applies the PullFromMirror default, and appends the result — is untested. Why it matters This function is what turns declarative mirror configuration into the Repository instances that pulls are actually routed through. Two behaviors in particular are load-bearing and currently unpinned: An empty PullFromMirror must default to PullFromMirrorAll. Silently defaulting the other way would send traffic somewhere unintended. A mirror whose client fails to build must return a wrapped error naming the offending m.Location. Without that, a misconfigured mirror is very hard to diagnose. What to do Add tests to registry/remote/mirror_test.go. Suggested cases: 1. Multiple mirrors, hap

What Add a runnable example_test.go to registry/remote/retry documenting the package's public API on pkg.go.dev. Why Nearly every other public package in the module ships godoc examples: content/example_test.go, content/cache/example_test.go, content/file/example_test.go registry/example_test.go, registry/remote/example_test.go registry/remote/auth/example_test.go, registry/remote/config/example_test.go, registry/remote/credentials/example_test.go, registry/remote/policy/example_test.go, registry/remote/properties/example_test.go, registry/remote/signature/example_test.go registry/remote/retry has none, so its pkg.go.dev page shows no usage guidance even though configuring retry behavior is a common thing users need to do. Scope Create registry/remote/retry/example_test.go in package retry_test (external test package, so the examples read as real consumer code), with the standard ORAS Apache-2.0 license header. Suggested examples covering the exported surface: ExampleNewClient — t

Description All GitHub Actions workflows in this repo pin their actions to a full commit SHA with a trailing version comment — except .github/workflows/lint.yml, which still uses floating tags. https://github.com/oras-project/oras-go/blob/main/.github/workflows/lint.yml Current state on main: Workflow Pinned to digest? build.yml ✅ codeql-analysis.yml ✅ license-checker.yml ✅ release.yml ✅ stale.yml ✅ lint.yml ❌ - name: Checkout uses: actions/checkout@v7 - name: Set up Go uses: actions/setup-go@v7 - name: Run golangci-lint uses: golangci/golangci-lint-action@v9 Why this matters Git tags are mutable. Anyone who can push to the action's repo (or anyone who compromises it) can move v7 to point at different code, and it will silently run in our CI with whatever token permissions the job has. Pinning to an immutable commit SHA is the standard mitigation, and it's what OpenSSF Scorecard's Pinned-Dependencies check and