celeris

Public git repository: https://github.com/goceleris/celeris

Git records what changed, who and when; changes to main land through pull requests (336 of the 338 commits on main's first-parent history are PR merges): https://github.com/goceleris/celeris/commits/main

All development happens in the public repository between releases: every commit and pull request is visible, not only release snapshots (410 pull requests, 358 merged).

Git, hosted on GitHub.

Every release has a unique version tag (vX.Y.Z) and a GitHub Release, for example v1.5.11. The Release workflow rejects any tag that is not valid semver.

Semantic Versioning, enforced by the Release workflow. Compatibility rules are in GOVERNANCE.md ("Compatibility"). https://github.com/goceleris/celeris/blob/main/GOVERNANCE.md

Each release is a git tag (174 tags on origin, including per-sub-module tags such as middleware/otel/v1.5.11). Release tags are protected by a repository ruleset ("Release tags": no update, no deletion).

https://github.com/goceleris/celeris/releases
Release notes are the GitHub Releases. Each recent release has a written summary of what changed and why, grouped by Fixes, Security, Performance, Features and Breaking changes (generated from PR labels per .github/release.yml and hand-edited). The project deliberately has no CHANGELOG.md; CONTRIBUTING.md says GitHub Releases is the changelog. Example: https://github.com/goceleris/celeris/releases/tag/v1.5.11

No celeris release has fixed a vulnerability that had a CVE assigned to celeris itself. The repository has 0 published security advisories. The criterion excludes dependencies, so Go toolchain and x/net advisories do not count. (Protocol-level mitigations such as CVE-2023-44487 handling are described in SECURITY.md.)

https://github.com/goceleris/celeris/issues/new/choose
Bugs are reported through GitHub Issues with a bug-report form (engine, architecture, minimal reproduction) and a feature-request form. Blank issues are disabled in favour of the forms. See also CONTRIBUTING.md "Reporting Issues".

GitHub Issues: https://github.com/goceleris/celeris/issues

Reports are answered. Almost all issues are opened by the maintainer himself to track work (584 of 585 issues). 515 of the 585 issues are closed and 70 are open. The one external issue so far (#245) got a reply from the maintainer in about 41 hours: https://github.com/goceleris/celeris/issues/245

The one external enhancement request (#245) was answered within about 41 hours. Maintainer-filed feature issues are discussed and triaged in the open.

https://github.com/goceleris/celeris/issues?q=is%3Aissue
All reports and responses are in the public GitHub issue tracker, searchable and permanent.

https://github.com/goceleris/celeris/blob/main/SECURITY.md#reporting-a-vulnerability
The process is published in SECURITY.md (also surfaced by GitHub's Security tab and the issue-form chooser): report privately via GitHub private vulnerability reporting, or email security@goceleris.dev. Do not open a public issue. Acknowledgement within 72 hours, fix target within 7 days for critical issues, fixes announced via GitHub Security Advisory.

https://github.com/goceleris/celeris/security/advisories/new
Private reports go through GitHub private vulnerability reporting (HTTPS, visible only to maintainers) at the URL above, as documented in SECURITY.md; email security@goceleris.dev is the alternative. CONFIRM the inbox works (action 2); the GitHub channel alone is sufficient evidence.

No vulnerability reports were received in the last 6 months. The repository has 0 security advisories (published or draft). The policy commits to acknowledging within 72 hours.

Standard Go build: go build ./..., plus the Mage targets (mage build, mage check) documented in CONTRIBUTING.md "Build & Test". CI builds on Linux and macOS on every PR (job "Build"). Go modules pin dependencies by go.sum.

The standard Go toolchain, with Mage (Go-based make alternative) for task automation.

Go, Mage, golangci-lint and the other build tools are all FLOSS.

Automated tests use Go's standard go test framework (FLOSS, in the repo: 961 _test.go files, plus integration and spec suites in test/). Invocation is documented in CONTRIBUTING.md ("Build & Test", "Testing"): mage test or go test -race ./..., and CI runs them on every PR: https://github.com/goceleris/celeris/blob/main/.github/workflows/ci.yml

go test ./... (and mage test).

Coverage is measured on every push and reported to Codecov (about 74.6% of 36,464 lines on main as of 2026-10-11): https://codecov.io/gh/goceleris/celeris . Beyond unit tests there are h2spec/h1spec conformance suites and fuzz targets. Coverage is informational, not an enforced gate (codecov.yml).

GitHub Actions CI runs lint, race-detector unit tests, conformance tests, driver tests, builds on two OSes and a vulnerability check on every PR and every push to main; 7 of these checks are required to merge. https://github.com/goceleris/celeris/blob/main/.github/workflows/ci.yml

Policy in CONTRIBUTING.md "Pull Requests": "Include tests for new functionality". The PR template has a "Unit tests added/updated" checkbox. https://github.com/goceleris/celeris/blob/main/CONTRIBUTING.md#pull-requests

Recent major changes ship with tests. Examples: struct request binding (PR #459) added bind_struct.go together with bind_struct_test.go (327 lines); of the last 300 non-merge commits on main, 197 are feat/fix/perf and 180 of those (about 91%) touch a _test.go file; the latest engine fixes add many regression tests (for example commit 3cfee4b touches 16 test files).

Documented in CONTRIBUTING.md ("Pull Requests", "Testing") and in the PR template (.github/PULL_REQUEST_TEMPLATE.md, "Test Plan").

golangci-lint v2 with govet, staticcheck, errcheck, revive, ineffassign, unused, misspell, unconvert, unparam, prealloc and nolintlint, run in the required "Lint" CI job on the root module and all four sub-modules. Config: https://github.com/goceleris/celeris/blob/main/.golangci.yml

The Lint job is a required check, so a PR with lint findings cannot merge. Suppressions need a specific linter name and an explanation (nolintlint require-explanation and require-specific).

Linters are opted in explicitly (11 enabled, default none), formatting is enforced with gofmt and goimports, go vet runs through golangci-lint, and workflow files are additionally checked with actionlint and zizmor. The exclusions are narrow and listed in .golangci.yml.

3.5 Security

At least one primary developer (the maintainer) knows how to design secure software and applies the classic principles in celeris. Concrete examples from the code and policy: fail-safe defaults and fail closed (the database drivers refuse an unsupported TLS mode instead of silently downgrading; size limits and a read-header timeout apply by default); least privilege and separation of privilege (the JWT, session, CSRF and rate-limit middleware live in separate modules/packages so an application only links what it uses); complete mediation (every protocol path, HTTP/1.1, HTTP/2 and WebSocket, goes through the same size and framing checks, with request-smuggling hardening in the HTTP/1 parser and an HTTP/2 rapid-reset rate limit); economy of mechanism and least common mechanism (small internal packages with narrow interfaces; io_uring completions are generation-tagged so a late completion cannot touch a reused buffer); open design (source, protocol parsers, tests and the security policy are public; nothing relies on obscurity); psychological acceptability (the secure behaviour is the default and the unsafe options are explicit, named settings). See SECURITY.md and CONTRIBUTING.md in the repository.

At least one primary developer (the maintainer) knows the common kinds of errors that lead to vulnerabilities in an HTTP server and database-driver library, and at least one way to counter each. Request smuggling and framing ambiguity: strict parsing that rejects ambiguous Content-Length / Transfer-Encoding combinations. Header and CRLF injection: CRLF and NUL sanitisation of response headers. Resource exhaustion and slow-client denial of service: size limits on every protocol path, bounded queues with a slow-consumer policy, timeouts, and the HTTP/2 rapid-reset limit. Memory-safety style bugs in the native engines (use-after-free, buffer reuse while an operation is in flight): generation-tagged io_uring completions, buffer ownership rules, and the race detector and checkptr runs, long soak runs, and fuzz targets (mage fuzz). Timing attacks: constant-time comparison for secrets. Missing authentication/authorization and weak credential handling: standard-library cryptography only (HMAC-SHA256, PBKDF2, SCRAM-SHA-256, crypto/rand), no home-made primitives. Process: CWE numbers are recorded in the commit message of security-sensitive changes (CONTRIBUTING.md), CodeQL and govulncheck run in CI, and findings are triaged with a written reason. See SECURITY.md "Scope" and the per-version security notes.

celeris only uses standard, published algorithms through Go's standard library: HMAC-SHA256, PBKDF2-HMAC-SHA256 (basicauth helper, SCRAM-SHA-256 for PostgreSQL), RSA / ECDSA / Ed25519 signature verification for JWT, and crypto/rand for tokens.

No cryptography is implemented in the project. All primitives come from the Go standard library (crypto/*), and TLS is the Go standard library's, supplied by the application (celeris is cleartext by design, README "TLS" note).

Everything that depends on cryptography uses the Go standard library, which is FLOSS.

celeris does not generate or negotiate long-term keys. Its own defaults are SHA-256 based (HMAC-SHA256, PBKDF2-HMAC-SHA256 with 600,000 iterations, SCRAM-SHA-256), and the JWT middleware rejects RSA keys under 2048 bits from JWKS and supports P-256/P-384/P-521 and Ed25519. TLS key sizes are decided by the application's Go crypto/tls configuration.
Honest caveat for the maintainer: keys passed directly in jwt.Config are not length-checked (HMAC secrets only log a warning; RSA keys only get the 2048 check on the JWKS path). The criterion says smaller key lengths must be possible to disable completely. If the maintainer wants this airtight, either add a 2048-bit check to config-supplied RSA keys and make short HMAC secrets an error, or answer N/A with "celeris generates and negotiates no keys". Both are defensible; Met is my pick.

No broken algorithm is used for any security mechanism by default. MD5 appears in exactly two places: the PostgreSQL client's MD5 password response, used only when the PostgreSQL server itself requests that method (protocol interoperability; SCRAM-SHA-256 is also supported), and memcached key distribution, which is not a security mechanism. SHA-1 appears once, for the WebSocket Sec-WebSocket-Accept value that RFC 6455 mandates. CodeQL flagged the PostgreSQL MD5 and it was triaged with this reasoning (alerts #8, #25).

No default security mechanism relies on weak algorithms. SHA-1 (WebSocket handshake, mandated by RFC 6455, not a security control) and MD5 (PostgreSQL server-requested auth, interoperability only) are protocol requirements; see crypto_working.
Alternative: if the maintainer prefers strictness, mark Unmet and use the same text as the explanation. SHOULD criteria allow Unmet with a reason.

celeris implements no key-agreement protocol. The io_uring and epoll engines are cleartext only by design; any TLS is the application's Go crypto/tls configuration, whose defaults provide forward-secret key exchange.

celeris does not store passwords for authenticating external users; the application supplies its own credential store. The basicauth middleware only verifies credentials, in constant time, against what the application configures. (A PBKDF2-HMAC-SHA256 helper with 600,000 iterations and a random 16-byte salt, HashPasswordPBKDF2 / VerifyPassword, is on main and ships with v1.6.0; it is not in v1.5.11.)
Alternative: Met, but only once v1.6.0 is released. Use N/A for now.

Keys, tokens, IDs and salts are generated with crypto/rand (request IDs, the session and CSRF middleware, the basicauth PBKDF2 salt and per-process HMAC key). math/rand is used only for retry-backoff jitter in drivers and for bind diagnostics, neither of which is security-sensitive.

celeris is distributed as a Go module: source is fetched over HTTPS from GitHub through proxy.golang.org, and verified against the sum.golang.org checksum database. Release tags are immutable (repository ruleset forbids moving or deleting v* tags), so a moved tag cannot silently change a release.

No hash is fetched over HTTP. The project ships no downloadable binaries or checksum files; dependencies are verified through go.sum and the Go checksum database.

No known unpatched vulnerability of medium or higher severity has been public for over 60 days. The repository has 0 security advisories, 0 open Dependabot alerts and 0 open secret-scanning alerts. The most recent public advisories touching dependencies, five Go net/http and x/net HTTP/2 issues published 2026-10-08, are already fixed on main (x/net v0.60.0, CI on Go 1.27.2), and a release carrying them is planned within the 60-day window.

SECURITY.md sets a target of a fix within 7 days for critical issues, and earlier Go standard-library advisories were handled by toolchain bumps (see the SECURITY.md notes for Go 1.26.3 and 1.26.4). No critical advisories are open.

No credentials in the public repository. GitHub secret scanning and push protection are enabled, and there are 0 open secret-scanning alerts.

Static analysis runs on every pull request and every push to main: golangci-lint with staticcheck and govet (required "Lint" check), govulncheck (required "Vulnerability Check"), and actionlint and zizmor on the workflows; the release workflow re-runs this CI. GitHub CodeQL for Go and GitHub Actions (default setup) also scans pull requests and pushes to main, and weekly. https://github.com/goceleris/celeris/blob/main/.github/workflows/ci.yml

CodeQL's Go security queries and govulncheck both look for common vulnerabilities.

There are no open CodeQL findings. 14 code-scanning alerts were fixed, and 12 were dismissed with written reasons (false positives such as the protocol-mandated PostgreSQL MD5 response, and bounded integer conversions). The only open code-scanning alerts are Scorecard's own meta-checks (#20 this badge, #26 dependency advisories, see action 3).

On every PR and every push to main (CodeQL and golangci-lint), and govulncheck on every PR; CodeQL also has a weekly scheduled scan.

The Go race detector runs on the unit, adaptive, io_uring and middleware test steps of the CI that gates every PR and runs again from the release workflow. The conformance job runs h2spec/h1spec against a running server. The repo also contains 43 Go fuzz targets (run with mage fuzz), and the separate probatorium cluster matrix exercises releases under load.

The project is written in Go, a memory-safe language, with no C, C++ or assembly (no cgo, no .s/.c/.h files in the tree). Where unsafe is used, tests run under the race detector, which also enables checkptr.

Tests run with go test -race, which enables the race detector and Go's checkptr pointer-safety instrumentation. A dedicated build tag (celeris_closeprobe) adds extra close-path checks, vetted and tested in CI.

Problems found by the race detector and by soak runs were fixed: SECURITY.md records two memory-safety races closed in 1.5.x, and the release notes for v1.5.8-v1.5.11 list fixes found by dynamic testing. No open exploitable vulnerability from dynamic analysis is known.
Alternative: N/A is allowed if the maintainer prefers ("not running dynamic analysis finds nothing"), but the project does run it, so Met is the more accurate answer.

4. Evidence index (for the maintainer's reference)