Bound the receiver rate limit per client IP across /webhook/* (closes #139)

The receiver limiter keyed buckets on (client IP, request path). The
route pattern /webhook/{uuid} matches any single segment, so a client
that invented a fresh path per request minted a fresh bucket per
request and never refilled one: its aggregate rate against the only
unauthenticated, internet-exposed endpoint was unbounded, and every
one of those requests reached an entrypoint lookup before it 404ed.

Put a second limiter in front of it, keyed on the client IP alone and
covering the whole route at ten times the configured per-entrypoint
limit (1200/min by default). The per-entrypoint limit is unchanged and
still wanted; it just bounds nothing in aggregate on its own. Ten
entrypoints' worth of headroom lets one sender address drive several
entrypoints at full rate while still capping what one address costs
the receiver. The multiplication saturates rather than wrapping, since
nothing bounds RECEIVER_RATE_LIMIT from above and a negative limit
would reject every request.

The aggregate limiter is the outer one, so it counts the requests the
per-entrypoint limiter rejects; a test pins that order by exhausting
one path against the inner limit and then requiring a request to an
unused path to be rejected.

Move the handler's INFO line for an incoming webhook below the
entrypoint lookup. The UUID is attacker-controlled path text, so
logging it first let a client write an INFO line per invented path; a
miss is already logged at DEBUG and the request is already in the
access log.

Give the aggregate limiter its own 429 handler that logs at DEBUG and
without the path, rather than the shared one that logs at WARN with
it. Its rejections are one line per request of the very flood it
exists to bound, so the shared handler would have let a client write
its own text into the operator's log at an alerting level once per
request. What this limiter bounds is the database work an invented
path costs; the access log still records every request once at INFO,
and the README now says so instead of claiming DEBUG-only logging.

.dockerignore

@@ -1,6 +1,3 @@
-# .ci-fingerprint is deliberately NOT excluded: it is the CI cache barrier
-# that keeps the check stages from replaying a cached pass. See the lint
-# stage of the Dockerfile.
 .git/
 bin/
 *.md

.gitea/workflows/check.yml

@@ -11,53 +11,5 @@ jobs:
     steps:
       - name: Checkout
         uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2 2024-10-23
-        with:
-          # The fingerprint step below needs history to find the last commit
-          # that touched the Docker build context.
-          fetch-depth: 0
-
-      - name: Neutralize superseded run statuses
-        # Gitea cancels the in-flight run when another commit is pushed to the
-        # same branch and records the cancellation as `failure`, so a commit
-        # that was never tested reads red. The cancellation is unconditional
-        # server-side for push events and cannot be disabled from a workflow
-        # file, so the superseding run rewrites those statuses to `skipped`.
-        # Only the exact cancellation status is touched; a real failure is
-        # left alone.
-        env:
-          GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }}
-        run: |
-          set -eu
-          api="${GITHUB_API_URL}/repos/${GITHUB_REPOSITORY}"
-          ctx='check / check (push)'
-          for sha in $(git rev-list --max-count=20 "${GITHUB_SHA}^" || true); do
-            latest="$(curl -sf "${api}/commits/${sha}/status" | jq -r \
-              --arg c "$ctx" \
-              '[.statuses[] | select(.context == $c)][0] // empty
-               | "\(.status)|\(.description)"')" || continue
-            [ "$latest" = 'failure|Has been cancelled' ] || continue
-            curl -sf -X POST "${api}/statuses/${sha}" \
-              -H "Authorization: token ${GITEA_TOKEN}" \
-              -H 'Content-Type: application/json' \
-              -d "$(jq -nc --arg c "$ctx" '{
-                context: $c,
-                state: "skipped",
-                description: "Superseded by a newer commit; never tested"
-              }')" >/dev/null
-            echo "neutralized superseded status on ${sha}"
-          done
-
-      - name: Fingerprint the build context
-        # `.dockerignore` keeps docs out of the build context, so a docs-only
-        # commit legitimately replays the whole image from cache and stays
-        # cheap. Every other commit writes a new fingerprint into the context,
-        # which invalidates the `COPY . .` layer of both check stages: a
-        # commit that was never linted, formatted-checked, tested and built
-        # cannot report success from cache.
-        run: |
-          set -eu
-          fp="$(git log -1 --format=%H -- . ':!*.md' ':!LICENSE' ':!.editorconfig')"
-          printf '%s\n' "${fp:-$GITHUB_SHA}" > .ci-fingerprint
-
       - name: Build Docker image (runs make check)
         run: script/cibuild

.gitignore

@@ -41,7 +41,4 @@ data/
 
 # Temporary files
 tmp/
-temp/
-
-# CI cache barrier, written into the build context by the check workflow
-.ci-fingerprint 
+temp/ 

Dockerfile

@@ -12,11 +12,7 @@ WORKDIR /src
 COPY go.mod go.sum ./
 RUN go mod download
 
-# Copy source code. In CI the context also carries .ci-fingerprint, whose
-# value changes with every commit that touches the build context (see
-# .gitea/workflows/check.yml). That invalidates this layer, so the checks
-# below cannot report success by replaying a cached pass. Do not add it to
-# .dockerignore.
+# Copy source code
 COPY . .
 
 # Run formatting check and linter
@@ -40,8 +36,7 @@ WORKDIR /build
 COPY go.mod go.sum ./
 RUN go mod download
 
-# Copy source code, including the .ci-fingerprint cache barrier described in
-# the lint stage above.
+# Copy source code
 COPY . .
 
 # Run tests and build

README.md

@@ -867,19 +867,14 @@ limit leaves room for one address to drive several entrypoints at their
 full rate, and it is not configurable separately.
 
 What that aggregate limit bounds is the database work an invented path
-costs; log volume it caps rather than eliminates. A path that names no
-entrypoint is recorded by the handler at `DEBUG`, and the aggregate
-limiter logs its own rejections at `DEBUG` and without the path, so
-neither appears at all under the default level. The per-entrypoint
-limiter is the loud one: it still logs every rejection at `WARN` with
-the request path, which on this route is attacker-controlled text. A
-client hammering a single invented path is served `RECEIVER_RATE_LIMIT`
-requests and has the rest of its aggregate budget rejected there, so
-the aggregate limit is what bounds those `WARN` lines — to under ten
-times `RECEIVER_RATE_LIMIT` per minute per client IP, 1080 at the
-defaults, where before it there was no bound at all. The access log is
-bounded by neither limit: every request is recorded once at `INFO` with
-its full URL, served or rejected alike.
+costs, not the number of log lines it produces. The path is
+attacker-controlled, so nothing on this route writes it to the log
+above `DEBUG`: a path that names no entrypoint is recorded by the
+handler at `DEBUG`, and the aggregate limiter logs its rejections at
+`DEBUG` and without the path. Every request is still recorded once by
+the access log, at `INFO`, with its full URL, whether it was served or
+rejected — so a flood of invented paths still writes one `INFO` line
+per request.
 
 Every limiter here — receiver, login, and password change — identifies
 the client the same way, through one shared key function: the
@@ -1141,34 +1136,6 @@ binary is statically linked and runs on Alpine.
 `docker build .` is the CI gate — if it passes, the code is formatted,
 linted, tested, and compiled.
 
-#### CI gate honesty
-
-A layer cache lets `docker build .` exit 0 in seconds with the lint and
-test stages replayed rather than executed, which would make a green
-check meaningless. The `check` workflow therefore writes
-`.ci-fingerprint` into the build context before building. Its value is
-the hash of the last commit that touched the build context, so:
-
-- Any commit that changes code (including a squash merge whose tree
-  matches an already-built branch) gets a new fingerprint, invalidates
-  the `COPY . .` layer of both check stages, and really runs
-  `make fmt-check`, `make lint`, `make test`, and `make build`. A run
-  that reports success ran them.
-- A docs-only commit leaves the fingerprint unchanged — `.dockerignore`
-  excludes `*.md` and `LICENSE` from the context anyway — so the image
-  replays from cache and costs seconds.
-
-The module download layer sits above `COPY . .` and stays cached either
-way.
-
-The workflow's first step covers a second way the gate lied: Gitea
-cancels an in-flight run when a newer commit lands on the same branch
-and records that cancellation as a `failure` status, marking a commit
-red that was never tested. Cancellation is unconditional server-side for
-push events, so the superseding run rewrites the exact
-`Has been cancelled` status to `skipped`. Genuine failures are never
-touched.
-
 ## TODO
 
 See [TODO.md](TODO.md).

internal/middleware/ratelimit.go

@@ -171,11 +171,9 @@ func (m *Middleware) clientKey(r *http.Request) string {
 	return peer.String()
 }
 
-// tooManyRequests returns the 429 handler used by the login,
-// password-change and per-entrypoint receiver limiters: it logs the
-// rejection with logMessage and answers with responseMessage.
-// httprate adds the Retry-After header (RFC 6585). The aggregate
-// receiver limiter uses floodTooManyRequests instead.
+// tooManyRequests returns the 429 handler shared by every limiter:
+// it logs the rejection with logMessage and answers with
+// responseMessage. httprate adds the Retry-After header (RFC 6585).
 func (m *Middleware) tooManyRequests(
 	logMessage, responseMessage string,
 ) http.HandlerFunc {