Git: is_safe_refname rejects legal git ref names containing '+'

[Zigoljube]

Git: is_safe_refname rejects legal git ref names containing + (and other git-valid characters)

Summary

crates/buzz-relay/src/api/git/manifest.rs — is_safe_refname() allows only [a-zA-Z0-9_./-] (plus the structural refs/ checks). Git's own rules (git check-ref-format) additionally permit characters like +, @, =, ,, !, and ] in ref components. Refs that git happily creates therefore cannot be pushed to Buzz at all.

This is not hypothetical: OriginTrail/dkg (a real upstream repo) contains the branch

refs/heads/test/842+841-devnet

and pushing it fails with HTTP 400 — it is the single ref out of 1,339 that cannot be mirrored into Buzz git.

Reproduction

git init t && cd t && git commit --allow-empty -m x
git branch "test/842+841-devnet"          # git accepts this name fine
git push <buzz-remote> refs/heads/test/842+841-devnet:refs/heads/test/842+841-devnet
# → error: RPC failed; HTTP 400

git check-ref-format --branch "test/842+841-devnet" exits 0 — the name is legal git.

Suggested fix

Widen the allowed alphabet in is_safe_refname to the git-legal set while keeping the structural protections that actually matter for the object-store keys (no .., no //, no control chars, no leading/trailing slash, refs/ prefix). Since refnames are used as object-store key components, characters outside the current set could be percent-encoded at the storage boundary instead of rejected at the protocol boundary — the doc comment already notes the predicate is shared symmetrically by write validation and hydration, so a single encode/decode pair at that seam keeps the "valid CAS, un-clone-able output" invariant intact.

A conservative first step that covers the observed real-world case: add + (and ideally @) to the alphabet — neither has meaning to the object-store key scheme nor to path traversal.

Environment

Relay at 63496cc1d; observed 2026-08-01 while mirroring OriginTrail/dkg.

[iroiro147]

Shipped a PR for this: #4257

Widens is_safe_refname to [a-zA-Z0-9_./+-@]. The +/@ pair was the conservative suggestion from the issue body — both are legal git ref characters with no meaning to the CAS key scheme or path traversal, and the predicate is shared symmetrically by write-side validate and read-side hydrate, so widening once fixes both sides of the seam.

Kept the widening bounded: =, ,, !, ] (also git-legal but un-observed in wild mirrors) are still rejected — easy follow-up if a real case appears.

Regression coverage extends both safe_refnames tests (manifest + hydrate):

• positive: refs/heads/test/842+841-devnet, refs/tags/release@v1
• negative: =, ,, !, ] still rejected

cargo check and cargo test -p buzz-relay --lib safe_refnames green. The 10 unrelated pre-existing failures in api::media / telemetry are untouched.

[alanshurafa]

Also addressed by #4214, which additionally widens the kind:30618 emission filter (is_emittable_ref) and the RefPattern literal alphabet — without those, a +/@ ref pushes but never appears in branch listers and can't be named by a literal protection rule. Comparison with the other open PRs in its body.

[iroiro147]

PR #4348 open — addresses the original is_safe_refname widening plus two sibling predicates flagged in #4257 review that re-spelled the old alphabet (is_emittable_ref in manifest_event.rs, RefPattern::parse in buzz-core/src/git_perms.rs:152). Supersedes #4257.