# zit 0.3.23

zit 0.3.23 answers an HTTP Basic challenge. A forge that gates a read
answers a clone's first request with 401; the credential can now reach the
wire on that first request, which is the one a private repository refuses.

No artifact, tag namespace, sync message, or on-disk repository format
changed. One HTTP request header is new, sent only when a peer asks for it.

## The round that could not carry the card

0.3.22 taught `clone` and `pull` to send a login card, and a private
repository on a read-gating forge was still unclonable. The two halves
were each correct alone. A clone cannot sign its first request, because the
card's shared secret is derived from the project code and the project code
is what the first reply teaches; fossil's client sends no card on that
round either. And the forge refuses the first request with an HTTP 401,
which the transport treated as fatal, so the round that would have carried
the card never came. The server's log showed one request per clone and no
credential offered, whether or not one was given.

Fossil's own server never gates a read at the HTTP layer, so the retry
0.3.22 added, which fires on a protocol-level refusal that teaches the
project code, was the right answer to fossil and no answer to a forge.
Fossil's client reaches a forge with `--httpauth`, an HTTP Basic header on
every request, and that is the mechanism a first request can use.

## The transport answers the challenge

When a verb holds a plaintext password, from `--password`, `ZIT_PASSWORD`,
or the prompt, the transport keeps a Basic credential ready and sends
nothing until asked. A 401 whose `WWW-Authenticate` names the Basic scheme
is answered by sending the same round again with the `Authorization`
header, and every later round carries it, as fossil's does. After the first
reply teaches the project code the login card rides the later rounds as
before, so a peer that admits either is served either way.

A 401 is no longer a bare status. With a challenge and no password to
answer it, such as a pull on a stored login, the message says the peer
wants a login and names the flags. With a credential sent and still
refused, it says the peer refused the login. A 401 without a challenge says
so.

A read-only account on a forge whose card secrets exist only for writers
can now read with Basic, which is the case the card never covered.

## Verification

- Transport unit tests: a Basic challenge is recognized case-insensitively
  and a Bearer or absent challenge is not; the header value is the one
  fossil's `--httpauth` sends.
- An end-to-end test stands an authenticating gate in front of `zit serve`:
  every request without `Authorization` is answered 401 with a Basic
  challenge, every request with it is relayed. An anonymous clone is
  refused with the message naming the flags; a clone with `--user` and
  `--password` lands, and the gate's log shows its first request bare and
  every request after it carrying the header.

## Compatibility

- No on-disk repository or wire format changed; Fossil RFC revision 00
  remains the target.
- The header is sent only after a peer challenges for it, and only when a
  plaintext password was given to the run. A stored login never produces
  one. A peer that never challenges sees exactly the requests it saw before.

## Qualification

`zig fmt --check`, `zig build test`, `e2e`, `smoke`, `muscle`,
`git-import-e2e`, `git-export-e2e`, `dst`, and `cross`, plus the
three-runner CI battery.