Stop using ANY Container-image

Summary

Stop using:

docker run --privileged --rm tonistiigi/binfmt --install all ;

❌ Warning !! This is an unverified 3rd-party container-image
Speaking in his favor, Tonis Tiigi puts in a lot of effort 👍 to keep this Container-image updated.
FYI: Life and software is a marathon that no single person can keep doing all alone for long.

docker run --rm --privileged public.ecr.aws/k1t8c0v2/multiarch/qemu-user-static:latest --reset -p yes

❌ Warning !! Un-verified 3rd-party container-image. It is NOT being supported❌ and became outdated❌ a few years ago.

docker run --rm --privileged multiarch/qemu-user-static --reset -p yes

This .. is was .. (in contrast to tonistiigi) community-supported. As is so common, it is NOT being supported❌ and became outdated❌ a few years ago.

Instead (for 2026) use ✅

    sudo apt update ;
    sudo apt install -y qemu-system-arm qemu-user-static binfmt-support ;

    docker run --privileged --rm public.ecr.aws/eks-distro-build-tooling/binfmt-misc:qemu-v7.0.0 --install all ;

How can you simply test/verify, if this will work for you?
See Appendix below.

Switch from apt to dnf or other package-manager as appropriate for your needs.

Why bother?

(Want an alternative to -NOT- do the above, see next section.)

This is a Security topic. Either you get it, and eagerly (repeat: eagerly) implement the recommendations.
Or, you are part of the problem.

Here's another way to look at this article:

You: But.. but.. Mx. Police officer! Everyone else is going 25xph over the speed limit.
Police Officer: Fact is -YOU- are going 25xph over the speed limit. Here's your speeding ticket/चालान.

If you'd like to STILL argue/defend yourself about how the speeding-ticket says you being discriminated against ..
.. stop reading this.

This is a Security topic. Either you get it, and eagerly (repeat: eagerly) implement the recommendations.
Or, you are part of the problem.

How many times have I seen people point this out:- That His Excellency, the current US President, frequently says "I've heard SO MANY other people say.. .." on something most people have Not heard about.
We -ALL- do the SAME EXACT thing (like demonstrated in this article below) sooo frequently .. but, Mr. President, we are holier than thou.

This is a Security topic. Either you get it, and eagerly (repeat: eagerly) implement the recommendations.
Or, you are part of the problem.

"One guy" (one of us) writes -ONE- blog about using a container owned by tonistiigi.
Another "One guy" (one of us) writes -ONE- post about using a container owned by k1t8c0v2.
For years on end, ..
(repeating it) For years on end, ..
developers keep repeating "I've heard -SO MANY- people use .. .. .."
Exactly like in an echo chamber, these 3rd-party container-images get broadcast all over, and magically they becomes trustworthy!

In this day and age, where the lineage of SBOM is so important, why do you use 3rd party container-images?

What is "SBOM", you ask?!
You are part of the problem.

Alternative

There is an alternative to NOT doing anything from this article.
This alternative was so well demonstrated during a recent media-covered DATA-LEAK incident about a "Tea App".
On face-value, it appears that the Product-Manager(s), senior-most management and/or developers did Nothing to prevent the leak.
No Security whatsoever.
Everything about women expressing private opinions, including their IDs, were exposed. The women were humiliated.

So, do you know what the company owning "Tea App" did?
They took advantage of the narrative, that the "Men who were detailed in the Tea App, conspired with the so many other Men of this world, and hacked the app, to take some kind of revenge on those women".
"The product-manager(s), senior-management and/or developers were GOOD people with the proverbial golden ring HALO above their heads".

"The road to hell is paved with good intentions" is a meaningless jumble of words.

Bottomline: Instead of "fixing potential security" problems, get a Communication Major/Degree and "indulge in Media Spin" like the above couple of paras, instead.
That is the only other alternative (to this article) that I am aware of.

Why should I trust the above recommendation?

AWS Owns and Maintains this specific container image.
AWS uses it in the context of EKS (at least for now).
Added benefit: Within AWS, you will Not hit limits on your "docker pull/run.." !
- FYI: I use it extensively in my Pipelines, which pull this image so so many times.

Appendix - How to SIMPLY confirm that the replacement works?

Within an O/S on X86 ..

    OtherChipArch="linux/arm64"
    sudo update-binfmts --display | grep arm ;
    docker buildx ls ;

    echo "Sanity-check the ARM64-chipset execution via X86-Docker-in-Docker..."
    docker run --rm --privileged --platform ${OtherChipArch}  public.ecr.aws/sam/build-python3.12:latest python --version

You know how to do the other way around.

Appendix -- For those who love mega-deep-dives

The ABOVE-docker-cmd installs the QEMU binaries + registers them with binfmt_misc, enabling QEMU to execute non-native file formats for emulation

    ## These `update-binfmt` cmds are --NOT-- sufficient.  We need the "PRIVILEGED" docker-cmd !!!
    ## Register QEMU interpreters for multi-platform builds
    ## CLI-manpage: https://manpages.debian.org/testing/binfmt-support/update-binfmts.8.en.html
    sudo update-binfmts --enable qemu-arm ;
    sudo update-binfmts --enable qemu-armeb ;
    sudo update-binfmts --display | grep arm ;