fix(mise): require allowlisting for lock updates

[zeitlinger]

Changes

• require self-hosted administrators to allowlist mise via allowedUnsafeExecutions
• run mise trust explicitly before mise lock when refreshing mise.lock
• keep the lockfile update path scoped to existing mise.lock files only
• detect lockfile changes by reading the updated lockfile back instead of using Git status
• add/update unit coverage for the allowlisted mise trust + mise lock flow
• update docs to describe the trust model and security implications

Context

Please select one of the following:

• This closes an existing Issue, Closes: #
• This doesn't close an Issue, but I accept the risk that this PR may be closed if maintainers disagree with its opening or implementation

AI assistance disclosure

Did you use AI tools to create any part of this pull request?

• No — I did not use AI for this contribution.
• Yes — minimal assistance (e.g., IDE autocomplete, small code completions, grammar fixes).
• Yes — substantive assistance (AI-generated non-trivial portions of code, tests, or documentation).
• Yes — other (please describe):

Tooling used: OpenAI Codex / GPT-5 via the Codex CLI workflow.

Documentation

• I have updated the documentation, or
• No documentation update is required

How I've tested my work

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests, but ran on a real repository, or
• Both unit tests + ran on a real repository

The public repository: prometheus/client_java#2144

Why

Some repositories use mise.toml features that require trust, such as [env]. In those cases Renovate's mise lock refresh can fail inside the ephemeral checkout with errors like:

mise ERROR Config files in .../mise.toml are not trusted.

This PR takes the path discussed in review:

• treat mise execution as unsafe and require an explicit self-hosted allowlist
• keep the option generic as mise, not miseLock, because any mise command that reads trusted config can be unsafe
• explicitly run mise trust before mise lock, so the trust step is visible in logs and future mise trust behavior remains owned by mise

This keeps the current feature goal narrow: support lockfile refreshes for repositories that intentionally permit mise execution in their environment.

[jamietanna]

@zeitlinger can you please make sure you've followed our PR template?

Also:

This was reproducible with prometheus/client_java in PR #2144.

Is that link right?

Will have a look once that's updated

[jamietanna]

I think it'd be good to also make sure this is documented in our docs - are there any risks of enabling MISE_TRUSTED_CONFIG_PATHS?

[zeitlinger]

@zeitlinger can you please make sure you've followed our PR template?

Also:

This was reproducible with prometheus/client_java in PR #2144.

Is that link right?

Will have a look once that's updated

sorry - prometheus/client_java#2144

[zeitlinger]

Added docs for this in lib/modules/manager/mise/readme.md.

Short version on the risk side: setting MISE_TRUSTED_CONFIG_PATHS does reduce one layer of mise's trust protection, but here it's scoped to Renovate's ephemeral localDir for the mise lock subprocess only. So it trusts mise configs within the checked-out repo for that runner process, rather than globally trusting all paths or persisting trust in the runner's mise state.

I've documented that trade-off in the PR now.

[zeitlinger]

Also to cover the PR template items explicitly:

Context

• This doesn't close an existing Issue, but I accept the risk that this PR may be closed if maintainers disagree with its opening or implementation

AI assistance disclosure

• Yes — substantive assistance (AI-generated non-trivial portions of code, tests, and documentation)
• Tooling used: OpenAI Codex / GPT-5 via the Codex CLI workflow

Documentation

• I have updated the documentation

How I've tested my work

• Both unit tests + ran on a real repository
• Public repository: chore(deps): update node.js to v24.16.0 - autoclosed prometheus/client_java#2144

Sorry for not following the template in the original PR body more closely.

[secustor]

Added docs for this in lib/modules/manager/mise/readme.md.

Short version on the risk side: setting MISE_TRUSTED_CONFIG_PATHS does reduce one layer of mise's trust protection, but here it's scoped to Renovate's ephemeral localDir for the mise lock subprocess only. So it trusts mise configs within the checked-out repo for that runner process, rather than globally trusting all paths or persisting trust in the runner's mise state.

I've documented that trade-off in the PR now.

Sounds like an inside actor could use this to invoke mise scripts and use that to exfiltrate secrets.
If true, than this should be rather an Admin option IMO.

[zeitlinger]

I've now changed the implementation to avoid trusting the repo checkout at all.

New approach:

• Renovate mirrors the discovered mise config files for the relevant lockfile scope into a temp tree
• strips them down to [tools] only
• copies in the existing mise.lock
• runs mise lock against that sanitized mirror

So this no longer relies on MISE_TRUSTED_CONFIG_PATHS.

I also added an opt-in integration test using a real mise binary locally:

• lib/modules/manager/mise/artifacts.integration.spec.ts
• runs with RUN_MISE_INTEGRATION=1

Question for maintainers: would you want a full end-to-end CI test for this kind of manager artifact update (i.e. actual Renovate update flow + real mise binary + real lockfile update on a fixture repo), or would you prefer keeping that as an opt-in/local integration test for now?

[zeitlinger]

Follow-up: I ran the opt-in real-mise integration test locally and it passes now:

RUN_MISE_INTEGRATION=1 pnpm exec vitest run lib/modules/manager/mise/artifacts.integration.spec.ts

I also corrected the docs to match the current implementation. They now describe the sanitized mirrored-config flow rather than MISE_TRUSTED_CONFIG_PATHS on the repository checkout.

[github-actions]

Hi there,

You are using done comments which cause a lot of noise/notifications. Instead, please use GitHub's web interface to request another review. Please read our contributing guidelines to reduce noise.

Good luck,

The Renovate team

[jamietanna]

Also to confirm, are you replying directly (as a human) to each of the comments, or is your agent?

[viceice]

it seems the pr description needs another update, otherwise lgtm

[zeitlinger]

it seems the pr description needs another update, otherwise lgtm

done

[github-actions]

🎉 This PR is included in version 43.210.1 🎉

The release is available on:

• GitHub release
• 43.210.1

Your semantic-release bot 📦🚀

[sisp]

A post-merge question about the security implications of enabling allowedUnsafeExecutions=["mise"] on a simple self-hosted Renovate service that runs in an ephemeral container on a schedule: IIUC, only the full Renovate run is sandboxed because the container is terminated after each run, but when multiple projects are discovered within the same run, a mise config could execute arbitrary code that affects the update process of a subsequent project being updated in the same run. Is this correct? I imagine the Mend-hosted app that has additional sandboxing according to @jamietanna isolates the Renovate runs for each project in independent environments/containers. Correct? This offers stronger isolation than updating multiple projects in the same environment.

[jamietanna]

Might be worth moving to a fresh Discussion for this

But yes, that's true and that's why this is gated as an unsafe feature, as well as it being a general risk of Renovate executing commands, where the command (malicious or otherwise) could cause persistent filesystem changes that affect future repositories having Renovate run against them inside the same container

Mend-hosted Renovate doesn't isolate with containers (which may be sufficient due to your security profile and risk tolerance) but we add MicroVMs into the mix, so each case of a Renovate execution is isolated further, as well as a few other things we do for hardening

[zeitlinger]

• on Mend-hosted apps (where we have additional sandboxing in place), we'll enable this by default

@jamietanna it's not enabled yet - see prometheus/client_java#2220 for the first repo where I've tried it

[bo0tzz]

The version this is in hasn't been deployed to the hosted platform yet
nevermind, I misread