In-app PR merge can't authenticate to relay git hosting: git-credential-nostr silently yields no credentials (and needs git ≥ 2.46)

[derekross]

Environment: Buzz Desktop AppImage on Pop!_OS 24.04 LTS, system git 2.43.0. Repo hosted on the relay's git hosting (https://<relay>/git/<owner>/<repo>.git), which requires NIP-98 on every request including fetches (anonymous GET /info/refs → 401, WWW-Authenticate: Nostr realm="buzz"; Basic auth is rejected).

Summary

The in-app project-feed merge always fails on a stock Linux install when the relay's git hosting requires auth. The merge clones with the system git, and the credential plumbing the app sets up never actually produces credentials:

Cloning into '/tmp/.tmpXXXXXX/repo'... fatal: could not read Username for
'https://<relay>/git/<owner>/<repo>.git': terminal prompts disabled

What we traced

1. The wiring is present. Spawned processes get:

   GIT_CONFIG_COUNT=2
   GIT_CONFIG_KEY_0=credential.https://<relay>/git.helper
   GIT_CONFIG_VALUE_0=$APPDIR/usr/bin/git-credential-nostr
   GIT_CONFIG_KEY_1=credential.https://<relay>/git.useHttpPath
   GIT_CONFIG_VALUE_1=true
   

2. But the helper has no key. Its own error strings say it needs $NOSTR_PRIVATE_KEY or git config nostr.keyfile (0600 keyfile) — neither is provided to the spawned git, so it cannot sign anything.
3. It fails silently. git-credential-nostr get exits 0 with empty stdout and empty stderr in every variant we tried (with/without NOSTR_PRIVATE_KEY as nsec or hex, with/without BUZZ_AUTH_TAG, with/without capability[]=authtype in the request). Git gets nothing, falls back to a terminal prompt, and dies. At minimum the "no nostr key configured" error should reach stderr so the merge surfaces a real diagnosis.
4. Even fully wired, stock git can't consume it. The helper's strings show it returns credential=/authtype=-style output, i.e. the credential-helper authtype protocol added in git 2.46. Distro git on Ubuntu-noble-based systems is 2.43, which never advertises capability[]=authtype and cannot send Authorization: Nostr … from a helper at all. There's no version check or error for this.

Net effect: clone 401s → merge fails, with a misleading "could not read Username" error.

Suggestions

• Pass the key material to the spawned git (e.g. a 0600 keyfile + GIT_CONFIG entry for nostr.keyfile), or perform the merge's git transport with credentials the app controls.
• Make git-credential-nostr fail loudly on stderr when it can't produce credentials.
• Check/document the minimum git version (≥ 2.46 for authtype helpers), or bundle a suitable git.
• Alternative that works on any git version: the relay (as observed) doesn't strictly bind the NIP-98 method tag per request, so a one-shot token via -c http.extraheader=Authorization: Nostr <token> per git invocation is sufficient for a whole clone/fetch/push.

Workaround we're using

A PATH-first git wrapper that detects the relay's git host, signs a fresh NIP-98 token (kind 27235, u = repo base .git URL + owner-attestation tag), and injects it via http.extraheader. With that in place the in-app merge completes end-to-end (clone → merge → push).

Related: #2315 (the AppImage env leak also crashed the merge's git-remote-https before we got this far).

[aco-linux]

Additional macOS reproduction on Buzz Desktop 0.5.11, git 2.49.0:

• The bundled helper is present at /Applications/Buzz.app/Contents/MacOS/git-credential-nostr.
• The agent process has BUZZ_PRIVATE_KEY and BUZZ_AUTH_TAG; mapping the former to NOSTR_PRIVATE_KEY did not make the bundled helper emit a usable credential.
• A normal push to an agent-owned, channel-bound repo reaches git-receive-pack and fails with HTTP 401.
• I built current main helper source locally and patched the missing-method path to fall back to HttpMethod::GET.
• With that patched helper, Git credential discovery succeeds and Git proceeds to send-pack, but the subsequent pack upload is rejected with HTTP 401.
• GIT_TRACE=1 shows one helper get, then git send-pack ... <repo>/ --stdin, followed by helper erase after the 401.

This suggests the initial GET credential is accepted but is not accepted for the later smart-HTTP POST. Git is behaving as designed by reusing the repo-scoped credential for the session. That appears inconsistent with the intended Git transport behavior described elsewhere in the repository, where one signed repo-root credential is reusable for discovery and pack requests.

No key material or Authorization token was logged. The test repository announcement included a buzz-channel binding, and the signing agent is the repository announcement author.