goshort

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.

The public GitHub repository contains all interim commits between releases. For example, between v0.5.0 and v0.6.0 there are 10+ incremental commits (feature additions, docs, hotfixes) each committed to main as work progressed. Releases are marked with annotated git tags; the commits themselves are never withheld. No interim versions have been omitted.

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

Every release intended for user consumption has a unique SemVer version number (v0.1.0 → v0.6.0, 9 releases to date), corresponding to an annotated git tag and a GitHub Release. The version number is reflected in the CHANGELOG, git tag, and GoReleaser-built binary filenames (e.g., goshort_linux_amd64.tar.gz under the tagged release).

Every release is tagged in git (v0.0.1 through v0.6.0 — 10 tags). Tagging is automated via GoReleaser: pushing a v* tag triggers the GitHub Actions release workflow, which builds cross-platform binaries, pushes a multi-arch Docker image to ghcr.io, and publishes a GitHub Release with auto-generated assets.

Non-trivial release notes file in repository: https://github.com/anIcedAntFA/goshort/blob/main/CHANGELOG.md.

GoShort has had no publicly known run-time vulnerabilities with a CVE assignment (or equivalent) at the time any release was created. The CHANGELOG does include a ### Security section in v0.5.1 (proactive SSRF hardening in the preview fetcher), but this was a developer-initiated hardening, not a response to a publicly disclosed CVE. The govulncheck CI workflow scans dependencies on every push against the Go vulnerability database.

Non-trivial SECURITY[.md] file found file in repository: https://github.com/anIcedAntFA/goshort/blob/main/SECURITY.md. [osps_do_02_01]

The project uses GitHub Issues with structured YAML templates for bug reports (bug_report.yml) and feature requests (feature_request.yml). blank_issues_enabled: false enforces template use. General questions are redirected to GitHub Discussions via config.yml.

The project launched in May 2026 and has received no bug reports to date via GitHub Issues. The maintainer is committed to acknowledging all bug reports; the 48-hour response SLA documented in SECURITY.md for vulnerability reports reflects the response posture. All prior discussions and questions have been responded to.

The project is newly launched (first release May 2026) and has received no enhancement requests via GitHub Issues yet. Enhancement requests are welcomed via the feature_request.yml issue template and GitHub Discussions. The active development roadmap (Phase 7+) demonstrates continued engagement with future enhancements.

URL:
https://github.com/anIcedAntFA/goshort/issues

GitHub Issues provides a fully public, searchable, permanently archived record of all bug reports and responses. GitHub Discussions (https://github.com/anIcedAntFA/goshort/discussions) serves as an additional public archive for questions and enhancement discussions.

URL:
https://github.com/anIcedAntFA/goshort/blob/main/SECURITY.md

SECURITY.md at the repository root documents the full process: do not open public issues for vulnerabilities; email ngockhoi96.dev@gmail.com with description, reproduction steps, impact, and optional fix. Supported versions and scope (in/out of scope) are also listed.

URL:
https://github.com/anIcedAntFA/goshort/blob/main/SECURITY.md

SECURITY.md instructs reporters to email ngockhoi96.dev@gmail.com directly rather than opening a public GitHub issue. Email in transit is protected by TLS (SMTP over TLS / STARTTLS), keeping the report private from the general public. The repository also has GitHub's private security advisory feature available at https://github.com/anIcedAntFA/goshort/security/advisories/new for reporters who prefer a web-based HTTPS submission.

No vulnerability reports have been received in the last 6 months. The project launched in May 2026. SECURITY.md commits to a 48-hour acknowledgement SLA for any future reports, which is well within the 14-day threshold.

Non-trivial build file in repository: https://github.com/anIcedAntFA/goshort/blob/main/Makefile.

Non-trivial build file in repository: https://github.com/anIcedAntFA/goshort/blob/main/Makefile.

The entire toolchain is FLOSS: Go compiler (BSD-style), make (GNU GPL), golangci-lint (GPL/MIT), sqlc (MIT), goose (MIT), GoReleaser (MIT), GitHub Actions runners (MIT), Docker (Apache 2.0), Bun (MIT), Astro (MIT). No proprietary build tools are required at any stage.

The project uses Go's built-in testing package (FLOSS, BSD-licensed as part of the Go toolchain). Test execution is documented in three places:

• README (make test, make test/race, make test/cover, make test/redis)
• CONTRIBUTING.md (make test, make lint)
• CI (.github/workflows/ci.yml): go test -race -tags redis -coverprofile=coverage.out -covermode=atomic ./... runs on every push and PR with a live Redis service container.

Tests are invoked via the standard Go command go test ./... and the idiomatic make test Makefile target — both are the community-standard invocation forms for Go projects. Additional targets (make test/race, make test/cover, make test/redis, make test/all) follow the same make test/<variant> pattern.

Current coverage from go test -race -tags redis ./...:

• shortener/ — 98.0% (core business logic)
• mcp/ — 91.4%
• preview/ — 89.3%
• storage/ — 80.0%
• safebrowsing/ — 75.9%
• Total: 76.1% (reported to Codecov on every CI run)

Beyond line coverage, the suite includes table-driven unit tests, httptest HTTP handler tests, MCP in-process transport tests, real SQLite integration tests, Redis integration tests, and nightly fuzz tests for URL/alias validation and the Sqids encoder.

GitHub Actions CI runs on every push to main and every pull request. The pipeline includes five concurrent jobs: lint (golangci-lint), test (race detector + Redis + Codecov upload), build (cross-compile), website (Biome lint + Astro build), and security (Gitleaks secret scan). Additionally: nightly fuzz job (3 fuzz targets × 60 s each) and per-PR benchmark job with regression alerting at 150% threshold.

CONTRIBUTING.md explicitly states the policy: "Write tests first — we practice TDD. Write a failing test, then make it pass." The PR checklist item "Includes tests for new behavior" reinforces this. The policy is formal and publicly documented, not merely informal.

Every major feature in recent releases ships with tests. CHANGELOG evidence:

• v0.5.0 — batch endpoint, QR endpoint, PATCH expiry, Safe Browsing, link previews: all covered by new handler and service tests; integration tests added with real SQLite.
• v0.5.1 — "Test files split by concern; integration tests added with real SQLite" explicitly noted in changelog.
• v0.6.0 — public endpoint and CORS: handler tests and integration tests added; CI test job covers them on every push.
  Codecov tracks coverage across all commits, making regressions visible immediately.

CONTRIBUTING.md documents the requirement explicitly in two places: the TDD workflow step ("Write tests first — we practice TDD") and the PR acceptance checklist ("Includes tests for new behavior"). The coding conventions section also specifies the expected test patterns (table-driven, t.Parallel(), httptest).

.golangci.yml enables 15 linters beyond go vet: staticcheck (comprehensive static analysis), errcheck (unchecked errors), gosec (security issues), errorlint (error wrapping), govet, revive (21 style rules), gocritic (diagnostic + style + performance tags), bodyclose, noctx, paralleltest, thelper, gocognit, ineffassign, unused, and prealloc. Formatters enforce gofmt, gofumpt, goimports, and gci. The website uses Biome v2 for TypeScript/Astro linting. All linting runs on every push and PR via the lint CI job.

The CI pipeline enforces zero warnings: the build job has needs: [lint, test] — a build only runs if linting passes cleanly. max-issues-per-linter: 0 and max-same-issues: 0 in .golangci.yml prevent suppressing issues by hitting a cap. The pre-commit lefthook runs golangci-lint on staged files before any commit reaches CI. The govulncheck workflow additionally scans for known Go CVEs weekly and on every push.

The linter configuration reflects a maximal-strictness posture: gocritic runs all three tag categories (diagnostic, style, performance); revive enables 21 specific rules; errcheck has check-type-assertions: true; max-issues-per-linter: 0 and max-same-issues: 0 mean there is no escape hatch through issue count caps. Exclusions are narrowly scoped (only _test.go files exempt from a few security-oriented checks like gosec G304 that are inapplicable in test contexts). The govet enable-all: false is an intentional choice
▎ to use govet defaults rather than disable it.

The primary developer demonstrates applied knowledge of secure design principles throughout the codebase:

• Fail-safe defaults: api_key = "" disables auth by default (opt-in); URL validation uses an allowlist of permitted schemes (not a denylist).
• Complete mediation: Every POST/GET/DELETE on /api/v1/* passes through AuthMiddleware; MCP endpoint has its own APIKeyMiddleware — neither is bypassable via Chi routing.
• Least privilege: Docker image runs as non-root goshort user; preview fetcher blocks private/loopback IPs (SSRF prevention).
• Limited attack surface: CORS middleware scoped only to the public endpoint group; MCP endpoint served on main port but behind its own auth layer; honeypot field on public endpoint silently deflects bots.
• Input validation with allowlists: URLs validated with scheme allowlist + 2048-char limit + private-IP block; aliases validated against ^[a-zA-Z0-9-]{3,30}$; all SQL via sqlc parameterized queries (no raw string interpolation).
  ▎ - Open design: Security relies on API key secrecy, not obscurity of the algorithm.

SECURITY.md explicitly lists known vulnerability classes in scope, demonstrating awareness and mitigation:

• SQL injection → mitigated by sqlc-generated parameterized queries; db/queries.sql is the only place SQL is written.
• SSRF → HTTPPreviewFetcher validates resolved DNS IPs against RFC 1918/loopback ranges; v0.5.1 patched a DNS-rebinding SSRF vector.
• Open redirect → original URLs validated on creation; gosec G710 suppressed with justification comment only where URL is pre-validated.
• Missing authentication → constant-time crypto/subtle.ConstantTimeCompare for API key checks in both REST and MCP middleware.
• Information disclosure → API key never logged; structured slog logging reviewed for sensitive field leakage.
• CORS misconfiguration → explicitly listed as in-scope; CORS scoped to the unauthenticated public endpoint only.

The project uses only crypto/subtle from Go's standard library (publicly reviewed, constant-time comparison for API key auth). TLS is terminated by Caddy (TLS 1.3/1.2, publicly standardised IETF protocols) and Cloudflare CDN — no custom or proprietary cryptographic protocols.

The project calls Go's standard library (crypto/subtle) rather than re-implementing cryptographic primitives. All TLS/cipher logic is delegated to Caddy or the underlying Go net/tls package.

All cryptographic functionality is implementable with FLOSS: Go stdlib crypto/subtle (BSD), Caddy (Apache 2.0), Go net/tls (BSD). No ▎ proprietary crypto library is required.

TLS is handled by Caddy, which defaults to ECDHE with P-256/X25519 (≥128-bit security) and RSA-2048 minimum — all meeting NIST requirements through 2030. The Go server does not directly configure TLS in production.

No deprecated algorithms are used: no MD4/MD5/SHA-1 for security, no RC4, no single DES, no Dual_EC_DRBG. The only cryptographic call is crypto/subtle.ConstantTimeCompare for constant-time byte comparison.

No SHA-1 (for security), no CBC mode, no weak cipher suites. Caddy defaults disable weak ciphers automatically. Go's crypto/tls drops RC4 and 3DES by default since Go 1.22+.

TLS via Caddy uses ECDHE key exchange by default (X25519, P-256), providing perfect forward secrecy. Cloudflare also enforces PFS on the CDN edge. The Go application itself does not terminate TLS.

The project does not store user passwords. Authentication is API-key based; the key is user-supplied via config file or environment variable and is never stored in the database.

The project does not generate cryptographic keys or nonces internally. API keys are user-supplied. Short codes are generated via a deterministic counter + Sqids (not a security primitive). No session tokens or crypto material is generated server-side.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

The project does not retrieve cryptographic hashes over HTTP for verification purposes. Binary releases are published as GitHub Release assets served over HTTPS. Docker images are pulled from ghcr.io over HTTPS. GoReleaser generates SHA256 checksums and signs releases. The CI pipeline uses pinned action versions (e.g., actions/checkout@v4) with SHA-pinnable references. No http:// URLs are used in production code to fetch downloadable artifacts.

The project has no publicly known vulnerabilities with CVE assignments. The govulncheck CI workflow scans all Go dependencies against the Go vulnerability database on every push to main and weekly, providing continuous exposure monitoring. The one proactive security fix (v0.5.1, DNS-rebinding SSRF in preview fetcher) was developer-initiated and released the same day it was identified.

No critical vulnerabilities have been reported. SECURITY.md commits to a 48-hour acknowledgement SLA and private patch development prior to release — well within any reasonable definition of "rapid." The govulncheck weekly scan ensures dependency-level critical CVEs surface before they age past 60 days.

The Gitleaks secret scan CI job (.github/workflows/ci.yml, zricethezav/gitleaks-action@v2) runs on every push with fetch-depth: 20 and would block merges if credentials were committed. .gitignore explicitly excludes .dev.vars* (Wrangler secrets) and .wrangler/. The committed goshort.toml has api_key = "" (empty placeholder). The lefthook pre-commit hook also performs a secrets scan before any local commit.

golangci-lint (FLOSS, GPL) with 15+ linters is applied on every push and PR via the lint CI job, and as a pre-commit hook via lefthook — making it mandatory before any code reaches main. This is a distinct static analysis step beyond Go compiler warnings. Key linters: staticcheck (comprehensive Go static analysis), gosec (security rules), govet (extended go vet), errcheck (unchecked errors), errorlint (error wrapping), bodyclose, noctx. Additionally, govulncheck (FLOSS) runs on every push scanning against the Go vulnerability database.

gosec (Go Security Checker) directly targets common vulnerability patterns: G101 (hardcoded credentials), G304 (file path injection), G401–G501 (weak crypto), G601 (implicit memory aliasing), SSRF-related patterns. staticcheck covers nil dereference, unreachable code, and misuse of sync primitives. govulncheck maps transitive dependency usage against published CVEs in the Go vulnerability database (NVD-backed).

The CI build job has needs: [lint, test] — a release build cannot proceed if golangci-lint reports any finding. Any medium-or-higher gosec finding must be either fixed or suppressed with an explicit //nolint:gosec // <reason> comment (the codebase has 6 such suppressions, all with justifications explaining why the finding is a false positive). max-issues-per-linter: 0 prevents silencing findings by hitting a count cap.

Static analysis runs on every commit: the lefthook pre-commit hook runs golangci-lint on staged Go files locally before commit, and the CI lint job runs the full suite on every push to main and every PR. govulncheck also runs on every push plus a weekly Monday schedule.

The project applies three distinct dynamic analysis tools before each release:

1. Race detector — go test -race runs on every push/PR in CI with a live Redis service container.
2. Fuzz testing — nightly CI job runs three fuzz targets for 60 s each: FuzzValidateURL, FuzzValidateAlias, FuzzSqidsEncoder_Encode.
3. govulncheck — dynamic reachability analysis confirms whether known-vulnerable code paths are actually called (not just present as transitive dependencies).

GoShort is written entirely in Go, a memory-safe language with no C/C++ components and no use of unsafe package in production code. Buffer overflows and memory corruption vulnerabilities are not applicable.

Dynamic analysis runs with assertions enabled:

• -race flag activates Go's built-in race detector, which instruments all memory accesses at runtime to detect data races — a form of runtime assertion not present in production builds.
• -covermode=atomic in CI enables coverage instrumentation.
• Fuzz tests use Go's native fuzzing engine which panics on any unhandled error, crash, or assertion failure, surfacing them as test failures.
  None of these flags are enabled in production builds (go build ./cmd/server).

No medium-or-higher severity exploitable vulnerabilities have been found via dynamic analysis. The race detector has reported zero races since its introduction. Fuzz targets have found no crashes to date. Any race condition or fuzz-discovered panic would block the CI build job (which depends on the test job) and therefore could not be released. The SSRF fix in v0.5.1 — though developer-initiated — was prompted by recognising a reachable exploit path during a preview fetcher code review, and was patched and released the same day.