Feature Idea: asdf install to also install plugins

[PragTob]

First of all, thanks for asdf - it's a pleasure to work with! Especially when using multiple languages. Also love how it's gradually gotten better (love installing plugins by name!)

This is just an idea for a little feature improvement that I'd like to see.

Steps to reproduce

Get a repo with a .tool-versions of many different plugins. Run asdf install

$ cat .tool-versions 
rust 1.23.0
crystal 0.24.0
nodejs 9.3.0
elixir 1.6.0
haskell 8.2.2
clojure 1.8.0
golang 1.9.2
ruby 2.5.0

Expected behavior

I'd have loved that despite installing all the versions of plugins I already got it'd also install the plugins themselves (i.e. I don't have haskell installed, first install it then the specified version).

Actual behavior

On the first plugin it doesn't have installed, asdf aborts.

$ asdf install
rust 1.23.0 is already installed
# lots of stuff
No such plugin # hit haskell here

Environment

OS: Linux Mint 18.3

asdf version: 0.4.1

[Stratus3D]

I don't have much time right now but I do want to weigh in on this. I have some concerns about the security aspects of this. Here is a scenario:

1. Malicious code gets into a plugin in our plugins repo/list (quite possible, since we don't control most of them)
2. asdf user clones down a git repository for an open source project. Project contains a .tool-versions file that references the asdf plugin in the plugin repo containing malicious code.
3. User runs asdf install. Malicious code in plugin is invoked and can do anything on the users system.

Notice the user did not run any code in the software project they just cloned down. Maybe they don't actually trust the code at all. But it's not obvious to the user that the .tool-versions file is actually dictating what code is downloaded and run on their system when they run asdf install.

While this may not be very likely, it is possible and poses a very real security risk. I know that this issue just builds on the previous plugin-repository work, but I think this is probably a bad idea. If we do decide to move forward with this there must be a configuration setting added to asdf to disable this functionality entirely, so that paranoid people like me can sleep at night. I manually install all my asdf plugins so I know exactly what's installed on my system (https://github.com/Stratus3D/dotfiles/blob/master/scripts/setup.sh#L127). I do not let the plugin repository dictate what gets installed.

[Stratus3D]

And yes, we should be doing security auditing of all plugins we list in the plugin repository. I don't really have any experience with security auditing, and I don't really have the time to learn enough and then automate the process for plugins, but it needs to be done if we are going to continue to providing a list of canonical plugins to asdf users.

[PragTob]

👋
Thanks for the answer! My idea would be to at least get user confirmation during this like "This needs plugin xyz (link to repo) - shall I install it? Y/n" - I hope this would alleviate some of your concerns :)

In general I agree. Installing random stuff from the Internet is always scary :)

[Stratus3D]

@PragTob confirmation with the repo URL is a good idea. I'd be ok with that, assuming there was an option added to the .asdfrc to toggle this feature (or maybe all the plugin repo niceties).

[danhper]

I also agree with @Stratus3D that we could make this configurable.
I personally never felt that having to manually adding the plugin was particularly a burden, but if someone would like to work on this I am open to the idea.

[trs]

You could even do this behind a flag.

asdf install would run as it does now.

asdf install --add would add plugins from the repo and install.

[kvokka]

Looks like it is forgotten, but the feature idea is cool!

[quilicicf]

The most basic version of this could simply be a list of missing plugins in the output instead of the generic message telling there is no .tool-versions.

Something like:

* nodejs x.y.z not installed because the plugin `nodejs` is not installed. You can fix this by running: asdf install nodejs; asdf install nodejs x.y.z
* haskell x.y.z not installed because the plugin `haskell` is not installed. You can fix this by running: asdf install haskell; asdf install haskell x.y.z

I can give this (or any other solution, provided I know what to develop) a go if it helps.

[tisoft]

I use this oneliner in my CI environment to install all plugins from a .tools-version file:

cut -d' ' -f1 .tool-versions|xargs -i asdf plugin add  {}

[Stratus3D]

I am closing this issue now as I believe the existing asdf API is sufficient for most use cases, and for those that would like automatic install of plugins a simple shell script or alias containing @tisoft one-liner will be sufficient. I've previously listed some other reasons why I think this is a bad idea, and now I feel like our limited resources ought to be focused on bugs and other higher priority features.

[quilicicf]

Would've been great to improve the error message as suggested in this comment though.
If it's only by lack of time, I can open a PR.
Good error messages really help.

[Stratus3D]

@quilicicf yes, I'd welcome a PR for that. However, I think it might be better to simplify the messages to just:

* nodejs x.y.z not installed because the plugin `nodejs` is not installed.
* haskell x.y.z not installed because the plugin `haskell` is not installed.

Because we can't be sure what the best way to resolve the issues is. The user might be expected to use a different implementation of say the haskell plugin rather than the one listed in the plugins repository. Or the plugin may not exist at all due to a typo, Or the plugin may be a private plugin only available within a certain organization, and the user will need to find and install it manually.

[quilicicf]

That's fine by me @Stratus3D 👍
Adding this to my TODO list.

[quilicicf]

Went digging and found out that threkk has already implemented a warning in #1033
Nothing more to do IMO.
Bumped to 0.9.0 and asdf install fails with return code 1 and the list of missing plugins when some are missing.

[PragTob]

Thanks y'all!

[codethief]

Here's another version of @tisoft's script to install all plugins from .tool-versions which also ignores line comments:

cat .tool-versions | cut -d' ' -f1 | grep "^[^\#]" | xargs -i asdf plugin add  {}

[connorads]

I use this oneliner in my CI environment to install all plugins from a .tools-version file:

cut -d' ' -f1 .tool-versions|xargs -i asdf plugin add  {}

macOS (BSD xargs) equivalent for those not running on Linux/CI

cut -d' ' -f1 .tool-versions|xargs -I{} asdf plugin add {}

[feld]

3. User runs asdf install. Malicious code in plugin is invoked and can do anything on the users system.

Are any of the plugins even validated by checksum before install? How do we trust them?

The only way it would be able to automatically install a plugin is if that plugin was committed to https://github.com/asdf-vm/asdf-plugins

If a malicious plugin gets added to that repository we have a much larger problem on our hands.

Please reconsider adding this feature. Its absence is complete security theater.

[pkit]

OMG, the tool that is just a bunch of bash scripts cannot add more bash scripts... lol

[RealOrko]

@Stratus3D

I think your security concerns are perhaps slightly misplaced by virtue of the fact that the intended plugin usage is still governed by the .tools-versions file. Can I take a moment to try convince you?

In security terms, you are concerned about Supply Chain Attacks. Although a valid concern, it is not the responsibility of the tooling author to mitigate this. The responsibility lies squarley on the shoulder of the end-user. The reason I say this is two fold.

• The security tools today rely heavily on CVE (Common Vulnerability and Exposure) databases and in some cases are very expensive too. So unless someone has found a pattern in some dependency somewhere and reported it, the security scan will gloss over the dependency (even if it has malicious code) and can still report it as being sound. So this is not entirely a silver bullet.
• The same problem exists with every single programming language with a package dependency management today (Java. Dotnet. NodeJs, Python, etc).

The biggest difference between you and the authors for the tooling of above mentioned programming languages is that they allow dependencies (which is code) to installed in a single hit. This is because they take the view that security is everyones responsibility, not just up to the authors of the tooling. It follows that the .tool-versions file is maintained by the end-user, very much similar to how developers have to maintain their dependencies in a code project. If you are willing to accept this is the case and adopt the same philosophy, it then becomes quite reasonable to implement this feature request which by the sounds of it is very trivial to achieve.

Are you convinced? :)

[quilicicf]

From what I understand of the discussion above, no-one is against a configurable way to add the missing plugins (see this comment and this one).

The author just stated they don't have time to work on something like this but if I didn't misunderstand, anyone is welcome to suggest a PR?

[RealOrko]

@quilicicf

I believe you might have misread the project owners earlier response on the feature request. He only gave approval for a PR to improve the messaging here.

Express permission for PR'ing this feature was dismissed at a "bad idea". I believe it is more of a phiolosophical disagreement then anything else. A shame because it would dramatically improve the UX for the CLI and most package management/plugin architectures support this kind of thing for most(if not all) main stream languages and IDEs.

[RealOrko]

I do think the suggestion of adding a flag is a great idea. I would suggest changing the feature ever so slightly to indicate better intent, maybe asdf install --add-plugins?

[quilicicf]

The message from Stratus didn't read like a complete dismissal to me.

But we can only guess the real intent, let's have them clear this.

I also think that having the feature behind a flag is the best of both worlds:

• better UX than everyone copying a one liner in their bashrc
• sane default of not installing anything unless specified otherwise

[Stratus3D]

As previously stated, the current workaround for this is one line:

cat .tool-versions | cut -d' ' -f1 | grep "^[^\#]" | xargs -i asdf plugin add {}

-- #276 (comment)

Given how easy it is to work around this issue what I stated previously still stands #276 (comment). I'm busy with more important tasks at the moment.

[RealOrko]

@Stratus3D I am grateful that you are assuming responsibility for this change but I think we were suggesting that one of us would create a PR for it. Or I would volunteer anyway!

[Stratus3D]

@RealOrko there is the initial cost to implement the feature (the PR) and the ongoing cost to maintain the feature (bug fixes, refactors, rewites, etc...). I personally feel like I've taken on too much open source for me to maintain at the level I would like, so I'm not interested in expanding the scope.

Currently we're exploring a total rewrite of asdf in a new language, so if this was added now I'd just have to rewrite it myself in a couple months.

[RealOrko]

@Stratus3D that is fair enough. I used to do open source back in the day and it took real commitment for sure. Folks are quick to raise issues, full of opinions and rarely help create solutions, so it can get busy. Just wanted to take the time to express my gratitude to all the contributors for this tool. It is a great CLI. I am looking forward to seeing the result of the re-write and wish you folks every bit of luck that the first release goes well! 💪 ♥️

[codethief]

@Stratus3D Like @RealOrko I really appreciate the effort you've put into asdf! I use it in many different projects and I like it a lot!

Currently we're exploring a total rewrite of asdf in a new language

Would it make sense to collaborate with https://github.com/jdxcode/rtx here?