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/mise
files 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:
- the contents of the that the simlink points to
- 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
?