> And even if they come with hash checks _today_, there is no guarantee next version won't quietly remove them.
...But you could say this about literally every security measure in literally every codebase. At any point, anyone could quietly remove anything that enhances security, or quietly add anything that reduces security. So what's your point?
Yes, technically it's all Turing-complete, but conventions matter, a lot. And Rust, being a mature project, is very likely to follow the conventions.
"static toolchain .tar.gz" means bunch of files you download and manually extract. There may be an install.sh script, but it'll just copy files around, not download extra files. And sometimes install.sh is optional, and tools can be run directly from extraction location.
"curl | bash" means "do whatever developers think gives best experience with minimal prompts", which absolutely means download extra files, but also install system packages, update ~/.bashrc, change system settings and so on.
".run installer" mean interactive installer, Windows-style, often with actual GUI. Often goes into /opt.
"deb file" means "all installed files are managed by apt, and can be examined. /etc conflicts are managed by apt. pre/post install scripts are minimal, and there is a clean uninstall command you can trust to actually work".
You can have deviations - like curl|bash used to pull a deb file or something - but no one likes surprises, so people usually stick to their lanes. If you have .deb files, it might get an officially-specified dependency, more files and maybe a post-inst script, but it won't suddenly start rewriting your .bashrc. Having static toolchain suddenly download files will make many people unhappy, so it likely won't happen either.
(One exception to this rule is enterprise software being packaged into .deb files - Google Chrome surprised everyone when they started to install apt source in their postinst, but many enterprise softwares (cough nomachine cough) do much worse things, like only using apt to unpack their installer file, an dthen running their proprietary install script in postinst)
...But you could say this about literally every security measure in literally every codebase. At any point, anyone could quietly remove anything that enhances security, or quietly add anything that reduces security. So what's your point?