Proposal: Simplify installation of krew as it makes adoption harder

[laverya]

Today, to install a plugin on a new machine, the user has to install krew and then the plugin. The recommended process involves copying and running a script that downloads a tarball with curl, decompressing it, and then executing a binary from within that tarball. After this completes, the user is then to add krew to their PATH manually, and finally to install the desired plugin via krew.

I’d like to propose a solution where we integrate the krew and plugin install process into a single script that automatically detects the shell and injects the PATH addition into the relevant bashrc/zshrc/etc file.

This isn’t inherently more insecure than the current solution because both fundamentally involve executing untrusted code directly from the internet.

The advantages of this are having an easy, memorable install process (curl https://krew.sh | bash) and that’s faster and more extensible than the current setup.

I’ve experimented with a prototype of this idea that’s currently available at krew.sh. There are a number of things that could be added to this - allowing the user to specify a prior krew version, for instance - but it functions at a basic level today.

I don’t think this should be the recommended, default, or only approach to installing krew. I’m proposing that this is created and hosted as a supported alternative to the current methods.

I think this will increase adoption of krew because developers will be able to give their customers a very easy, one line install as opposed to a multi-step process that involves copying scripts into the shell.

[corneliusweig]

Hey @laverya,
thanks for bringing the discussion onto this public platform. I have a few concerns about this:

• curl http://something | sh is an anti-pattern. We don't want to endorse it.
• The krew maintainers have no control over krew.sh. We have no idea what scripts are served there.
• The installation instructions on krew's homepage are already pretty straightforward. Everyone sees what's being executed and there is no execution of an unknown script.
• Krew also has installation instructions for fish and Windows. AFAICT, krew.sh only supports bash and zsh.

I will admit, that a one-line installation is nice. But it's not safe.

[laverya]

Addressing each in turn:

• I'd argue that running untrusted, unknown code is the anti pattern. We often see unsafe curl | sudo bash scripts as an implementation, but is downloading an untrusted .tar.gz, extracting it, and executing it inherently safer? A bash script at least has the potential to offer more transparency in that regard. I understand that this is probably more of a perception problem because I don't think it fundamentally is any safer or less safe than the current pattern used.

  • And there are improvement paths we can take with a bash script that would be less practical for one embedded within the readme - for instance we could implement the install process within bash to avoid the 'inspect binary' problem entirely, or embed a sha256sum verification check.

• krew.sh is the current endpoint, and IMO a nice vanity url for this. But we'd be happy to work something out there (whether to provide transparency or to transfer the domain into your control). I thought we'd open sourced the backing code earlier, but it's now up at https://github.com/replicatedhq/krew-installer. (EDIT: now really up)

• I would be very happy to suggest a two-step 'download this script, then run it' install process so that people can validate the script themselves.

• I don't think that krew.sh should completely replace the existing install methods, or even become the recommended install method. Just that it be made available.

A one line installation isn't safe. But it's not that far from what krew does today, either.

[ahmetb]

re: curl|sh

There was a time that curl -fsSL https://get.k8s.io | bash was supported. While it still exists today, it's frowned upon today –and by extension, we're a Kubernetes sub-project, so this affects us.

We might still find a way to do it. I own krew.dev. But I don't think SIG CLI can undertake responsibility of maintaining that.

I agree with you, this is the cleanest approach, but we need to be able to get behind that safely.

do we have other options?

We have been chatting with some SIG CLI folks that maybe we can provide a "placeholder" command named kubectl krew. First time you execute it, it offers a prompt to install or not.

This is all unorthodox, however. "Placeholder commands", "kubectl installing things", or even "kubectl prompting" is practically unheard of. :) So to keep kubectl small and consistent I suspect this approach will be den

[laverya]

An installer built into kubectl would be by far the best option (for krew adoption), but that feels like a big ask as you've said.

[joemiller]

How about distributing krew using native package managers (dnf, apt, etc) and/or homebrew for macos/linux? I'd love to be able to do brew install krew, for example.

[ahmetb]

Please read #475. We don’t intend to allow other package managers just yet.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.