trentpower.fr

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

Work lands on feature branches, graduates to a preprod branch, and is promoted to main. All three stages are public; nothing appears as a finished release out of nowhere.

Repository on GitHub, which uses git. git is distributed.

Each release is an edition, identified by its date. Editions are tagged (edition/YYYY-MM-DD) and their frozen archives live under /integrity/releases/ permanently.

Signed annotated tags, edition/YYYY-MM-DD, protected by a tag ruleset so they cannot be moved or deleted.

Each GitHub Release describes the edition in prose and points at the canonical signed record. https://github.com/trentpower/trentpower.fr/releases

No publicly known vulnerability has existed in this project. If one ever does, the release notes for the fixing edition will name it.

GitHub Issues with templates for broken pages, verification problems and documentation corrections. https://github.com/trentpower/trentpower.fr/issues

GitHub Issues.

I am the sole maintainer and I respond to what arrives. The repository is young and low-traffic; nothing has gone unanswered.

Same answer - enhancement requests get a response, even when the response is a polite no, since this is an authored publication.

Two private routes: encrypted mail using the published PGP key, or GitHub private vulnerability reporting. https://github.com/trentpower/trentpower.fr/security/advisories/new

SECURITY.md and the RFC 9116 security.txt at https://trentpower.fr/.well-known/security.txt both publish the route. https://github.com/trentpower/trentpower.fr/blob/main/SECURITY.md

Two private routes: encrypted mail using the published PGP key, or GitHub private vulnerability reporting. https://github.com/trentpower/trentpower.fr/security/advisories/new

No vulnerability reports have been received. My committed initial-response window is 14 days, stated in SECURITY.md, and as sole maintainer I expect to beat it comfortably.

tools/build/build.sh rebuilds the whole site from source, deterministically. CI rebuilds it independently on every promotion and compares the result against the committed record.

bash, python3 and npm. Nothing exotic.

Every build tool is FLOSS. The licensed typefaces are content, not tooling — the build fetches them and verifies every byte against the signed manifest.

A unittest suite under tools/quality/tests/ — including Hypothesis property-based tests — runs in CI on every pull request, alongside 36 blocking release-gate checks. How to run it is in docs/fuzzing.md and the PR template: python3 -m unittest discover -s tools/quality/tests

Standard Python invocation: python3 -m unittest discover -s tools/quality/tests -p 'test_*.py' URL: https://github.com/trentpower/trentpower.fr/tree/main/tools/quality/tests

The tests cover the shared library primitives, the template token engine, the badge generator and the check-report machinery; the blocking release gate then exercises the entire published artefact on every build. Between the two, little ships unexamined.

The source-quality job runs the suite on every PR to preprod/main. URL: https://github.com/trentpower/trentpower.fr/blob/main/.github/workflows/pr-checks.yml

The policy is written into the pull request template: new or changed tooling behaviour brings tests with it.

The most recent significant change added property-based tests for exactly the surfaces it touched — and the first run of those tests found and fixed a real escaping bug, which is the policy doing its job.

It is a checklist line in .github/PULL_REQUEST_TEMPLATE.md, so every change proposal restates it.

ruff for Python, eslint for JavaScript, stylelint for CSS, shellcheck and shfmt for shell — all in CI, with CodeQL on top.

The linters run at zero findings and I keep them there. CodeQL's findings were fixed in dedicated rounds before the repository opened.

Standard-strict configurations, and the quality gate has a documented switch (QUALITY_ENFORCE) to turn any finding into a blocker.

I designed the site's defence model myself — strict CSP, subresource integrity, cross-origin isolation, signed manifests, an allow-list of what the server may expose — and wrote it up in docs/SECURITY-AND-PRIVACY.md.

he mitigations show the awareness: context-aware escaping in the template engine (property-tested) against XSS, hash-pinned dependencies and SHA-pinned actions against supply-chain drift, push protection and a blocking history scan against leaked credentials.

Standard, published primitives only: SHA-256 manifests, SHA-384 subresource integrity, Ed25519 commit signing, RSA-4096 PGP signatures via GnuPG.

Everything cryptographic is delegated to GnuPG, OpenSSH and Python's hashlib. I have re-implemented nothing.

GnuPG, OpenSSH and hashlib are all FLOSS, and the published verification guide walks through the whole chain using only those tools.

RSA-4096, Ed25519 and SHA-256/384 all clear the NIST 2030 minimums. There is no weaker mode to configure.

Nothing in the trust chain touches a broken algorithm — no MD5, no SHA-1, no DES or RC4.

Digests are SHA-256 and SHA-384 throughout; SHA-1 appears nowhere.

I implement no key-agreement protocol. TLS, with its forward-secret ciphersuites, belongs to the hosting layer.

There are no users to authenticate and no passwords to store; the published site is static.

The software generates no keys or nonces at runtime. My signing keys were generated locally by GnuPG and OpenSSH with their standard CSPRNGs.

HTTPS with HSTS on the site, HTTPS at GitHub — and beneath TLS, every published file is covered by the PGP-signed integrity manifest, so tampering is detectable even past the transport.

Hashes are served over HTTPS and anchored by detached PGP signatures; there is no http anywhere in the chain.

None outstanding. The last advisories that touched a committed requirements file were fixed the same day the scanner raised them.

Same-day turnaround is the demonstrated practice, and reviewing Dependabot, CodeQL and OSV results is a written step in the promotion checklist.

GitHub secret scanning with push protection, plus my own blocking scan of the full git history on every pull request. Signing keys have never been in the repository — that boundary is part of the design.

CodeQL analyses every pull request; ruff, eslint, stylelint and shellcheck run in the same gate.

CodeQL runs its security query suites for Python and JavaScript.

CodeQL's findings were fixed in dedicated rounds before the repository went public, and no high or critical alerts are open. Reviewing them stays on the promotion checklist.

Every pull request, every push, plus a weekly scheduled run.

Two kinds: Hypothesis property-based tests drive the build tooling with generated adversarial input before every release, and post-deploy smoke tests exercise the live site — routes, headers, CSP, signature validation — after every production deploy.

Nothing here is written in a memory-unsafe language — HTML, CSS, JavaScript, Python and shell only.

The property tests are built from assertions — escaping must be total, generated SVG must stay well-formed, slugs must be idempotent. The published static site carries no runtime assertions, deliberately.

Dynamic analysis has found one defect so far — control characters slipping through the badge escaper into SVG — and it was fixed the same day. docs/fuzzing.md tells that story.