Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Changing a lockfile `url` but not its `sha256` silently serves the old binary from the repository cache

Open
  • Is something wrong?
#131 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
66/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Domain
build-system

Research direction

Start with the three download calls in multitool/private/multitool.bzl (the issue links to lines 83, 98, and 132), then compare their cache handling with http_archive or http_file and @bazel_tools//tools/build_defs/repo:cache.bzl. The issue also calls for an environ addition to tool_repo; reproduce using the lockfile URL/SHA mismatch. Done when a cached run fails with the checksum error, as an uncached run does.

Written by the indexing model from the issue text.

Description

tool_repo passes sha256 to rctx.download / rctx.download_and_extract but no canonical_id (multitool.bzl L83, L98, L132). Bazel's repository cache is keyed by sha256. So if a lockfile entry's url is bumped and its sha256 is left at the old value, any machine that already has the old file cached gets the old binary, with no error. A machine without it fails with a checksum mismatch. The same commit builds differently depending on the cache.

Repro

rules_multitool 1.11.1, Bazel 9.2.0, macOS arm64. main (5ef5b45) behaves the same.

.bazelversion

9.2.0

MODULE.bazel

module(name = "multitool_repro")

bazel_dep(name = "rules_multitool", version = "1.11.1")

multitool = use_extension("@rules_multitool//multitool:extension.bzl", "multitool")
multitool.hub(lockfile = "//:multitool.lock.json")
use_repo(multitool, "multitool")

BUILD.bazel: empty

multitool.lock.json

{
  "$schema": "https://raw.githubusercontent.com/bazel-contrib/rules_multitool/main/lockfile.schema.json",
  "jq": {
    "binaries": [
      {
        "kind": "file",
        "url": "https://github.com/jqlang/jq/releases/download/jq-1.8.0/jq-macos-arm64",
        "sha256": "aaf1efbb376d6e3eaf61f63807c32c1df519f5857dfc4f581826fa2df4b715ae",
        "os": "macos",
        "cpu": "arm64"
      },
      {
        "kind": "file",
        "url": "https://github.com/jqlang/jq/releases/download/jq-1.8.0/jq-linux-amd64",
        "sha256": "8926c33326111bcd67a47a970b5a5db933ef9194ad925994934c639c76a0605c",
        "os": "linux",
        "cpu": "x86_64"
      }
    ]
  }
}

$ bazel run @multitool//tools/jq -- --version
jq-1.8.0

# bump the URLs to 1.8.1, keep the 1.8.0 sha256
$ sed -i.bak 's/jq-1\.8\.0/jq-1.8.1/g' multitool.lock.json

$ bazel run @multitool//tools/jq -- --version
jq-1.8.0

# same lockfile, nothing cached
$ bazel clean --expunge && bazel run --repository_cache= @multitool//tools/jq -- --version
ERROR: .../multitool/private/multitool.bzl:83:22: An error occurred during the fetch of repository 'rules_multitool++multitool+multitool.jq.macos_arm64':
Error in download: java.io.IOException: Error downloading [https://github.com/jqlang/jq/releases/download/jq-1.8.1/jq-macos-arm64] to .../macos_arm64_executable: Checksum was a9fe3ea2f86dfc72f6728417521ec9067b343277152b114f4e98d8cb0e263603 but wanted aaf1efbb376d6e3eaf61f63807c32c1df519f5857dfc4f581826fa2df4b715ae

When both url and sha256 are updated, both runs print jq-1.8.1.

Actual: the second run prints jq-1.8.0 and succeeds.
Expected: the second run fails with the same checksum error as the uncached run. http_file does this for the same edit.

Fix

Do what http_archive / http_file do: pass canonical_id = get_default_canonical_id(rctx, [binary["url"]]) (from @bazel_tools//tools/build_defs/repo:cache.bzl) to the three download calls, and add environ = [DEFAULT_CANONICAL_ID_ENV] to tool_repo. With that change applied to 1.11.1, the second run fails with the checksum error.

Dominant language
Starlark
Stars
26
Forks
11
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from bazel-contrib/rules_multitool

All issues in bazel-contrib/rules_multitool

Similar issues

More Build System issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.