blog @main - refs - log -
My nonexistent blog
tree log patch
feat: gomodsri Signed-off-by: jolheiser <john.olheiser@gmail.com>
-----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEgqEQpE3xoo1QwJO/uFOtpdp7v3oFAmXuaVAACgkQuFOtpdp7 v3raSw/9FJiGe+9Ji43bxDp+gETF5cjDQsk/plUqqJbs8G+B8e2oyTv37a2AnT8j BCK5YSHZneKkLIpYCx23jlaVScKWhpZ2K8pISWinxMqNNllDfiE0j7575ErMpmAA 3z4l6B8jp5wQWxa176ldKpBoGu9i3hEzjRPwwOv2DHqMUKJ6jPTBsKupXcueVnDH /tJWai0X9jfFbllACnh/7l1NEBqiJQQY7tLoEvfSrtQG0sX2bCoRxbMNbXyFVa7n JE8EVsYP59GW37CH97G2dwkWUkSKyak/cW0ymEThGJc65YXq00RhYbIlBZoU0v4E aFcdLry26EawN0SH8mnWiC2MTfUFWs16tmMwMZ5Tkgw9WR2Gf2Q1Sus7NvJ9Cqja f11i7s21Jj/aBYh0E0kbWPZxblDdsRY8tFVPSh/CyKwG3lqEz1OIKiZ+a38PZDKd xgFBzTjyTMFil08QJgVi0c233VtmhLEWLTUU7OHKF0jkJuWVaMeoPyaytyc5Gfa9 XzwRMN7vmJhirWOQQzlSdpHLEO7qRkqiSFnHcGuVJzKhFOybWCWORnvOxjCsSpjR MTx3ir+31bkLeUNGIAFJwytSp2Y3x7xuhSD9u4tzvhg+dicuZkVsJ/SSiR2nVSZB 0PZWiJQdiy4vQk+qyYLBoK3G6570KTXAyijzWPC2eGr1ofvKUYE= =K8D9 -----END PGP SIGNATURE-----
jolheiser <john.olheiser@gmail.com>
2 months ago
1 changed files, 50 additions(+), 0 deletions(-)
I articles/gomodsri.md
diff --git a/articles/gomodsri.md b/articles/gomodsri.md
new file mode 100644
index 0000000000000000000000000000000000000000..0db9c867ae5e27317291da7db2cc437bcb3328c7
--- /dev/null
+++ b/articles/gomodsri.md
@@ -0,0 +1,50 @@
+title = "gomodsri"
+summary = "Using taislcale/nardump to generate a go module SRI without building first"
+date = 2024-03-10
+category = "Nix"
+### The problem
+When building a Go module with `nix`, generally one uses `buildGoModule`. One thing this shares with other builders in the nix ecosystem is `vendorHash` (or similar name).
+Although there _have_ been various workarounds, there's usually no getting around some variation of building, noting the "expected" new hash, and replacing the hash with the correct one before building works for real.
+### The solution
+Now, admittedly I am borrowing this idea from [tailscale](https://tailscale.com). I simply wrapped it in a (nu)shell command for easier usage more generically.
+The original idea combines the command [nardump](https://github.com/tailscale/tailscale/tree/ad33e47270509345469af795aed65177df88904e/cmd/nardump) with the [vendoring](https://pkg.go.dev/cmd/go#hdr-Make_vendored_copy_of_dependencies) ability of Go modules to predict the `vendorHash`. Put together, it can look something like the following:
+- [update-flake.sh](https://github.com/tailscale/tailscale/blob/ad33e47270509345469af795aed65177df88904e/update-flake.sh#L9-L10)
+# [...] setting up a tempdir
+go mod vendor -o "$OUT"
+go run tailscale.com/cmd/nardump --sri "$OUT" >go.mod.sri
+# [...] cleanup
+- [flake.nix](https://github.com/tailscale/tailscale/blob/ad33e47270509345469af795aed65177df88904e/flake.nix#L69) 
+pkgs.buildGoModule {
+  # ...
+  vendorHash = pkgs.lib.fileContents ./go.mod.sri;
+  # ...
+I've modified it locally to use across other projects as the following nushell function:
+def gomodsri [] {
+  let tmp = (mktemp -d)
+  go mod vendor -o $tmp
+  let sri = (go run tailscale.com/cmd/nardump@latest --sri $tmp)
+  $sri | save -f go.mod.sri
+  rm -rf $tmp
+  echo 'nixpkgs.lib.fileContents ./go.mod.sri'
+<small>Yes, the echo at the end is because I always forget the invocation otherwise...</small>