Official-images: Rebuild Varnish Docker image with latest Debian base image

[pacifier17]

I see that Varnish Docker image was last built 2 months ago: https://hub.docker.com/_/varnish?tab=tags

This image is based on debian:buster-slim image which I see was updated 8 days ago: https://hub.docker.com/_/debian?tab=tags&page=1&name=buster-slim

From this FAQ I see that official Docker images are regularly rebuilt to fix any known vulnerabilities: https://github.com/docker-library/faq#why-does-my-security-scanner-show-that-an-image-has-cves

But since the Varnish image was not rebuilt using the latest debian:buster-slim image it now has this vulnerability in it which is supposed to be fixed by the latest version: https://security-tracker.debian.org/tracker/CVE-2020-10757

Would you be able to help rebuild the Varnish image to fix this vulnerability?

Is debian:buster-slim considered an official image? If yes, then shouldn't the Varnish image have been rebuilt automatically?

[yosifkit]

It has been attempted to build multiple times (on each debian update), but has been failing to complete: https://doi-janky.infosiftr.net/job/multiarch/view/images/view/varnish/job/amd64/job/varnish/.

As for the failure, it looks like it is using hkps://hkps.pool.sks-keyservers.net to fetch gpg keys. We see issues all the time with fetching keys, but we can't insert our cache/proxy in the ssl based fetch (see also https://github.com/docker-library/faq/#openpgp--gnupg-keys-and-verification).

[tianon]

cc @gquintard

[gquintard]

Thanks all. @yosifkit, if I read your comment and link right, we should use hkp://hkps.pool.sks-keyservers.net or hkps.pool.sks-keyservers.net so that the build system can MITM and provide the key, right?

[tianon]

Yes, but also switching to one of the non-hkps pools (since the servers in the hkps pool likely also respond to hkp traffic, but aren't necessarily required to) like ha.pool.sks-keyserver.net (which is the one we usually use).

[tianon]

(Alternatively, get the email address verified on https://keys.openpgp.org/ and then you can keep hkps since that service is actually reliable :sweat_smile:)

[gquintard]

Yes, but also switching to one of the non-hkps pools (since the servers in the hkps pool likely also respond to hkp traffic, but aren't necessarily required to) like ha.pool.sks-keyserver.net (which is the one we usually use).

gotcha, will switch to that, thanks for the quick support as always!

(Alternatively, get the email address verified on https://keys.openpgp.org/ and then you can keep hkps since that service is actually reliable sweat_smile)

I think it's packagecloud's key, so I'm not sure we can do that. I'll check

[gquintard]

thank you @tianon and @yosifkit , it's always a pleasure contributing here.

@pacifier17, thanks a lot for the investigation and not letting go!