docs(nip-fi): document Git smart-HTTP credential exemption

[wpfleger96]

Amend NIP-FI HTTP ingress with an explicit Git smart-HTTP credential-helper exemption. The exception covers method binding, endpoint-URL binding, and the payload tag requirement for info/refs, git-upload-pack, and git-receive-pack, while preserving per-request NIP-FI assertion, key pairing, and deny-map enforcement.

The spec records Git's credential-protocol limitation, the required compensating controls, and the rule that this exception is limited to these endpoints and is superseded by per-request signing.

Related: PR #7264

[github-actions]

🔐 Codex Security Review

Note: This is an automated, security-focused review generated by Codex.
Use it as a supplement to human review; false positives are possible.

Scope

• Exact PR diff: 47d068e2109d077414cbf2f4f1c927f6d051037a...b804f05a41e124af49ce23ef67f45bfa9dd4a96f
• Model: gpt-5.6-sol

💡 Click "edited" above to see earlier reviews for this PR.

---

Review Summary

Overall Risk: HIGH

The Git exemption turns a clone proof into a short-lived bearer credential capable of authorizing pushes to the same repository.

Findings

[HIGH] Clone credentials can be replayed for arbitrary pushes

• Category: Auth
• Location: docs/nips/NIP-FI.md:551 (source)
• Description: The exemption removes method, endpoint, and payload binding simultaneously. An observer who obtains a valid clone request's NIP-98 event and paired bearer assertion can reuse them within the 60-second window on git-receive-pack with an attacker-chosen body. The pre-receive hook only evaluates the authenticated pubkey's existing role and branch rules; it provides no client-signed proof that the user intended this push. TLS, separate routes, and repeated signature verification do not prevent replay because the specification explicitly accepts the same credential on both routes.
• Impact: Credentials exposed through a proxy, trace, log, or compromised intermediary can be used to push attacker-controlled commits as a push-capable victim, potentially compromising hosted source and downstream builds.
• Recommendation: Retain an operation binding even if body hashing is unavailable. Have the info/refs challenge identify git-upload-pack versus git-receive-pack and include that capability in the signed event, rejecting read-scoped proofs on push routes. Pushes should additionally carry a client-signed, replay-protected authorization bound to the repository and proposed ref updates, such as through a custom remote helper or signed push certificate.

Notes

• No additional limitations were reported.

---

_{Generated by Codex Security Review |
Requested by: @wpfleger96 |
Workflow run}