Ensure plugins authenticate downloaded files

[ypid]

A few plugins seem to be maintained as part of asdf-vm. Please ensure that those plugins properly authenticate downloaded files.

[Stratus3D]

@ypid good catch.

We have a plugin-test command that ensures plugins work properly and meet our standards. Can you think of a way to automatically check for HTTP downloads in our plugin-test command? I suppose we stub curl and wget and see what arguments they are passed. If it's not automated it's probably not going to happen...

[ypid]

The easiest and most effective step would be to check all source code of plugins and enforce that no unauthenticated legacy HTTP connection attempts are to be made. Ref: asdf-vm/asdf-nodejs#16

And maybe a warning could be given if no gpg command is used which is commonly used to verify signatures.

[danhper]

I will close this issue, as it has been inactive for a long time now.
If there is still interest, please feel free to open a new issue.
Thank you!

[lestephane]

I don't see this issue as having been addressed at all. Since plugins can be loaded from anywhere, there is a huge risk in doing asdf install this or asdf install that. There should be at least a way to restrict asdf to using core maintained plugins, and deny others. A denylist or allowlist capability is the very least that needs to be in place, until any thought has been given to a 'proper' solution (which may never come).

For now I deny untrusted plugins this way:

cd ~/.asdf/installs
# explicitly deny the installation of untrusted plugin 'git'
ln -s /dev/null git
# deny all other not-yet-installed plugins by default
chmod u-w .

[Stratus3D]

@lestephane asdf doesn't implicitly install any plugins. You have to manually asdf plugin add <plugin> in order to get new code on your computer. Once you have installed a plugin it can download data from where ever it wants to, there is no way for us to constrain that. If you are concerned about where plugins pull data from I suggest you audit the source code before running asdf plugin add <plugin>. We'd love to offer better guarantees around plugins, but we don't have any maintainer time to dedicate to third party plugins.

[lestephane]

If you are concerned about where plugins pull data from I suggest you audit the source code before running asdf plugin add <plugin>.

In my case, I could not audit the code for the git plugin, because it is hosted on a gitlab instance that, at least today, was returning HTTP 429 (too many requests), which made me want to avoid using the plugin altogether.

I ended up denylisting as described, and used homebrew for linux to install the latest git instead. Maybe there is a way to benefit from the declarative clarity of .tool-versions, while using homebrew to actually install the versions. So that we can leverage all the work that's been done there, and the only code that people need to write for asdf is for niche needs, for packages that do not exist in homebrew yet.

And one could potentially, down the line, indicate that versions are to be taken exclusively from homebrew. Mind you, I only installed Homebrew for Linux today, because I did not know it event existed outside of the MacOS ecosystem. And so I do not not know yet how trustworthy packages there can be assumed to be. But I would trust those packages over asdf plugins for sure. There are analytics that I can use to make install decisions:

$ brew info git
...
==> Analytics
install: 226,185 (30 days), 759,196 (90 days), 2,934,353 (365 days)
install-on-request: 220,353 (30 days), 742,485 (90 days), 2,872,847 (365 days)
build-error: 15 (30 days)

[jthegedus]

@lestephane Homebrew manages installation of entire dependency trees without your explicit approval, so as I see it, installing an asdf plugin or a Homebrew package is equally fraught with security concerns.

With asdf plugins you can specify the commit sha of the plugin when you add the plugin. So at least you know people can't change the plugin behaviour out from underneath you. You can even go so far as to Fork each plugin repo you use and maintain your own copy.

asdf as a solution is definitely not as sophiscated as Homebrew, but IMO that is a benefit of asdf. The lack of dependency management allows for an easier time managing the many versions of a tool across a single machines directory tree. We are version management first, not package management which Homebrew is. Trade offs.