Skip to content

Makefile: Track Go tool versions via separate Go modules

Patrick Steinhardt requested to merge pks-makefile-per-tool-mods into master

Right now we track versions of our Go tooling directly in our Makefile. While this is simple, it has several drawbacks:

- We're susceptible to supply-chain attacks in case an adversary
  manages to replace the code used to build any of our tools.

- We cannot use proper dependencies in our Makefile, which adds the
  need for `*.version` files.

- It is hard to build the tools outside of our Makefile as we don't
  have a way to properly pull in the correct version.

- Upgrading our tooling requires us to manually hunt down new
  releases for all of our tools.

We can fix these issues by following the approach that is efficially recommended by the Go project 1: every tool has its own Go module in tools/ with a "tool.go" file that imports the tool of interest. Like this we can use Go's normal tooling to keep track of versions:

- We record hashes of the tool's sources as well as all of its
  dependencies, making supply-chain attacks almost impossible.

- We can now provide proper dependencies in our Makefile: every tool
  depends on "tool.go", "go.mod" and "go.sum". If any of them
  changes we need to rebuild.

- The tools can be installed in the correct version simply by using
  `go install` with the correct `go.mod` file.

- Upgrading tools is as simple as running `go get -u`, so no more
  manual hunting for new versions.

While these benefits are great on their own already, we can go even further with this refactoring: now that each tool has its own go.mod file we can adapt the Renovate bot to pick up these files. This means that we don't have to remember upgrading at all anymore, but instead the bot will automatically upgrade them for us.

While at it this MR also updates some tools to demonstrate how updates will look like going forward.

Merge request reports