Don't rely on the less trustworthy carlosedp/golang docker image for other platforms than riscv64

[yo8192]

In commit 252397a the build Docker image was switched from the very standard, widely used and
trusted official golang Docker image to the much more niche, unknown carlosedp/golang Docker image (e.g. it has zero star on Docker Hub!).

The source of this Docker image appears to be https://github.com/carlosedp/riscv-bringup/blob/master/Dockerfiles/Dockerfile.golang, however I am not sure we can definitely tell if that it is indeed the case. I think we are left to rely on how much we trust the Docker Hub account carlosedp, and I am not sure there is a good reason to trust it per say, or even that it belongs to the same person as the GitHub account of the same name?

I am concerned by this for a security-sensitive Docker image as shenxn/protonmail, which sees credentials and unencrypted data (emails).

I understand carlosedp/golang is used as a way to support riscv64, and perhaps it is the best or only option for riscv64. However I don't think it makes sense to expose the vast majority of users, who use other platforms than riscv64, to the risk of carlosedp/golang when the official golang image works perfectly well for them.

A few possible ways forward come to mind:

1. Have two different Dockerfiles, one for riscv64 that uses carlosedp/golang, one for all the other platforms that uses the official golang image.
   • Pro:
     • initially very simple
   • Con:
     • 2 almost identical Dockerfiles to keep in sync (I don't think Dockerfiles have an include do they?). Or adds a bit of complexity elsewhere to generate the two Dockerfile on the fly from one single source.
     • may make the build a bit more complex to select the right Dockerfile depending on the architecture
2. find a way to effectively do the same with a single Dockerfile, e.g. some kind of if statement that picks the right image based on the architecture -- it would I think be the best option, but from my quick look I didn't see a way to do this. I am not a Docker expert though, so I may well have missed something?
3. instead of using carlosedp/golang, in protonmail-bridge-docker/build/Dockerfile replace FROM carlosedp/golang:1.18 AS build by the content of https://github.com/carlosedp/riscv-bringup/blob/master/Dockerfiles/Dockerfile.golang. This would mean it would be easy to be sure that the golang binary comes from the official golang website on all platforms but riscv64.
   • Pro:
     • simple to implement
     • probably nothing else to change in terms of build
   • Con:
     • Slower build as we'd do more in our Dockerfile
     • We then have to maintain the extra Dockerfile code (it's just a few lines, but might need to change at some point in the future?)

What do you think would be the best way to solve this?

(I am happy to propose a PR for 3, or for at least the Dockerfile part of 1 -- I'd be happy to try a PR on 2 if someone shows me a way to do it!)

[Enucatl]

As of today, golang >= 1.20 is needed to compile the image anyway. I changed to the official golang image in my fork.

[Ogglord]

I could not agree more. I strongly recommend using @Enucatl fork instead of this, or fork it yourself.