Single repository for all plugins

[augustobmoura]

Is your feature request related to a problem? Please describe

Currently, each plugin has its own repository, owner, and per consequence development/review process and opinions.

Having the official plugins in such a fashion can be very insecure as the repositories can be exposed to bad actors, either with the consent of the plugin maintainers or by accident, via faulty reviews or security leaks of said accounts. Plugins can also be abandoned or deleted at will.

This is in my opinion a huge security threat, as we can't blindly trust all the different parties involved in plugins installs and updates.

Describe the proposed solution

Similar to how other tools handle it (homebrew, nixpkgs, oh-my-zsh) would be to keep all the plugins in a single repository.

Benefits:

• Changes would be reviewed in a standardized manner and in a controlled fashion. All PRs could be audited for security and deviations of the asdf-core philosophy.
• We could easily address updates and security fixes.
• Testing all packages could be a lot better. And installing/updating plugins could be simplified, as we wouldn't necessarily need to run plugin-add, all plugins would already be installed always.

I could work on this solution if the idea ever gets greenlighted.

Describe similar asdf features and why they are not sufficient

NA

Describe other workarounds you've considered

NA

[jthegedus]

The asdf core team agree with your points on plugins being a security nightmare.

We (the asdf core team), do not wish to be responsible for all security issues on hundreds (soon to be thousands) of plugins. We already have enough on our plate with the main tool.

My personal opinion is tools like Homebrew have given users a false sense of security. Most people do not know what is on their machines because these tools install a whole set of dependencies. People hear the name of a tool and type brew install X, which is why we have so many issues on the main repo of Hombrew users not reading documentation on setup, expecting us to modify their Shell configs as the default. This is the security problem IMO. Forcing users to take responsibility and learn their toolchain and audit their tools is a better path forward. Education.

We have signalled that we want to move away from maintaining this repo and implement a search functionality so users are explicitly knowing that they are adding tools from other users repos: asdf-vm/asdf#952 asdf-vm/asdf#1194

Testing of plugins is something we could look into further. An initial thought is that in the proposed plugin search solution require authors to use specific GitHub Actions and assert specific results for their tool to show in search results. There are many possible solutions to this problem then following the central repo model, which I do not think is most optimal for the goals I outlined above.

Thanks for taking the time to input here. More minds on a potential solution is what we're after. As are more hands typing out solutions ;) If you feel you have time to help on development it would be much appreciated.

[daveneeley]

Scoop.sh is a dev tool manager for Windows that has similar concerns. I noticed that they recently implemented search functionality .

In Scoop, users install buckets that include one or more tool definitions. The buckets are also git repositories; the tools can be binaries or installers or what have you. It's very similar to asdf. Their site now lists "Official" and "Community" buckets.

[bcdady]

I think this is something we could define requirements around and ask for community contributions.

Testing of plugins is something we could look into further...

@jthegedus, @daveneeley, et. al., what quality/security tests of plugins would you most like to see contributed?

I was curious what degree of testing is currently covered. I noticed the current GitHub Actions for this project include a Format and a Test workflow (which runs test_plugin.sh).

IMHO, the test_plugin script is a nice automation for including in PR checks and relying on successful builds to indicate that a plugin is ready to be added to the catalog. Would you agree we could start contributing worthwhile improvements by updating the Actions workflows a.k.a. CI jobs that run in the context of a PR to this repo? Or are there reasons you're thinking this should start in a new repo/project?

[bcdady]

Maybe this list in the comment of Issue 73 helps us fast-track next steps.

[daveneeley]

That's a great list. I'm all for that, particularly cryptographic signing, although that can be a hiccup for tools that don't publish a hash. Maybe github does it for free automatically? I noticed that the asdf-golang does crypotographic validation and wondered if that could be added to the asdf-templates repo.

My context for buckets / external repos was for a developer using their own collection of private tooling, working in an air-gapped environment, or vendors hosting their own set of tools, stuff like that. Easier to add one bucket with six plugins than six plugins individually. Those ideas might not be in scope for asdf, which is fine.

[jthegedus]

Not addressing the OP, but continuing the discussion.

I may migrate the functionality of scripts/test_plugin.bash into our GitHub Actions repo (I am about to rework that whole repo) and then we can assert here that people are using that and that the result is green. And then re-validate this for all plugins on each merge here and on a schedule. This would also be useful in future when we perform search as we can use it (whether they use our action and it's result) as a metric to show users.

I just refactored the CI of this repo to run scripts/test_plugin.bash on each merge to master and on PR. So, now we will always have a list of plugins not meeting our standards in the CI logs. Not best, but better.

[hyperupcall]

Having a single repositories is something I would like to support too. However, I don't think one repository should hold all plugins - that repository would be too big and hard to maintain. But, it would be a good idea for each repository to hold 1-10 tools each.

If security is a concern right now, one could create a directory with various cloned asdf plugins, and apply the following (VERY hacky) patch to asdf. Note that I'm only supplying this for informational purposes and this type of configuration is not officially supported whatsoever.

diff --git a/lib/functions/plugins.bash b/lib/functions/plugins.bash
index 247a22d..31dff85 100644
--- a/lib/functions/plugins.bash
+++ b/lib/functions/plugins.bash
@@ -85,8 +85,14 @@ plugin_add_command() {
     asdf_run_hook "pre_asdf_plugin_add" "$plugin_name"
     asdf_run_hook "pre_asdf_plugin_add_${plugin_name}"
 
-    if ! git clone -q "$source_url" "$plugin_path"; then
-      exit 1
+    if [ -d "$source_url" ]; then
+      if ! cp -r "$source_url" "$plugin_path"; then
+        exit 1
+      fi
+    else
+      if ! git clone -q "$source_url" "$plugin_path"; then
+        exit 1
+      fi
     fi
 
     if [ -f "${plugin_path}/bin/post-plugin-add" ]; then

This makes it so that plugins that are located in directories (not just from a URL) can be installed or uninstalled (but not updated).

You can clone the plugins you wish to use or use a some special repositories that I'm working on (not officially a part of asdf!) One of: (plugins-format-git-subtree or plugins-format-gitsubmodule or plugins-format-googlerepo)

In the future, I hope to add actual official support for this kind of thing - or something entirely different that accomplishes the same goal.

[ollietreend]

A centralised repo would help avoid PRs being ignored and going unanswered for months – for example, sourcesense/asdf-azure-cli#1 😕