jdx / mise

dev tools, env vars, task runner

Home Page:https://mise.jdx.dev

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

mise trust follows symbolic links making it difficult to manage

AntonFriberg opened this issue · comments

Describe the bug
It is common to manage dotfiles using symbolic links to version controlled repos or by utilizing more advanced tools such as Nix with Home-Manager. In both of these cases the ~.config/misefiles will be populated by symbolic links to configuration that is stored elsewhere instead of actual files.

To Reproduce

❯ mkdir test
❯ mkdir symlinks
❯ touch symlinks/.mise.toml
❯ ln -s symlinks/.mise.toml test/.mise.toml
❯ mise --verbose trust test/.mise.toml
[DEBUG] ARGS: mise --verbose trust test/test/.mise.toml
Error: 
   0: No such file or directory (os error 2)

Location:
   src/config/config_file/mod.rs:250

Version:
   2024.1.24 linux-x64 (de37513 2024-01-20)

Suggestion: Run with --verbose or MISE_VERBOSE=1 for more information.

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.

Expected behavior
I would expect that I should trust the symbolic link instead of needing to trust the source of the link.

mise doctor output

mise version:
  2024.1.20 linux-x64 (2024-01-16)

build:
  Target: x86_64-unknown-linux-gnu
  Features: DEFAULT, NATIVE_TLS
  Built: Tue, 16 Jan 2024 19:21:33 +0000
  Rust Version: rustc 1.75.0 (82e1608df 2023-12-21) (built from a source tarball)
  Profile: release

shell:
  /home/antonfr/.nix-profile/bin/fish
  fish, version 3.7.0

mise data directory:
  /home/antonfr/.local/share/mise

mise environment variables:
  MISE_SHELL=fish
  MISE_TRUSTED_CONFIG_PATHS=~/.config/mise

settings:
  {
    "activate_aggressive": false,
    "all_compile": false,
    "always_keep_download": false,
    "always_keep_install": false,
    "asdf_compat": false,
    "cargo_binstall": true,
    "color": true,
    "disable_default_shorthands": false,
    "disable_tools": [],
    "experimental": true,
    "jobs": 4,
    "legacy_version_file": true,
    "legacy_version_file_disable_tools": [],
    "node_compile": false,
    "not_found_auto_install": true,
    "paranoid": false,
    "plugin_autoupdate_last_check_duration": "7d",
    "python_compile": false,
    "python_default_packages_file": "/home/antonfr/.default-python-packages",
    "python_patch_url": null,
    "python_precompiled_os": null,
    "python_patches_directory": null,
    "python_precompiled_arch": null,
    "python_pyenv_repo": "https://github.com/pyenv/pyenv.git",
    "python_venv_auto_create": false,
    "raw": false,
    "shorthands_file": null,
    "task_output": null,
    "trusted_config_paths": [
      "~/.config/mise"
    ],
    "quiet": false,
    "verbose": false,
    "yes": false,
    "ci": false,
    "cd": null,
    "debug": false,
    "env_file": null,
    "trace": false,
    "log_level": "info"
  }

config files:
  ~/.config/mise/config.toml

plugins:
  bun      (core)
  deno     (core)
  erlang   (core)
  go       (core)
  java     (core)
  node     (core)
  poetry   https://github.com/mise-plugins/mise-poetry#82d11e3
  python   (core)
  ruby     (core)

toolset:
  python@3.11, poetry@1.7.1

Additional context
In my case it is very difficult to trust the source of the symbolic link since it is a generate path from Nix that changes each time the configuration of mise changes.

So instead of simply trusting ~/.config/mise/config.toml I need to trust /nix/store/3d7m3pfiv48hl1lp70b3pnyhziwbyvrh-mise-config

You can probably see the issue by just seeing the output of manual trust of the file. I would really like to have global config with trusted directories instead of having to manually run mise trust every time I change the source of the Nix configuration.

❯ mise trust .config/mise/config.toml 
mise trusted /nix/store/3d7m3pfiv48hl1lp70b3pnyhziwbyvrh-mise-config

With symlinks, wouldn't the paranoid thing be to hash both:

  1. the contents of the that the simlink points to
  2. the file pointed at by the symlink

Then, when changes are made to the underlying file, only one file would need to be re-hashed.

Perhaps --trust --follow?