git push fails because the NIP-98 credential is scoped to discovery GET and is not sent on git-receive-pack POST

[nandubatchu]

Describe the bug

Pushing to a Buzz-hosted Git repository fails with HTTP 401 even when repository ownership, relay authorization, and signing credentials are valid. Authentication succeeds for receive-pack discovery, but Git sends the subsequent streamed POST without an Authorization header. The relay challenges that POST, but Git cannot replay it after receiving the challenge.

Steps to reproduce

1. Configure a valid Buzz repository remote and the git-credential-nostr credential helper.
2. Push a branch with git push.
3. Inspect the HTTP exchange:
   1. Git probes GET /git/<owner>/<repo>/info/refs?service=git-receive-pack.
   2. The relay responds with a Nostr authentication challenge scoped to GET.
   3. git-credential-nostr generates a GET-scoped NIP-98 credential; Git retries discovery and receives HTTP 200.
   4. Git sends POST /git/<owner>/<repo>/git-receive-pack without an Authorization header.
   5. The relay responds with HTTP 401 and WWW-Authenticate: Nostr realm="buzz", method="POST".
   6. The push aborts because Git cannot replay the streamed POST after the challenge.

Expected behavior

A valid push should authenticate the git-receive-pack POST preemptively with a fresh, POST-scoped NIP-98 credential and complete without a 401 challenge.

Version and platform

• Buzz version: unknown
• OS: macOS
• Git: 2.50.1
• Buzz Git relay using NIP-98 authentication
• git-credential-nostr credential helper

Logs / additional context

Root-cause evidence:

• A direct POST carrying a helper-generated, POST-scoped NIP-98 credential returns HTTP 200.

• Injecting the same kind of credential preemptively makes the push succeed:

  git -c http.extraHeader="Authorization: Nostr <POST_SCOPED_TOKEN>" push

• The successful authenticated POST rules out repository ownership, auth-tag, relay provisioning, and repository-permission failures.

This indicates an authentication-handshake mismatch: discovery authenticates a GET, but that credential is neither valid for nor attached to the later POST. Challenging only after the streamed POST begins is too late for Git to recover.

Workaround:

Generate a fresh POST-scoped NIP-98 token and attach it preemptively using http.extraHeader for the push. Tokens should remain short-lived and must not be logged or persisted in repository configuration.

Recommended fix:

Before invoking git-receive-pack, have the Buzz Git integration attach a fresh NIP-98 Authorization header whose URL and method match the POST request. Alternatively, establish a short-lived authenticated session during discovery that is accepted by the subsequent POST.

Please also add an integration test covering the full smart-HTTP push sequence and asserting that the POST succeeds without relying on a replay after a 401 challenge.

[yinkev]

I traced this on current main (c7089d3b) before taking the issue, and the missing POST authorization does not reproduce with the shipped helper.

Controlled smart-HTTP probe:

• built git-credential-nostr from current source;
• challenged unauthenticated info/refs with the normal Nostr GET challenge;
• served a real git http-backend receive-pack flow;
• tested Apple Git 2.50.1 (Apple Git-155) and Git 2.53.0;
• repeated with the server closing every connection to mimic a proxy boundary.

In every run the push succeeded. The request sequence was:

GET  info/refs         no Authorization -> 401
GET  info/refs         Nostr auth        -> 200
POST git-receive-pack  Nostr auth        -> 200

The authenticated GET and POST carried the same generated credential. Current relay code intentionally supports this Git constraint by scoping the token to the repository root and not rechecking its HTTP method on smart-HTTP routes.

A helper/relay change is therefore premature. The remaining likely discriminator is local configuration or a bundled-helper version mismatch. Please add:

• git --version;
• the origins and values of credential.helper, credential.useHttpPath, and any URL-scoped credential-helper entries;
• a sanitized Git HTTP trace retaining request paths, status codes, and whether each request had an authorization header.

Remove every authorization value and all private-key material from the trace; only header presence/absence is needed.

[lynford-u]

Reproduced in a managed Buzz agent on macOS (Buzz Desktop v0.4.24, Apple Git 2.50.1). With the canonical ephemeral config (credential.helper=; credential.useHttpPath=true; credential.https://<relay-host>.helper=<git-credential-nostr>), discovery completes after the GET Nostr challenge, but POST /git-receive-pack carries no Authorization header and receives 401 with WWW-Authenticate: Nostr realm="buzz", method="POST".

The URL-scoped /git runtime configuration and a process-scoped helper override have the same result. No persistent Git config or remotes were changed, and no credential material is included here. This appears to be the managed-agent Git smart-HTTP credential handoff path rather than repository authorization.

[yinkev]

Correction to my earlier comment: the failure does reproduce on current main (c2a4ee71), but only when the generated pack exceeds Git's default http.postBuffer and Git switches to its large-request path.

Controlled reproduction with Apple Git 2.50.1 and the current git-credential-nostr:

2 MiB incompressible push, default http.postBuffer:
GET  info/refs         no Authorization -> 401
GET  info/refs         Nostr auth        -> 200
POST git-receive-pack  no Authorization, Content-Length: 4 -> 401
push aborts

The same 2 MiB push with http.postBuffer=5242880 succeeds:

GET  info/refs         no Authorization -> 401
GET  info/refs         Nostr auth        -> 200
POST git-receive-pack  Nostr auth, Content-Length: 2098181 -> 200

I also isolated the large-request sequence by allowing only Git's unauthenticated 4-byte probe POST to return 200. Git then sent the real chunked request with the existing Nostr credential and Expect: 100-continue, and the push completed. That pins the failing boundary:

• small/content-length pushes reuse the discovery credential and work;
• large pushes first send an unauthenticated 4-byte probe;
• challenging that probe with 401 aborts the flow before Git reaches the authenticated chunked POST.

So this is not a repository-permission or key problem, and the reporter's managed-agent observation is valid. A bounded current workaround is to set http.postBuffer above the expected pack size for the individual push; that is not a durable product fix because pack size is unbounded and buffering large pushes increases memory use.

The durable fix should cover the full smart-HTTP large-push sequence in an integration test before changing auth behavior. The two plausible seams are:

1. make the Git client path attach authorization to the 4-byte probe; or
2. let an already-authenticated discovery session admit that probe without weakening authorization for the real receive-pack request.

I am continuing the investigation from this now-reproducible boundary.

[yinkev]

Additional isolation: the relay does not need to buffer the large push or establish a broader authenticated session.

I reproduced the large-push sequence with Git 2.47.3 and a fake authtype=Nostr credential helper against a real git http-backend. Four server behaviors for the unauthenticated four-byte POST /git-receive-pack probe produced:

401 challenge                         -> push fails
forward `0000` to git-http-backend    -> real authenticated chunked POST follows; push succeeds
200 + receive-pack result type + empty body
                                      -> real authenticated chunked POST follows; push succeeds
200 + receive-pack result type + `0000`
                                      -> real authenticated chunked POST follows; push succeeds

The successful minimal case was:

POST /git/<owner>/<repo>/git-receive-pack
Content-Type: application/x-git-receive-pack-request
Content-Length: 4
Authorization: <absent>

0000

responding with:

HTTP/1.1 200 OK
Content-Type: application/x-git-receive-pack-result
Content-Length: 0

Git then sent the actual pack as a separate request:

POST git-receive-pack
Authorization: Nostr <credential>
Transfer-Encoding: chunked
Expect: 100-continue
body: ~2 MiB pack

This narrows the durable server fix to a very small compatibility shim before the current GitAuth extractor:

• only POST .../git-receive-pack;
• only when Authorization is absent;
• exact receive-pack request MIME;
• exact Content-Length: 4;
• exact body 0000;
• return an empty receive-pack-result 200 without hydrating a repository, running Git, checking repository existence, or mutating state;
• every other unauthenticated request retains the current Nostr challenge.

That keeps the real pack fully authenticated, avoids a repository-existence oracle if the probe response is path-independent, and makes the compatibility request computationally constant. The regression should use an incompressible pack above Git's default http.postBuffer, because the existing small-text pushes never enter this path.

[vbalko-claimate]

Hit this exact same thing today pushing to a fresh repo (git 2.51.2, macOS/arm64). Small commit, ~1.06 MiB of loose objects (a few docx/png/drawio files), so right around the postBuffer line — matches the theory in #4401/#7156.

Trace looked identical to what's described here: GET info/refs?service=git-receive-pack gets challenged, credential helper signs it, retry succeeds with 200. Then the POST to git-receive-pack goes out with no Authorization header at all and gets a 401, and send-pack just gives up ("unexpected disconnect while reading sideband packet"). Never saw the helper get invoked a second time for the POST — git just assumed the earlier credential covered it.

The http.extraHeader="Authorization: Nostr <token>" workaround from the issue description works fine for me too. I generated the token by feeding the helper the same protocol/host/path it would've used for the receive-pack URL and grabbing the credential= line, then passed it as a static header for the whole push. Since the relay doesn't check that the signed method matches the actual HTTP method, a POST-scoped (or even GET-scoped) token works either way.

Good to see there are already two PRs open for this (#4401 narrower, #7156 more general). Would be nice to see one of them land — this is the kind of thing that makes a first git push to a new repo just silently fail with no obvious path forward if you don't already know the workaround.