drupal_warmup

The repository default workflow permission is read-only (default_workflow_permissions: read), so a job or workflow specifying nothing receives the lowest token. Every workflow additionally sets an explicit minimal top-level permissions block that jobs inherit, and elevated scopes are granted only on the individual jobs that require them.

Official releases are produced by GoReleaser, triggered only on SemVer git tags (refs/tags/v*), and the release version is taken from the tag. Tag names are unique in Git, so each release has a unique version identifier. No release has been tagged yet; the process enforces uniqueness once one is.

The project uses Go modules (go.mod/go.sum) for all dependency ingestion, the standard tooling for the language, with checksum verification via go.sum and an explicit go mod verify step in the release pipeline. Dependabot manages updates through the same module files.

GoReleaser emits checksums.txt with each asset's SHA-256 hash, and the release workflow signs it with a Sigstore keyless attestation (actions/attest, subject-checksums: checksums.txt) bound to the workflow's OIDC identity. The attestation is verifiable with gh attestation verify and published as a release asset, so every release asset is covered by a signed manifest of hashes.

The README's "Dependencies" section describes how the project selects dependencies (stdlib and golang.org/x without review, others vetted), obtains them (Go modules with go.sum checksum verification and go mod verify in the release pipeline), and tracks them (go.mod/go.sum committed, Dependabot for scheduled updates).

The README's "Build from source" section states the sole prerequisite (Go 1.27.1+, per go.mod), notes that dependencies are fetched automatically by Go modules, and gives the clone-and-make build steps, with the other make targets and the release-only GoReleaser dependency described.

The README's "Maintainers" section lists the project's sole member with access to sensitive resources (repository admin, CI/CD, and release signing) by name and GitHub handle.

The README's "Maintainers" section defines the project's one role, maintainer, and its responsibilities: reviewing and merging changes via pull request, releasing and signing, triaging issues and security reports, and dependency upkeep.

CONTRIBUTING.md documents the contribution process (pull requests against the protected main branch) and the requirements for acceptable contributions: passing make (staticcheck, race-detector tests, build), tests for new behaviour, 100% coverage, gofmt-clean code, Conventional Commits, and GPL-3.0 licensing.

The default-branch ruleset requires the CI test job, CodeQL, and dependency-review checks to pass before a pull request can merge, with no bypass actors, so a commit reaches main only when its automated status checks pass.

The CI workflow runs the race-enabled Go test suite on every pull request; that job is a required status check on the default branch, so no commit is accepted without the automated tests passing.

docs/design.md documents the system's actors (operator, tool, origin, asset CDN, Xdebug) and every action the tool takes, including a sequence diagram of the warm flow and a trust-boundary description. It is linked from the README's Design section.

The released software is a command-line binary; all Go packages are internal, so it exposes no importable API. Its sole external interface, the CLI, is documented in the README: every command, flag, argument, the stdin list source, the stdout report format, exit statuses, and environment variables.

SECURITY.md's "Security assessment" section identifies the most likely and impactful security problems for a tool that fetches URLs with credentials (credential disclosure, sending credentials to unintended hosts, cleartext transmission, sensitive data in logs, supply-chain compromise, and unintended debugger activation) and states how the design mitigates each.

SECURITY.md's "Reporting a Vulnerability" section defines a private reporting channel, a first-response timeframe of one business day (Mon-Fri), and a coordinated process: fixes are worked out with the reporter, who is credited and decides on public disclosure.

Met on the contact form documented in SECURITY.md, namely https://osinet.fr/contact

SECURITY.md's "Published advisories" section states that fixed vulnerabilities are published as GitHub Security Advisories on the repository, feeding the public GitHub Advisory Database and OSV, and are recorded under a Security heading in the CHANGELOG.