Add ability to ignore certificate checks or clone via ssh when installing krew

[timblaktu]

I get a certificate error cloning krew-index when executing the last command in the instructions:

tim@DESKTOP-646JHDO:/tmp/tmp.3xNSSH4Phm$ ./krew-linux_amd64 install krew
Adding "default" plugin index from https://github.com/kubernetes-sigs/krew-index.git.
failed to add default plugin index in absence of no indexes: command execution failure, output="Cloning into '/home/tim/.krew/index/default'...\nfatal: unable to access 'https://github.com/kubernetes-sigs/krew-index.git/': server certificate verification failed. CAfile: none CRLfile: none\n": exit status 128

I'm on Debian 11.3, and using kubectl 1.23.5:

tim@DESKTOP-646JHDO:/tmp/tmp.3xNSSH4Phm$ kubectl version --client
Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.5", GitCommit:"c285e781331a3785a7f436042c65c5641ce8a9e9", GitTreeState:"clean", BuildDate:"2022-03-16T15:58:47Z", GoVersion:"go1.17.8", Compiler:"gc", Platform:"linux/amd64"}

I get the same error trying to clone krew-index separately using https, but using ssh works fine:

tim@DESKTOP-646JHDO:~/src$ git clone https://github.com/kubernetes-sigs/krew-index.git
Cloning into 'krew-index'...
fatal: unable to access 'https://github.com/kubernetes-sigs/krew-index.git/': server certificate verification failed. CAfile: none CRLfile: none
tim@DESKTOP-646JHDO:~/src$ git clone git@github.com:kubernetes-sigs/krew-index.git
Cloning into 'krew-index'...
remote: Enumerating objects: 7447, done.
remote: Counting objects: 100% (7447/7447), done.
remote: Compressing objects: 100% (2105/2105), done.
remote: Total 7447 (delta 5347), reused 7395 (delta 5330), pack-reused 0
Receiving objects: 100% (7447/7447), 1.82 MiB | 10.92 MiB/s, done.
Resolving deltas: 100% (5347/5347), done.

I'm able to somewhat resolve this by using the GIT_SSL_NO_VERIFY git internal env var, cloning the https repo successfully:

tim@DESKTOP-646JHDO:~/src$ GIT_SSL_NO_VERIFY=true git clone https://github.com/kubernetes-sigs/krew-index.git
Cloning into 'krew-index'...
remote: Enumerating objects: 7451, done.
remote: Counting objects: 100% (7451/7451), done.
remote: Compressing objects: 100% (2107/2107), done.
remote: Total 7451 (delta 5349), reused 7398 (delta 5332), pack-reused 0
Receiving objects: 100% (7451/7451), 1.83 MiB | 6.65 MiB/s, done.
Resolving deltas: 100% (5349/5349), done.

...and likewise applying GIT_SSL_NO_VERIFY to the original issue gets me further (it can clone now) but I still get a different certificate error in a subsequent git cloning operation:

tim@DESKTOP-646JHDO:/tmp/tmp.3xNSSH4Phm$ GIT_SSL_NO_VERIFY=true ./krew-linux_amd64 install krew
Adding "default" plugin index from https://github.com/kubernetes-sigs/krew-index.git.
Updated the local copy of plugin index.
Installing plugin: krew
W0406 15:00:30.484562   19018 install.go:164] failed to install plugin "krew": install failed: failed to unpack into staging dir: failed to unpack the plugin archive: failed to obtain plugin archive: failed to download "https://github.com/kubernetes-sigs/krew/releases/download/v0.4.3/krew-linux_amd64.tar.gz": Get "https://github.com/kubernetes-sigs/krew/releases/download/v0.4.3/krew-linux_amd64.tar.gz": x509: certificate signed by unknown authority
failed to install some plugins: [krew]: install failed: failed to unpack into staging dir: failed to unpack the plugin archive: failed to obtain plugin archive: failed to download "https://github.com/kubernetes-sigs/krew/releases/download/v0.4.3/krew-linux_amd64.tar.gz": Get "https://github.com/kubernetes-sigs/krew/releases/download/v0.4.3/krew-linux_amd64.tar.gz": x509: certificate signed by unknown authority

So I then re-tried the whole install sequence using insecure everywhere (I think) and I still got certificate errors:

tim@DESKTOP-646JHDO:/tmp/tmp.3xNSSH4Phm$ (   set -x; cd "$(mktemp -d)" &&   OS="$(uname | tr '[:upper:]' '[:lower:]')" &&   ARCH="$(uname -
m | sed -e 's/x86_64/amd64/' -e 's/\(arm\)\(64\)\?.*/\1\2/' -e 's/aarch64$/arm64/')" &&   KREW="krew-${OS}_${ARCH}" &&   curl -kfsSLO "http
s://github.com/kubernetes-sigs/krew/releases/latest/download/${KREW}.tar.gz" &&   tar zxvf "${KREW}.tar.gz" && export GIT_SSL_NO_VERIFY=tru
e && ./"${KREW}" install krew; )
++ mktemp -d
+ cd /tmp/tmp.HA6UsWuK2l
++ uname
++ tr '[:upper:]' '[:lower:]'
+ OS=linux
++ uname -m
++ sed -e s/x86_64/amd64/ -e 's/\(arm\)\(64\)\?.*/\1\2/' -e 's/aarch64$/arm64/'
+ ARCH=amd64
+ KREW=krew-linux_amd64
+ curl -kfsSLO https://github.com/kubernetes-sigs/krew/releases/latest/download/krew-linux_amd64.tar.gz
+ tar zxvf krew-linux_amd64.tar.gz
./LICENSE
./krew-linux_amd64
+ export GIT_SSL_NO_VERIFY=true
+ GIT_SSL_NO_VERIFY=true
+ ./krew-linux_amd64 install krew
Updated the local copy of plugin index.
Installing plugin: krew
W0406 15:06:30.862167   19083 install.go:164] failed to install plugin "krew": install failed: failed to unpack into staging dir: failed to unpack the plugin archive: failed to obtain plugin archive: failed to download "https://github.com/kubernetes-sigs/krew/releases/download/v0.4.3/krew-linux_amd64.tar.gz": Get "https://github.com/kubernetes-sigs/krew/releases/download/v0.4.3/krew-linux_amd64.tar.gz": x509: certificate signed by unknown authority
failed to install some plugins: [krew]: install failed: failed to unpack into staging dir: failed to unpack the plugin archive: failed to obtain plugin archive: failed to download "https://github.com/kubernetes-sigs/krew/releases/download/v0.4.3/krew-linux_amd64.tar.gz": Get "https://github.com/kubernetes-sigs/krew/releases/download/v0.4.3/krew-linux_amd64.tar.gz": x509: certificate signed by unknown authority

[chriskim06]

does this mean you don't have any root CAs in your trust store? if you go to https://github.com in your browser do you get that untrusted site warning?

[timblaktu]

@chriskim06 yes. This is on a fresh Debian install.

[chriskim06]

im not sure what the security implications would be for allowing krew to not verify tls (also not sure if we want to do that). is it not an option to add github's root ca to your trust store?

[timblaktu]

I was able to install the root and intermediate ca (which was a little confusing in our corporate firewalled environment), and the issue is resolved. Thanks.