Friendly forks of upstream projects.

When an upstream project we depend on is unmaintained, slow to move, or simply missing something we need, we fork it here rather than vendoring a patch and forgetting about it. The fork stays honest about what it is: upstream keeps the credit, the licence stays upstream's, and every change is one we would happily see merged back.

If you can get a fix upstream, do that first. These forks exist because that was not possible or not timely — not because we think we own the code.

• xz — a fork of ulikunitz/xz, in two passes. First decoding speed: the per-operation allocations removed, a branchless range decoder, match copies by pattern doubling, and a ParallelReader that decodes the blocks of a multiblock archive concurrently. Then robustness against archives that were built to break a decoder — impossible sizes rejected, the stream index read incrementally and bounded so the backwards walk terminates, the dictionary grown on demand rather than up front, and Close able to cancel a read already blocked in a worker. Upstream appears inactive; the changes are deliberately kept in a shape that could be carried over if anyone has the time.
• erofs — a fork of erofs/go-erofs: a pure-Go library for reading and creating EROFS filesystem images through the standard fs.FS interface, no CGO. The work here is mostly about surviving images we did not write — allocations bounded by what the image can physically hold, cyclic directory graphs and oversized directory and symlink sizes rejected — alongside correctness fixes (fs.FS contract conformance, chunk extents mapped at block granularity with holes preserved, setuid/setgid/sticky bits kept on both the read and write paths) and additions to the writer.
• blake3 — a fork of lukechampine/blake3, a Go implementation of the BLAKE3 hash with AVX2/AVX-512 routines and the bao verified-streaming encoding. The changes come out of an audit of the tree: an XOF Seek to almost any buffer-unaligned offset returned output from the wrong position (latent since 2020), bao slice bounds could overflow past validation and the empty encoding was rejected, New now validates its key and size instead of panicking deep inside, and the allocation and parallelism behaviour is tuned so small XOF reads and streaming writes stop paying for work they do not use.
• grid-clock-screensaver — a fork of chrstphrknwtn/grid-clock-screensaver, a word-clock screensaver for macOS, ported to modern macOS.
• go-graphviz — a fork of goccy/go-graphviz: Go bindings for Graphviz with the real Graphviz compiled to WebAssembly and run on wazero, no C toolchain and no system Graphviz. The changes are about trusting the blob: Graphviz and expat are built from pinned, digest-checked sources with a pinned wasi-sdk and binaryen, reproducibly, so two builders produce the same bytes and CI proves it on every change; the bridge's failures are typed errors a caller can match; the dot binary of upstream's nested module is replaced by dot below.

Not forks: tools we reimplemented from scratch because the upstream one could not be consumed as pinned, versioned tooling. Our own code, our own licence, credit to the project whose interface they follow.

• dot — a Graphviz dot command as one static Go binary, on go-graphviz's WebAssembly build of Graphviz: -K, -T (dot, svg, png, jpg) and -o, file or standard input, file or standard output. go-graphviz's own dot lives in a nested module that has never been tagged and pins the library five releases back, so a tool directive on it cannot move; this one is tagged and tracks the library like any other dependency.

• godolint — a Dockerfile linter in Go that follows hadolint, rule for rule: the rule metadata and the test cases are generated from hadolint's Haskell sources at a pinned release, so a hadolint bump shows exactly which rules moved, and the pragmas, the shell analysis of RUN lines and the optional shellcheck integration are ported to match. One static binary and an SDK, where hadolint needs a Haskell toolchain to build and a container to run.

Upstream code, our packaging: nothing rewritten, nothing forked, only built or imported at an audited pin and published so the fleet can pin it by checksum and attestation.

• curl — one curl with dependable TLS 1.3 for every platform, from curl-for-win, the curl project's own reproducible-build system: the Windows packages are the official builds, imported and sigstore-verified against a vendored key; linux (static musl) and macOS (arm64) are built by curl-for-win's scripts at the same commit pin. Exists because no single upstream channel covers all the platforms the toolchain runs on.
• openssh — OpenSSH for macOS with security keys built in, which Apple's build lacks: OpenSSH portable without OpenSSL, libfido2 and libcbor linked statically, LibreSSL's libcrypto under libfido2 only, Apple's clang, one relocatable package per release. A small patch makes the binaries find their configuration and helpers beside themselves, so the package runs from wherever aqua unpacks it; it ships a strict client configuration, the agent as a user LaunchAgent, and the server off by default, user-scoped when on.

The organisation's own, not forks: what serves and what provisions.

• website-godolint — the website for godolint at godolint.forkcloser.org: two static pages, no build step, no third-party requests, the sample Dockerfile on the landing page annotated by the pinned godolint itself.
• infra — the infrastructure behind the websites, as code: one zone per domain, one block per site; OpenTofu holds the Cloudflare Pages projects and their domains, and dnsctl, a Go program in the repository, makes the DNS and registrar accounts match zones.yaml, delegation and DNSSEC included. A pull request adds a site; the apply on main creates it.

Projects here are provided as-is, best-effort, without warranty.

• Contributing guide — upstream first, then sign-off (DCO), commit signing and the pull request flow.
• Security policy — never report a vulnerability in a public issue, and note that a flaw in forked code is usually upstream's to fix.
• Bugs and ideas go to the issue tracker of the repository they concern.

The sibling organization farcloser holds the tooling and libraries these are built with.