Use docker "immutable identifier" instead of tag

[Tonux599]

CircleCI and docker_repro.sh should use Docker's immutable identifier (sha256 digest of image) instead of tags.

Currently, using tags, the administrators of Docker Hub could be coerced into modifying tlaurion/heads-dev-env to produce malicious ROM's.

@tlaurion the safest way to ensure that CircleCI and local builds with docker_repro.sh are not tainted by a malicious images would be to use immutable identifiers instead of tags. Going forward, I would recommend you build your container locally, taking note of the sha256 digest, then pushing to docker hub before creating a signed commit replacing the checksums in .circleci/config.yml.

[tlaurion]

The idea was that docker image is supposed to be reproducible with the commit with which it was created. Trust but verify idea of reproducible builds here again.

I have no strong opposition to merge this as long as the instructions for maintainer follows in global README.md

[Tonux599]

The idea was that docker image is supposed to be reproducible with the commit with which it was created. Trust but verify idea of reproducible builds here again.

That's good, but end users will probably skip building their own Docker image and would benefit from an immutable Docker image.

I have no strong opposition to merge this as long as the instructions for maintainer follows in global README.md

./docker_local_dev.sh and ./docker_latest.sh IMO can stay on the latest tag as generally the expectation would be resulting ROM's are not used in production. Whereas ./docker_repro.sh and CircleCI artefacts are expected to be used by end-users and (I believe) would benefit from the additional safety net of immutable Docker images.

[tlaurion]

To-do : document under README.md with copy paste related commands

• "Going forward, I would recommend you build your container locally, taking note of the sha256 digest, then pushing to docker hub before creating a signed commit replacing the checksums in .circleci/config.yml."

So that next maintainer can reuse this knowledge.

[tlaurion]

Same idea implemented differently under #2036

@Tonux599 take a look