建议: 支持更多的工件检索方法

与 #684 和 #816 有关 ##### 概述 我正在寻找一些初始实现反馈，以支持私有 GitHub 仓库版本以及一些其他可能的资产仓库。 这里的目的是支持运行自定义命令的某种方式，这些命令通过 stdout 返回资产文件。 这可以解决 #684 问题，通过运行类似于 `gh api -H Accept:application/octet-stream /repos/Kubernetes-sigs/krew/releases/assets/55894121` 来从私有 GitHub 仓库的版本资产中下载资产。 它还可以允许人们在私有 krew 索引中拥有依赖本地机器工具来获取资产的命令。 我正在考虑类似 `AWS s3 cp s3://my-fancy-private-bucket/my-cool-krew-plugin.tgz -` 这样的示例命令。 这种支持可以将身份验证问题与运行安装的本地机器分离。 最初我希望以 S3 SDK 方案来实现此功能，但后来决定通过在本地机器上运行命令来支持更多选项。 我也很乐意在这里讨论其他方法。 ### 对设计的早期反馈 请记住，我的测试和工作非常粗糙，只是一个初步概念。 1. 这种实现是否应该扩展 `uri` 规范键，以支持其他"方案"（例如 `file://` 和 `cmd://`）？还是它应该真正成为插件清单规范中的一个单独键？ (提供类似 `cmd://run-my-super-sweet-script -i thing -o otherthing` 的字符串感觉不太理想。) 2. 这种实现是否应该利用文件系统上的临时文件来"缓冲"来自"资产下载命令"的 stdout？ 我最初尝试使用 `exec.Command()` 和 `exec.Command().Stdout()`，但遇到了在流可读之前管道关闭的问题（似乎是 `exec.Command()` 的预期功能）。 3. 这种实现是否引入了过多的安全风险，允许在安装插件时通过 krew 来有效执行任意代码？ 下面是使用此 PR 的示例插件清单，以示目前的写法。 yaml apiVersion: krew.googlecontainertools.GitHub.com/v1alpha2 kind: Plugin metadata: name: testfile spec: version: "v0.0.1" homepage: https://somedomain.com/ shortDescription: Throwin testfiles caveats: | Something something testfile platforms: - uri: cmd://gh api -H Accept:application/octet-stream /repos/Kubernetes-sigs/krew/releases/assets/55894121 sha256: 5df32eaa0e888a2566439c4ccb2ef3a3e6e89522f2f2126030171e2585585e4f bin: testfile files: - from: ./krew-linux_amd64 to: testfile selector: matchExpressions: - key: "os" operator: "In" values: - linux - darwin