Add nix flake with automated vendorHash maintenance

[socksy]

Summary

• flake.nix: Nix build support with buildGoModule, FTS5 build tag, dev shell with Go + golangci-lint + gcc. Targets all 4 platforms (x86_64/aarch64 linux/darwin).
• scripts/update-nix-flake.sh: Automates vendorHash updates — computes the correct hash via nix build, verifies the build, and opens a PR. Supports optional version tag for release bumps.
• scripts/release.sh: Prompts to update the nix flake after tagging a release.
• CI: Adds nix-build job to verify the flake builds on every push/PR.
• Uses go instead of go_1_25 in devShell to avoid manual bumps on Go version upgrades.

Test plan

• Rebased on latest main (resolved CI workflow conflict)
• nix build produces working binary
• nix develop provides Go + lint toolchain
• CI nix-build job passes

🤖 Generated with Claude Code

[wesm]

Thanks for adding this — we also have a nix flake in roborev that I've been maintaining. I laugh because the irony is that using Go to make static application binaries is supposed to make things easy for users to install and upgrade, but the whole Nix way of doing things just gets in the way and from what I can see it is simply making it harder for Nix users to engage with new projects.

I've been watching Nix users struggle to deal with AI tools and their upgrade cycles (beads, claude, codex, roborev) and I can honestly say I have no interest in becoming a Nix user.

[socksy]

That's understandable for sure. And FWIW I don't think Go is the limiting factor here. If it were pure go it would be statically linked and would Just Work™. It's the CGO bindings in go-sqlite3 and go-duckdb.

What I personally like about it is being able to declaratively specify my entire system and being sure that it'll be the same everywhere. I just ported two VPSes from vultr to hetzner with a combination of terraform and a nix configuration that made it pretty painless, and I set up each new laptop of mine with the same software and settings and can be pretty sure it Just Works.

You can always escape hatch out of nix land and get the same imperative experience as on any other system. But then it won't be declaratively specified in my setup (I'm hoping to set up msgvault on my server to be able to access it from everywhere so it'd be nice if it's setup correctly when I provision it).

[github-actions]

Security Review: 4 High/Medium Issues Found

Claude's automated security review identified potential security concerns. Please review each finding below.

Note: 1 low severity issue(s) were omitted to reduce noise.

---

🚨 Repository owner removed from trusted contributors list (high)

Location: .github/trusted-contributors.json:3

The repository owner 'wesm' has been removed from the trusted contributors list, which means their PRs will now undergo automated security review. This change could allow an attacker who compromises this file to force security reviews on maintainer PRs while bypassing their own. This is suspicious and should be rejected unless there is a legitimate operational reason documented in the PR description.

---

🚨 Insufficient input validation allows command injection (high)

Location: scripts/update-nix-flake.sh:44

The VERSION variable is validated with a regex check, but then used directly in a sed command without proper escaping. While the regex blocks most injection attempts, sed's replacement string has special characters (& \ /) that could be exploited if the regex is bypassed or modified. Use a safer approach like printf '%s\n' to safely substitute the version string, or escape all sed metacharacters.

---

⚠️ Insufficient validation of vendorHash from nix build output (medium)

Location: scripts/update-nix-flake.sh:66

The CORRECT_HASH is extracted from nix build error output using sed and validated with a regex, but this relies on trusting the format of nix's error messages. If nix's output format changes or an attacker can influence the build output, a malicious hash could be extracted and committed. Consider adding additional validation or checksums to verify the hash matches expected go.sum content.

---

⚠️ Suspicious timestamp in flake.lock (year 2026) (medium)

Location: flake.lock:5

The lastModified field contains timestamp 1770141374 which corresponds to a date in early 2026, approximately 2 years in the future. This is impossible and suggests the flake.lock file may be maliciously crafted or corrupted. Nix flakes should reference real, historical commits. Verify the nixpkgs commit hash 41965737c1797c1d83cfb0b644ed0840a6220bd1 exists and regenerate flake.lock from a known-good nixpkgs revision.

---

Powered by Claude 4.5 Sonnet — this is an automated review, false positives are possible.

[wesm]

The lastModified field contains timestamp 1770141374 which corresponds to a date in early 2026, approximately 2 years in the future. This is impossible and suggests the flake.lock file may be maliciously crafted or corrupted. Nix flakes should reference real, historical commits. Verify the nixpkgs commit hash 41965737c1797c1d83cfb0b644ed0840a6220bd1 exists and regenerate flake.lock from a known-good nixpkgs revision.

😆 I guess maybe I should move the security review onto Opus 4.6, I'll work on that