Enable https verification for wget or disable https about busybox HOT 11 OPEN

Not very scientific but, as expected, most people are surprised by this: https://twitter.com/discordianfish/status/1234537962093740033
I'd suggest to disable it. It will break users, but better to break than putting them at risk, right?

from busybox.

I am very confused by this issue, it seems like something is actually wrong with wget in the busybox container (but only when run inside of a Kubernetes cluster).

For example, when running wget "https://get.helm.sh/helm-v3.10.3-linux-amd64.tar.gz" in busybox:1.36.1 on Kubernetes 1.26, you will get the following error (and the file will NOT download):

wget: note: TLS certificate validation not implemented
wget: TLS error from peer (alert code 80): internal error
wget: error getting response: Connection reset by peer

However, this wget "https://get.helm.sh/helm-v3.10.3-linux-amd64.tar.gz" will succeed in an alpine image like alpine:3.18.2.

For now, I guess I recommend people use alpine until this is fixed.

from busybox.

We don't do anything specific to explicitly enable (or disable) https support in BusyBox's wget applet, so the fact that it's enabled is because it's enabled by default upstream. Given that and the notice being pretty clear about validation not being implemented (despite not exiting with a non-zero exit code), I'd argue we're faithfully representing BusyBox upstream's preferences here, which is our goal:

IMO there's a pretty decent argument for having BusyBox upstream implement --no-check-certificate and enforce using it for all https URLs when certificate validation is not implemented, but that's a discussion that should happen with upstream (https://bugs.busybox.net/).

from busybox.

Well yeah it's the usual questions about how is responsible for the security of their users..
But you can disable it apparently: https://git.busybox.net/buildroot/tree/package/busybox/busybox.config?id=d5507262f37506d6b1b48eb409ed8bc3f08d3e47#n933

from busybox.

IMO there's a pretty decent argument for having BusyBox upstream implement --no-check-certificate and enforce using it for all https URLs when certificate validation is not implemented, but that's a discussion that should happen with upstream (https://bugs.busybox.net/).

It turns out the exact change I've proposed was submitted at http://lists.busybox.net/pipermail/busybox/2018-May/086444.html, followed by quite a long discussion that amounts to "we can't change it, because it would break existing user scripts" (http://lists.busybox.net/pipermail/busybox/2018-May/086457.html) but it did result in both the warning we currently get (http://lists.busybox.net/pipermail/busybox/2018-May/086467.html), and as of today's 1.32.0 release, https://git.busybox.net/busybox/commit/?id=45fa3f18adf57ef9d743038743d9c90573aeeb91. Unfortunately, that patch only accounts for the case where there's a separate openssl binary available for busybox to shell out to.

from busybox.

We add the ca-certificates to this image. I'm not sure that will help with wget, but it makes statically compiled (like Go binaries) work.

Would it be OK to include the /etc/ssl/certs/ca-certificates.crt in the busybox images?

from busybox.

Given that nothing in Busybox would use it out of the box, I think it would be misleading for us to include by default, unfortunately.

from busybox.

This wasn't fixed upstream?
https://git.busybox.net/busybox/commit/networking/wget.c?id=dbe95682b4bf1192d2860646617f157e6c44f2d1

from busybox.

No, that change unfortunately only makes sure the warning is only printed once per invocation -- it doesn't turn the warning into an error (that's what https://git.busybox.net/busybox/commit/?id=45fa3f18adf57ef9d743038743d9c90573aeeb91 does, but only in the case of the OpenSSL-using implementation).

from busybox.

replace busybox with curlimages/curl,then use curl to download what you want
https://hub.docker.com/r/curlimages/curl

from busybox.

However, this wget "https://get.helm.sh/helm-v3.10.3-linux-amd64.tar.gz" will succeed in an alpine image like alpine:3.18.2.

The busybox image is as close to upstream BusyBox releases as we can; the busybox binary in Alpine Linux is their own Alpine fork (i.e. patched and configured in a non-default way) as distributions tend to do. In other works, just because something works or is possible with Alpine's package does not mean it is part of the busybox image.

from busybox.