drwetter / testssl.sh

Testing TLS/SSL encryption anywhere on any port
https://testssl.sh
GNU General Public License v2.0
7.98k stars 1.02k forks source link

Docker image for ARM64 #2085

Open vahidshirvani opened 2 years ago

vahidshirvani commented 2 years ago

Which version are you referring to latest

Problem: No ARM64 image available on Docker Hub. Only AMD64 is published.

Screenshot 2022-01-13 at 09 16 20

Solution: This can be solved with Docker Buildx which builds several images for different architectures. So in your case it should be something similar to

docker buildx build --platform linux/arm64,linux/amd64 -t drwetter/testssl.sh:latest . 

Motivation: Apple Macbook with M1 chip are becoming more prevalent. These machines do not use your typical Intel CPU but are rather ARM based. Apple sees Intel as legacy and as time passes by those machines will be phased out in favour of ARM.


Note: By Intel I mean x86-64 or x64 or x86_64 or AMD64 or Intel 64. Note: By ARM I mean ARMv8 or ARM64 or AArch64.

drwetter commented 2 years ago

Hi @vahidshirvani ,

the question is whether docker hub supports that, which I can't tell. Do you?

OT: As of now we can't use the broken openssl 1.0.2. I wasn't able to compile this for M1. This is in general no problem as macOS comes with LibreSSL which we can use as a vehicle for the cases needed.

vahidshirvani commented 2 years ago

Yes, Docker Hub does support it so you can push multiple architectures. For example see OS/ARCH column for alpine.

The Docker on MacOS runs inside a Linux Virtual Machine, so what ships with MacOS won't interfere.
I forgot to mention that once you build and push then this will work on Raspberry Pi 3 and 4 as well as those machines are ARM64 based.

drwetter commented 2 years ago

We could need a hand here

jauderho commented 2 years ago

@drwetter I do not have a Docker Hub paid account so I do not know if the build process there can support multi-platform builds. BUT the action that I built for you does already push multi-platform to GHCR. Those can be found here: https://github.com/drwetter/testssl.sh/pkgs/container/testssl.sh

This might be a reason why you want to use GH to build the images then push to both Docker Hub and GHCR as I previously suggested.

@vahidshirvani You can use the link I shared above or if you must use Docker Hub, I do have images here: https://hub.docker.com/r/jauderho/testssl.sh/tags

drwetter commented 2 years ago

Ok, thanks.

Your images stem from GHA pushes or how do you get the platforms in there?

jauderho commented 2 years ago

@drwetter I push from GHA to Docker Hub and GHCR.

See https://github.com/jauderho/dockerfiles/blob/main/.github/workflows/age.yml (lines 51 - 64) for an example.

vahidshirvani commented 2 years ago

Thank you for your answers. I helped me. I will close this issue.

drwetter commented 2 years ago

I still have headaches (security-wise) hard-wiring access tokens in Github from Docker. There have been issues in the past.

If anyone can give me a hand how to convince dockerhub to supply other architectures that would be great.

drwetter commented 2 years ago

I could need a hand here.

If there's a way w/o hard-wiring access tokens here

tenjaa commented 1 year ago

The GHCR image already offers an ARM build. Why not link it in the readme instead of the dockerhub one?

eins78 commented 1 year ago

@drwetter I can confirm that the GHCR version works on ARM, although it offers less/different tags than on Dockerhub) I ran it like this: docker run --rm -it ghcr.io/drwetter/testssl.sh

If you still want to publish to Dockerhub from GH Actions, here are the official docs on how to configure the authentication in a secure way using "secrets": https://docs.github.com/en/actions/publishing-packages/publishing-docker-images

drwetter commented 1 year ago

Thanks @tenjaa and @eins78 .

I lack currently a bit of time, but I had a quick look at the encrypted secrets page. From the security architecture perspective I am still wondering why one should handover + store passwords which is under other circumstances a "no, don't ever do that". Encrypting the password with another secret -- if understood that correctly -- doesn't make it better as I trust github to store that properly and there will never be flaws in the github workflow.

Do I understand something wrong?

eins78 commented 1 year ago

@drwetter This part might be a bit misleading in their docs, I don't assume you'll enter your "personal" username + password into the GitHub secrets (which indeed would be "icky"), but rather an access-token for this purpose, which can be revoked in case there is a problem at Github or you just want to stop using them for whatever reason. You can do that in dockerhub here: https://hub.docker.com/settings/security

drwetter commented 1 year ago

@eins78 : That token seem to want read / write / delete access to docker hub.

Currently it works that as soon as there is a push to one of the branches here (github), dockerhub just automatically builds the image. No credentials/token or whatsoever involved.

I do not get why this image is amd64 only and whether this repo can do something to provide instructions for dockerhub to build other archs -- maybe with tags in the Dockerfile like FROM <ARCH>/alpine:<VERSION> or any TARGETPLATFORM or by any other means?

That would be my first choice.

PS: in the UX at dockerhub there was no setting where I could set the architecture. Albeit the UX is gruesome it looks like I didn't overlook such a setting.

drwetter commented 1 year ago

Maybe somebody can add a section ### From GitHub Container Registry to Dockerhub.md accordingly?

That would be much appreciated!