Option to discourage/disallow anonymous HTTP(S) fetching (first-fetch nudge → block, login for token URL) #19

New issue

Open

opened 2026-07-11 11:33:32 +02:00 by qwc · 1 comment

qwc commented

2026-07-11 11:33:32 +02:00

Owner

Motivation

Today HTTP(S) fetches are anonymous by default (identity policy: SSH rejects unknown keys; HTTP identity is optional — anonymous fetch OK, invalid token → 401). That's fine for a small setup, but in a larger org it defeats attribution: when a fetch is anonymous, triage/notify has no principal to route to, so any follow-up (a quarantine, a CVE that needs an owner, "who pulled this bad ref?") falls back to a central person instead of the actual consumer. We want to push people onto identified fetching so the RecipientsForRepo / notify path resolves to the real user.

Proposed behavior (to refine later)

A configurable HTTP-identity mode, roughly:

open (current) — anonymous allowed, no nudge.
nudge (the nice one) — allow the first anonymous fetch from a given IP/identity, but inject a message into the git output warning that further anonymous fetches from this IP will be blocked, and telling the user to log into the proxy web UI to get a personal, token-baked clone URL and configure git globally (git config --global url."https://<token>@proxy/…".insteadOf …). Subsequent anonymous fetches from that IP → blocked (ERR / 401).
enforce — anonymous fetching disallowed outright; missing/invalid token → 401 from the start.

Mode should be settable globally, and plausibly per-repo later (some public mirrors may stay open).

Open questions / notes for refinement

In-band nudge needs sideband (Strategy B). Under the current Strategy A (git http-backend CGI) we can't inject an informational message into a successful fetch — only the block path (single ERR pkt-line) surfaces text. The "allow first, warn in output" step depends on the deferred Strategy B (drive upload-pack directly) work that unlocks band-2 sideband messages. Until then, nudge could degrade to: serve silently the first time, then block with an ERR message that contains the login/token instructions.
Grace key = IP vs identity. "First fetch" needs a subject. IP is the obvious key for anonymous, but NAT/shared egress makes it coarse (one dev's fetch consumes the whole office's grace). Consider IP + a short TTL, or a per-CIDR allowance, or making the grace a one-shot informational banner rather than a hard per-IP block.
Token-URL UX. The web UI already mints tokens; add a copy-paste "configure git" snippet (the insteadOf + token URL) on the account page so the nudge has a concrete destination. Basic-auth password slot already carries the token today.
Interaction with enforce + CI. CI/robots should use tokens (ties into robot users, #2) — enforce mode assumes everyone who matters is identified.
Relates to attribution precision (notify is repo-precise, not ref-precise — Strategy B want-parsing would sharpen both this and the nudge).

Scope

Design/refine-later placeholder — no implementation yet. Config knob + the enforce mode are cheap and independent of Strategy B; the nudge-with-in-band-message is the part gated on the sideband work.

## Motivation Today HTTP(S) fetches are **anonymous by default** (identity policy: SSH rejects unknown keys; HTTP identity is optional — anonymous fetch OK, invalid token → 401). That's fine for a small setup, but in a **larger org it defeats attribution**: when a fetch is anonymous, triage/notify has no principal to route to, so any follow-up (a quarantine, a CVE that needs an owner, "who pulled this bad ref?") falls back to a central person instead of the actual consumer. We want to push people onto **identified** fetching so the `RecipientsForRepo` / notify path resolves to the real user. ## Proposed behavior (to refine later) A configurable HTTP-identity mode, roughly: 1. **`open`** (current) — anonymous allowed, no nudge. 2. **`nudge`** (the nice one) — allow the **first** anonymous fetch from a given IP/identity, but **inject a message into the git output** warning that further anonymous fetches from this IP will be blocked, and telling the user to **log into the proxy web UI to get a personal, token-baked clone URL** and configure git globally (`git config --global url."https://<token>@proxy/…".insteadOf …`). Subsequent anonymous fetches from that IP → blocked (ERR / 401). 3. **`enforce`** — anonymous fetching disallowed outright; missing/invalid token → 401 from the start. Mode should be settable globally, and plausibly per-repo later (some public mirrors may stay `open`). ## Open questions / notes for refinement - **In-band nudge needs sideband (Strategy B).** Under the current Strategy A (`git http-backend` CGI) we can't inject an informational message into a *successful* fetch — only the block path (single `ERR` pkt-line) surfaces text. The "allow first, warn in output" step depends on the deferred **Strategy B (drive `upload-pack` directly)** work that unlocks band-2 sideband messages. Until then, `nudge` could degrade to: serve silently the first time, then block with an ERR message that contains the login/token instructions. - **Grace key = IP vs identity.** "First fetch" needs a subject. IP is the obvious key for anonymous, but NAT/shared egress makes it coarse (one dev's fetch consumes the whole office's grace). Consider IP + a short TTL, or a per-CIDR allowance, or making the grace a one-shot informational banner rather than a hard per-IP block. - **Token-URL UX.** The web UI already mints tokens; add a copy-paste **"configure git" snippet** (the `insteadOf` + token URL) on the account page so the nudge has a concrete destination. Basic-auth password slot already carries the token today. - **Interaction with `enforce` + CI.** CI/robots should use tokens (ties into robot users, #2) — enforce mode assumes everyone who matters is identified. - Relates to attribution precision (notify is repo-precise, not ref-precise — Strategy B want-parsing would sharpen both this and the nudge). ## Scope Design/refine-later placeholder — no implementation yet. Config knob + the `enforce` mode are cheap and independent of Strategy B; the `nudge`-with-in-band-message is the part gated on the sideband work.

qwc added the

identity

Kind/Enhancement

transport

labels

2026-07-11 11:36:50 +02:00

qwc commented

2026-07-11 11:37:08 +02:00

Author

Owner

Moved the greeting / onboarding-page detail to its own issue: #20. This issue (#19) depends on that page existing — the nudge/enforce messaging points users there to configure git properly.

Moved the greeting / onboarding-page detail to its own issue: #20. This issue (#19) *depends on* that page existing — the nudge/enforce messaging points users there to configure git properly.

qwc referenced this issue

2026-07-11 11:37:25 +02:00

Greeting / "get up to speed" onboarding page with pasteable git-config snippet #20

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

qwc-open/tulli#19

No description provided.

Rows
Columns