[renovate]

This PR contains the following updates:

Package	Type	Update	Change	Pending
jdx/mise-action	action	patch	v5.2.2 → v5.2.4	v5.2.6 (+1)
jdx/packslip	action	patch	v1.11.0 → v1.11.2	v1.11.3

---

Release Notes

jdx/mise-action

v5.2.4: : Reuse cached signed checksums when restoring mise

Compare Source

Jobs that restore mise from the cache no longer have to download its signed checksums from GitHub on every run, so a network failure at that step no longer fails a job that otherwise restored correctly.

Fixed

• Restoring a cached mise no longer needs a network download of the checksums. The action checks the cached mise binary against the signed SHASUMS256.txt and its .minisig. Before this release it downloaded both files from GitHub on every run, even when the cache restored correctly. When that download failed, for example after repeated curl errors, the job failed. Now, once the signature checks out, the action saves both files as SHASUMS256-<version>.txt and .minisig in <mise_dir>/bin, which is part of the mise cache. On later runs it reads them from the restored cache and checks the minisign signature again before using them. If the files are missing, corrupt or tampered with, the action downloads them as it did before. There are no new inputs. (#​708 by @​jdx)
  • Caches saved by earlier versions don't contain these files. The main cache is only saved on a cache miss, so runs keep downloading the checksums until the cache is saved again or its key changes.

Full Changelog: jdx/mise-action@v5.2.3...v5.2.4

v5.2.3: : Faster cache key computation in large workspaces

Compare Source

The cache key no longer comes from searching the whole workspace for mise config files. In repos that already contain node_modules or vendor/bundle, this removes a delay of several minutes in "Restoring mise cache".

Fixed

• "Restoring mise cache" no longer takes minutes after installing dependencies. To build the cache key, the action used to match about 25 **/… glob patterns. That meant it walked every subdirectory of the workspace, including node_modules and vendor/bundle, before checking the cache at all. When the action ran after a step like pnpm install or ruby/setup-ruby with bundler-cache: true, this could take 3–7 minutes. The action now looks for mise config files the same way mise does: only in the working directory and each parent directory up to the workspace root. It checks for mise.toml, .mise.toml, .config/mise/…, conf.d fragments, .tool-versions, and their local, env-specific and .lock variants. The step also logs Hashed mise config files in N.Ns. (#​703 by @​jdx and @​corsicanec82)
  • If you set a custom cache_key that doesn't use {{file_hash}} or {{default}}, the action no longer hashes config files at all.
  • Config files in subdirectories, such as monorepo sub-projects, no longer affect the cache key. mise only loads them with --monorepo.
  • Cache keys change, so the first run after you upgrade will miss the cache.

New Contributors

• @​corsicanec82 made their first contribution in 91e7f82 (#​703)

Full Changelog: jdx/mise-action@v5.2.2...v5.2.3

jdx/packslip

v1.11.2: : Detect replaced public keys that reuse the old key ID

Compare Source

packslip install now asks for approval when a key-signed project switches to a different public key that keeps the old key ID. This release also puts limits on how much work a hostile bundle can force the verifiers to do, and fixes two argument-handling gaps in the GitHub Actions. The format and specification are unchanged.

Fixed

• packslip install treats a replacement public key with the same key ID as a trust change. A minisign key ID is eight bytes of text in the public key file. It is not derived from the key itself. Before this release, the continuity check compared only that ID, so a different key with the old ID was accepted through --pubkey or pins.d without approval, and install then remembered the new key. Each key-signed record now also stores a fingerprint of the whole public key. A changed key is reported as public key changed from <old> to <new> and needs --accept-trust-change=<id> like any other trust change. That means one approval for the release list and one for the release, as the trust guide already described. Records for keyless projects are unchanged. (#​305, @​jdx)
  • Existing histories: On the first install after you upgrade, records without a fingerprint are filled in from the public key the history already remembers, so that install catches a same-ID replacement. If a history has a key-signed record but no remembered key, it adopts the first key it sees, as before. If an earlier version already accepted a same-ID replacement for the release list, the old key is lost and cannot be recovered. In that case the release check uses the replacement key as its baseline and does not catch the swap. Older packslip versions ignore the new field.
  • Pending approvals: If a key change was waiting for approval when you upgraded, its approval ID changes. Approve it again with the new ID.
• Verifiers reject oversized or malformed bundle data before doing expensive work. (#​304, @​jdx)
  • The standalone verifier (verifier/packslip-verify.mjs) rejects inclusion proofs whose logIndex or treeSize is not a non-negative int64. Before, a very long digit string took time that grew quadratically with its length. It also rejects checkpoints with more than 16 signatures.
  • The JavaScript package rejects bundles with more than 8 transparency-log entries or RFC 3161 timestamps before passing them to sigstore, which compares them pairwise before authenticating any. A normal release bundle has one entry.
  • In the Go library, Statement.Validate now finds artifacts with the same selectors in linear time. Before, the check was quadratic in the number of artifacts.
• GitHub Actions handle unusual artifact names and tags safely. (#​304, @​jdx)
  • The jdx/packslip action now passes -- before the artifact list. An artifact whose file name is exactly a packslip option, such as --no-pin-workflow, was previously read as that option. It is now treated as an artifact, and packslip create refuses it because it has no format.
  • The releases action now fails on a tag directory containing =. --release URL=PATH splits at the first =, so a tag like that moved part of the URL into the path.

Full Changelog: jdx/packslip@v1.11.1...v1.11.2

v1.11.1: : Go module helpers for build targets, monorepo bundle names, and signer checks

Compare Source

The Go module (github.com/jdx/packslip/go) gets three helpers for Go release tools that publish packslips. Until now those tools had to reimplement packslip rules in their own code. The statement format stays release/v1, and nothing changes for existing callers.

Added

• GoTarget holds one build's Go settings: GOARCH, GOARM, GOAMD64, GO386, GOARM64, GOMIPS, GOPPC64, GORISCV64, and FloatABI. Arch() returns the packslip architecture and Variant() returns the variant, using whichever setting applies to GOARCH. For arm, FloatABI takes Go's softfloat or hardfloat, or a Rust or Zig target ABI such as gnueabi or gnueabihf, and overrides any float option in GOARM. (#​297, @​jdx)

  target := packslip.GoTarget{GOARCH: "amd64", GOAMD64: "v3"}
  artifact.Arch = target.Arch()       // "x86_64"
  artifact.Variant = target.Variant() // "v3"

• BundleName(project, repo) returns the bundle asset name the spec assigns when several tools share one repository's release. For example, github.com/owner/repo/mytool becomes packslip.mytool.sigstore.json, and any / in a deeper subpath becomes -. The repository itself, or a project outside it, gets packslip.sigstore.json. The repository is matched without regard to case. (#​297, @​jdx)

• CheckProjectSigner(project, token) checks, before anything is signed or written to the transparency log, that an OIDC token can sign for the project. Call it after AmbientIDToken. A github.com project must belong to the token's repository claim, and a gitlab.com project must equal its project_path claim. A reusable workflow from another repository passes. A domain project always passes, because its vendor pins the signer. (#​297, @​jdx)

  Limitations:

  • The check only reads the token. It does not verify it.
  • A github.com or gitlab.com project fails if the token comes from a different issuer.
  • A project that still uses a repository's old name after a rename fails this check, even though verification would accept it.
  • SignKeyless does not call CheckProjectSigner, so existing signing code behaves as before.

The Publish from Go guide and the module README now cover all three helpers.

Full Changelog: jdx/packslip@v1.11.0...v1.11.1

---

Configuration

📅 Schedule: (in timezone America/Chicago)

• Branch creation
  • Only on Thursday (* * * * 4)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[greptile-apps]

This PR does not match any of the 1 configured review trigger rule.

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Central YAML (base), Organization UI (inherited)
• Review profile: CHILL
• Plan: Advanced
• Run ID: 3607c103-3e7b-474f-b000-29ac55f913d9

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn