oras-project/oras-go

Split out of #338, which has now been closed. The chunked wire protocol landed in #1434; this issue tracks the other half of #338 — pushing content whose descriptor is not fully known in advance. Problem Push (and content/oci) require a complete descriptor up front: the content's digest and size must be known before the upload starts. MaxChunkSize (#1434) does not change this — it only bounds the size of each PATCH body; the descriptor is still supplied and still verified. That leaves no way to push content that is being produced as it is uploaded — a stream, a pipe, or a tar being built on the fly — without first buffering it to disk or memory to compute its digest and length. Proposed API From #338: type UnsafePusher interface { // UnsafePush pushes the content, matching the specified field in the expected descriptor. // - The `Digest` of the expected descriptor is recalculated if empty // - The `Size` of the expected descriptor is recalculated if less than zero // The re

Follow-up to #898, which tracked crypto agility for ORAS broadly. Most of that issue has since been addressed: Panics on unregistered/invalid digest algorithms were fixed in #926. SHA-512 support landed via #864. Pulling a manifest whose registry-reported digest uses a different algorithm than the one requested is handled by #1425. What remains is the write side, which this issue tracks. 1. Let callers choose the digest algorithm when packing oras.PackManifest has no way to select a digest algorithm. It builds descriptors through content.NewDescriptorFromBytes, which uses digest.Canonical (SHA-256) unconditionally: https://github.com/oras-project/oras-go/blob/main/pack.go So even in a deployment that has standardized on SHA-384 or SHA-512, anything produced by PackManifest is SHA-256. The same gap applies to the other helpers that derive a descriptor from bytes. Proposal: add an algorithm option to PackManifestOptions (and a matching descriptor helper that takes an explicit digest.Al

Supersedes #1363, which carried the same problem statement plus five open API questions. Those questions are now decided and written down below, so this issue can be implemented without another round of design discussion. The work was claimed by @ArtSummers in #1363 and is still theirs if they want it. All code references are pinned to 7f80a16. Problem Scopes are carried as strings ("repository:hello-world:pull,push") everywhere: ScopeRepository builds one, WithScopesForHost / AppendScopesForHost store them, CleanScopes parses them apart and re-serializes them, and Client.Do joins them back into a cache key. Every append re-parses the whole set. The parsing is duplicated in three places with different rules: the len(scopes) == 1 fast path splits on the last colon, the slow path splits on the first and last, and neither agrees with the other on what counts as a well-formed scope. Evidence: CleanScopes does not de-duplicate scopes it cannot parse The doc comment promises "the scopes pass

Split out of #1384, where @QIW9 spotted it. It is a bug today, and #1384 is blocked on it. Problem FileStore.Get on a docker config.json falls back to a scan when the exact key is absent (registry/remote/internal/configfile/configfile.go:149-165): authCfgBytes, ok := cfg.authsCache[serverAddress] if !ok { // NOTE: the auth key for the server address may have been stored with // a http/https prefix in legacy config files, e.g. "registry.example.com" // can be stored as "https://registry.example.com/". for addr, auth := range cfg.authsCache { if ToHostname(addr) == serverAddress { ToHostname cuts at the first / (configfile.go:415-420): func ToHostname(addr string) string { addr = strings.TrimPrefix(addr, "http://") addr = strings.TrimPrefix(addr, "https://") addr, _, _ = strings.Cut(addr, "/") return addr } So ToHostname("example.com/team-a") is example.com. Given an auths map with example.com/team-a and no bare example.com key, a host-level lookup for example.com returns team-

Problem The v2 release workflow is keyed on the head branch name: if: github.event.pull_request.merged == true && startsWith(github.head_ref, 'release/') && ... and it derives the version to tag by stripping the release/ prefix off that branch name. That made sense when release/vX.Y.Z branches were maintained, but they no longer are: v2 is always the latest v2, and a release simply tags its tip. Keying the release on a branch-name convention now has a few drawbacks: The branch name carries release semantics, so a contributor can trigger (or accidentally miss) a release purely by how they named a branch. It conflicts with the repo's conventional branch prefixes (feat/, fix/, chore/, ...). The version is interpolated straight from github.head_ref into the shell script, and a branch that doesn't parse silently produces a garbage version rather than failing. Requested change Trigger the v2 release from a release label on the PR, and read the version from the PR title: Gate the job on co