Modernise: SHA-256 signatures, constant-time GitLab tokens, no HMAC in logs, Go 1.25

[jbdevprimary]

Two security fixes, one logging leak, and a toolchain bump. Offered as one PR
because they land together in the fork this came from and the project has been
quiet since 2020 — take whatever is useful.

go build, go vet and the full test suite pass on Go 1.26.

1. GitHub SHA-256 signatures

GithubProvider.Validate checked only X-Hub-Signature (HMAC-SHA1). GitHub
sends X-Hub-Signature-256 on every delivery and its documentation
says to use it. A proxy validating only SHA-1 is doing weaker checking than the
payload already permits, on the one process this project deliberately exposes to
the internet.

SHA-256 is now preferred, with SHA-1 kept as a fallback — GitLab and older
GitHub Enterprise send SHA-1 only, and dropping it would break working
deployments for no gain when SHA-256 is absent.

When both headers are present, SHA-256 decides. Falling back to SHA-1 on a
bad SHA-256 would let an attacker choose the weaker algorithm by pairing a
valid SHA-1 with a forged SHA-256. TestValidateRejectsBadSHA256EvenWithValidSHA1
covers exactly that.

2. The computed hash is no longer logged

IsValidPayload did log.Printf("Calculated Hash: %s", hash) on every
delivery. The digest is derived from the shared secret over a body the caller
chooses, so writing it to logs publishes an oracle — and it debugs nothing the
rejection itself does not already show.

3. GitLab token comparison is constant-time

GitlabProvider.Validate used ==. Go's string comparison returns as soon as
two bytes differ, so rejection time is a function of how many leading characters
the caller guessed right, and a webhook endpoint is public and accepts unlimited
attempts.

Unlike GitHub, GitLab sends the token verbatim rather than a signature, so
this string is the credential and the comparison is the whole of the check.
Now subtle.ConstantTimeCompare. Whitespace trimming is preserved deliberately;
some proxies pad the header.

4. Go 1.13 → 1.25, and dependency refresh

The module was pinned to a toolchain that left support some years ago; thirteen
releases of security fixes sat behind a one-line bump. httpmock 1.0.4 → 1.4.1.

Tests

TestGithubProvider_Validate was entirely commented out, which is why the
implementation carried // TODO: Update implementation and tests. It is now
eleven real cases: both algorithms, the downgrade attempt, a tampered payload, a
wrong secret, malformed prefixes and lengths, nil headers, and an empty SHA-256
header falling through to SHA-1. Signatures are computed from the helpers
rather than pasted, so a change to a helper fails the tests instead of quietly
agreeing with itself.

Three cases added for GitLab: a prefix of the secret, a length-equal near-miss
with the last byte changed, and the whitespace case.

One thing to strip if you take this

The diff renames the module path to github.com/jbcom/GitWebhookProxy (the
fork). That is obviously not something to merge — revert go.mod and the five
files' import lines and the rest applies cleanly. I kept it in rather than
maintain two branches, since the alternative was asking you to review the same
work twice.

---

From a fork at jbcom/GitWebhookProxy,
where these are already merged. If this project is no longer maintained, no hard
feelings — but the three fixes are worth having for anyone still running it, and
I would rather offer them back than keep them.

[jbdevprimary]

Adding a fourth fix, and it is the most serious one

I built the image and probed it rather than trusting the unit tests, and found
an authentication bypass that the tests do not reach.

proxyRequest ran the ignored/allowed-user filter before signature
validation and answered 200 to anything it decided to ignore. isIgnoredUser
treats an empty committer on the github provider as ignored
(proxy.go, committer == "" && p.provider == GithubName), so an
unsigned request reaching that branch got a 200 from a proxy that had never
authenticated it.

Measured against the built image with GWP_SECRET set and no signature header
at all:

Incoming request from user:
Ignoring request for user:
-> HTTP 200

Nothing is forwarded upstream, which is presumably why it survived — but a
public endpoint reporting success for a request it refused to authenticate is
exactly what a probe looks for.

The committer name is read from the payload, and a payload is only
trustworthy after the signature says so. Deciding anything on it first —
including deciding to ignore it — is deciding on attacker-supplied data.
Validation now runs first.

The regression test took two attempts, which is worth mentioning

My first one used the gitlab provider and passed with the bug deliberately
reintroduced — gitlab has no empty-committer case, so it never reaches that
branch. The github version fails with got 200 want 400 against the old
ordering. Verified by swapping the blocks back, not assumed.

Also in this push

Both signature headers are now optional at the parser. GetHeaderKeys()
conflates "headers I want forwarded" with "headers that must be present", so
listing X-Hub-Signature-256 there made both mandatory and rejected every
delivery carrying only one. Requiring either is wrong in a different direction:
SHA-256 excludes GitLab and older GHE, SHA-1 excludes a sender that has dropped
the legacy header. The real rule — at least one, strongest wins — can only be
stated in Validate, so GetOptionalHeaderKeys() was added to the Provider
interface. That is an interface change, so it is a breaking one for any
out-of-tree provider; flagging it explicitly.

A self-contained Dockerfile. build/package/Dockerfile expects a binary
already compiled beside it, so it cannot be handed to a platform that builds
from a repository, and Dockerfile.build is Go 1.13 plus packr on a GOPATH
layout. The new root Dockerfile builds from source in one pass — digest-pinned
Go 1.25, CGO off, distroless static-debian12:nonroot runtime with no shell and
no package manager.

Verified against the running image

case	result
SHA-256 only, valid	200
SHA-1 only, valid	200
forged SHA-256 + valid SHA-1	400
no signature at all	400
tampered body, valid signature	400
disallowed path	403

The unsigned-request 200 is gone.