Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

trusted_config_paths has no effect #3229

Open
gdlx opened this issue Nov 27, 2024 · 8 comments
Open

trusted_config_paths has no effect #3229

gdlx opened this issue Nov 27, 2024 · 8 comments
Labels

Comments

@gdlx
Copy link

gdlx commented Nov 27, 2024

Describe the bug
Since upgrading Mise last week, I have issues with config trust.
I have a Mise config file in a Python project:

# ~/projects/myproject > cat .mise.toml
[tools]
kustomize = 'prefix:5.3'

Config file isn't trusted by default since v2024.11.24 (it's trusted by default when downgrading to v2024.11.23), while global files are still trusted:

# ~/projects/myproject > mise trust --show
~/.config/mise/config.toml: trusted
~/.mise.toml: trusted
~/projects/myproject/.mise.toml: untrusted

The consequence is my kustomize install isn't considered current anymore.
Even if it is installed globally, I could need a different version in my project, so my code checks it's installed with --current:

# ~/projects/myproject > mise list kustomize --installed --current
Tool  Version  Config Source Requested

# ~/projects/myproject > mise list kustomize --installed
Tool       Version  Config Source Requested
kustomize  5.3.0

Everything works fine when trusting the file directly:

# ~/projects/myproject > mise trust
mise trusted /home/gdlx/projects/myproject/.mise.toml

# ~/projects/myproject > mise trust --show
~/.config/mise/config.toml: trusted
~/.mise.toml: trusted
~/projects/myproject/.mise.toml: trusted

# ~/projects/myproject > mise list kustomize --installed --current
Tool       Version  Config Source                   Requested
kustomize  5.3.0    ~/projects/myproject/.mise.toml prefix:5.3

But I don't want to do this because I have multiple projects with the same setup and I don't want to trust every config file. I'd prefer doing it with the MISE_TRUSTED_CONFIG_PATHS, globally for all projects on the ~/projects directory or even in each project dir by setting the variable on execution.

My problem is thas the setting seems to be completely ignored.

To Reproduce

# ~/projects/myproject > mise trust --untrust
mise untrusted /home/gdlx/projects/myproject/.mise.toml
mise ERROR error parsing config file: ~/projects/myproject/.mise.toml
mise ERROR Config file ~/projects/myproject/.mise.toml is not trusted.
Trust it with `mise trust`.
mise ERROR Run with --verbose or MISE_VERBOSE=1 for more information

# ~/projects/myproject > mise trust --show
~/.config/mise/config.toml: trusted
~/.mise.toml: trusted
~/projects/myproject/.mise.toml: untrusted

# ~/projects/myproject > export MISE_TRUSTED_CONFIG_PATHS=~/projects

# ~/projects/myproject > mise doctor |grep trust
  trusted_config_paths = ["~/projects"]

# ~/projects/myproject > mise trust --show
~/.config/mise/config.toml: trusted
~/.mise.toml: trusted
~/projects/myproject/.mise.toml: untrusted

# ~/projects/myproject > mise list kustomize --installed --current
Tool  Version  Config Source Requested

trusted_config_paths just seems to be ignored.

I tried with setting MISE_TRUSTED_CONFIG_PATHS to multiple paths and syntaxes with the same result:

  • ~/projects/
  • ~/projects/myproject
  • ~/projects/myproject/
  • ~/projects/myproject/.mise.toml
  • /home/gdlx/projects/myproject
  • /home/gdlx/projects/myproject/
  • /home/gdlx/projects/myproject/.mise.toml

Expected behavior
Unless I misunderstood something, the config file should just be trusted:

# ~/projects/myproject > export MISE_TRUSTED_CONFIG_PATHS=~/projects

# ~/projects/myproject > mise doctor |grep trust
  trusted_config_paths = ["~/projects"]

# ~/projects/myproject > mise trust --show
~/.config/mise/config.toml: trusted
~/.mise.toml: trusted
~/projects/myproject/.mise.toml: trusted

# ~/projects/myproject > mise list kustomize --installed --current
Tool       Version  Config Source                   Requested
kustomize  5.3.0    ~/projects/myproject/.mise.toml prefix:5.3

mise doctor output

With MISE_TRUSTED_CONFIG_PATHS unset (I've shown above that trusted_config_paths is correctly set when I set the variable):

❯ mise doctor
version: 2024.11.30 linux-x64 (2024-11-26)
activated: yes
shims_on_path: no

build_info:
  Target: x86_64-unknown-linux-gnu
  Features: DEFAULT, NATIVE_TLS
  Built: Tue, 26 Nov 2024 20:28:19 +0000
  Rust Version: rustc 1.82.0 (f6e511eec 2024-10-15) (Homebrew)
  Profile: release

shell:
  /usr/bin/zsh
  zsh 5.9 (x86_64-ubuntu-linux-gnu)

dirs:
  cache: ~/.cache/mise
  config: ~/.config/mise
  data: ~/.local/share/mise
  shims: ~/.local/share/mise/shims
  state: ~/.local/state/mise

config_files:
  ~/.config/mise/config.toml
  ~/.mise.toml

backends:
  aqua
  asdf
  cargo
  core
  gem
  go
  npm
  pipx
  spm
  ubi
  vfox

plugins:
  cilium-cli  https://github.com/carnei-ro/asdf-cilium-cli.git#89c7711
  flux2       https://github.com/tablexi/asdf-flux2.git#771755e
  helm        https://github.com/Antiarchitect/asdf-helm.git#085651c
  kubectl     https://github.com/asdf-community/asdf-kubectl.git#2fb3b57
  kustomize   https://github.com/Banno/asdf-kustomize.git#8e929af
  pulumi      https://github.com/canha/asdf-pulumi.git#99d675b
  usage       https://github.com/jdx/mise-usage.git#fe3888a

toolset:
  aqua:kubernetes-sigs/[email protected]
  asdf:[email protected]
  asdf:[email protected]
  asdf:[email protected]
  asdf:[email protected]
  asdf:[email protected]

env_vars:
  MISE_SHELL=zsh

settings:
  activate_aggressive = false
  all_compile = false
  always_keep_download = false
  always_keep_install = false
  asdf_compat = false
  cache_prune_age = "30d"
  ci = false
  color = true
  debug = false
  disable_backends = []
  disable_default_registry = false
  disable_hints = ["outdated_bump"]
  disable_tools = []
  exec_auto_install = true
  experimental = false
  fetch_remote_versions_cache = "1h"
  fetch_remote_versions_timeout = "10s"
  go_default_packages_file = "~/.default-go-packages"
  go_download_mirror = "https://dl.google.com/go"
  go_repo = "https://github.com/golang/go"
  go_set_gopath = false
  go_set_goroot = true
  go_skip_checksum = false
  http_timeout = "30s"
  ignored_config_paths = []
  jobs = 4
  legacy_version_file = true
  legacy_version_file_disable_tools = []
  libgit2 = true
  lockfile = true
  log_level = "info"
  not_found_auto_install = true
  paranoid = false
  pin = false
  plugin_autoupdate_last_check_duration = "7d"
  quiet = false
  raw = false
  task_run_auto_install = true
  task_skip = []
  trace = false
  trusted_config_paths = []
  unix_default_file_shell_args = ["sh"]
  unix_default_inline_shell_args = [
      "sh",
      "-c",
  ]
  use_file_shell_for_executable_tasks = false
  use_versions_host = true
  verbose = false
  windows_default_file_shell_args = [
      "cmd",
      "/c",
  ]
  windows_default_inline_shell_args = [
      "cmd",
      "/c",
  ]
  windows_executable_extensions = [
      "exe",
      "bat",
      "cmd",
      "com",
      "ps1",
      "vbs",
  ]
  yes = false

  [aqua]
  cosign = true
  slsa = true

  [cargo]
  binstall = true

  [node]

  [npm]
  bun = false

  [pipx]
  uvx = false

  [python]
  default_packages_file = "~/.default-python-packages"
  pyenv_repo = "https://github.com/pyenv/pyenv.git"
  venv_auto_create = false
  venv_stdlib = false

  [ruby]
  default_packages_file = "~/.default-gems"
  ruby_build_repo = "https://github.com/rbenv/ruby-build.git"
  ruby_install = false
  ruby_install_repo = "https://github.com/postmodern/ruby-install.git"

  [status]
  missing_tools = "if_other_versions_installed"
  show_env = false
  show_tools = false

No problems found

Additional context

I've seen nothing relevant with --debug or --trace.

@gdlx gdlx added the bug label Nov 27, 2024
@jdx
Copy link
Owner

jdx commented Nov 27, 2024

¯\_(ツ)_/¯ it's working for me if I set MISE_TRUSTED_CONFIG_PATHS=~ and every other thing I can think of. Is there a symlink in the paths maybe that's screwing things up?

here's the code which might give you an idea of what it is that is going awry:

pub fn is_trusted(path: &Path) -> bool {
let canonicalized_path = match path.canonicalize() {
Ok(p) => p,
Err(err) => {
debug!("trust canonicalize: {err}");
return false;
}
};
if is_ignored(canonicalized_path.as_path()) {
return false;
}
if IS_TRUSTED
.lock()
.unwrap()
.contains(canonicalized_path.as_path())
{
return true;
}
if config::is_global_config(path) {
add_trusted(canonicalized_path.to_path_buf());
return true;
}
let settings = Settings::get();
for p in settings.trusted_config_paths() {
if canonicalized_path.starts_with(p) {
add_trusted(canonicalized_path.to_path_buf());
return true;
}
}
if settings.paranoid {
let trusted = trust_file_hash(path).unwrap_or_else(|e| {
warn!("trust_file_hash: {e}");
false
});
if !trusted {
return false;
}
} else if cfg!(test) || ci_info::is_ci() {
// in tests/CI we trust everything
return true;
} else if !trust_path(path).exists() {
// the file isn't trusted, and we're not on a CI system where we generally assume we can
// trust config files
return false;
}
add_trusted(canonicalized_path.to_path_buf());
true
}

@gdlx
Copy link
Author

gdlx commented Nov 27, 2024

Ok, that's weird.
I tried with MISE_TRUSTED_CONFIG_PATHS=~ with no more success (and it wouldn't be really safe).
I have no symlink in the path, but maybe using WSL could have some impact ? (I don't think so)

@jdx
Copy link
Owner

jdx commented Nov 30, 2024

are you actually setting it as an env var?

@gdlx
Copy link
Author

gdlx commented Dec 3, 2024

Sure, as shown in my To Reproduce block:

# ~/projects/myproject > export MISE_TRUSTED_CONFIG_PATHS=~/projects

@kattouf
Copy link
Contributor

kattouf commented Dec 11, 2024

Hello @gdlx,

I had a similar experience to what you described and spent a couple of hours trying to figure out what was going on.

Eventually, I decided to pull the mise repository and debug it. I discovered that my configuration was untrusted because it was “ignored.” Here’s the relevant code snippet:

pub fn is_trusted(path: &Path) -> bool {
    let canonicalized_path = match path.canonicalize() {
        Ok(p) => p,
        Err(err) => {
            debug!("trust canonicalize: {err}");
            return false;
        }
    };
    if is_ignored(canonicalized_path.as_path()) {
        return false; // my code returns here
    }

I believe this happened when mise prompted me with:
mise config files in {some path} are not trusted. Trust them?
At that time, I had answered No.

To fix this, you can remove your target configuration from the “ignore list” by temporarily trusting it:

mise trust --all

Then, you can “untrust” the configuration by running:

mise trust --untrust

At this point, the configuration will no longer be in either the “ignore” or “trust” lists, allowing you to test the behavior from scratch:

export MISE_TRUSTED_CONFIG_PATHS=~/projects
mise trust --show

(or just visit MISE_STATE_DIR and manage all it manually)

image

I hope this helps! Let me know if you need further clarification.

@jdx
Copy link
Owner

jdx commented Dec 11, 2024

note that this logic changed significantly in the last release, previously it tracked files but now it tracks the directory so you don't need to trust every .config/conf.d/*.toml config individually

I did try to make it backwards-compatible where previously tracked individual files will still be trusted

@jdx
Copy link
Owner

jdx commented Dec 11, 2024

I believe this happened when mise prompted me with:
mise config files in {some path} are not trusted. Trust them?
At that time, I had answered No.

fwiw this is the intended behavior, otherwise we would prompt all the time and it would never go away

@kattouf
Copy link
Contributor

kattouf commented Dec 11, 2024

I agree with you, I just did it (implicitly added to permanent ignore by clicking "No" in the "do you trust" question) and forgot after that, so at the moment I was confused

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants