Use of sha1sum in official image Dockerfiles should be replaced with use of a stronger digest function

[briansmith]

See https://github.com/search?q=org%3Adocker-library+sha1sum&type=Code, which shows a lot of Dockerfiles are checking the integrity of packages with sha1sum.

We could speculate on how easy it would be to send an open source project a patch that gets merged that would enable a SHA-1 collision that would result in something bad happening to somebody, but let's not.

Instead, I suggest that the guidelines for Dockerfile authors should be updated to explicitly say that SHA-256 or SHA-384 should be used to verify file integrity, instead of sha1sum. And then, if there is some way of doing so, it would be good to contact current Dockerfile authors and ask them to update their scripts.

[yosifkit]

We would love to do this but we can only use what upstream releases. I looked at a few and here is what I found:

• wordpress; upstream only offers the sha1 file and no other verification options. It is downloaded in update.sh and then embedded in the Dockerfile.
• haproxy: sha1 is used for the Lua download since that is all Lua provides (they do have md5 🤣), but we are looking to swap to the alpine packaging of Lua: Use lua from system package haproxy#61
• tomcat uses both the upstream provided sha1 as well as the detached gpg signature (.asc)
• elasticsearch and logstash: in the alpine based images we use both the upstream provided sha1 as well as the upstream provided detached gpg signature (if both are available). The sha1 is just a quick check to ensure all the bits are downloaded before checking the signature. (these images are deprecated and should be consumed from elastic.co)

So we would really need to talk to the release team of each upstream project to convince them to release more secure hashes. If there are some projects that now have a better hash we would gladly accept a PR to improve them.

[briansmith]

At https://github.com/docker-library/official-images#security, the example already uses SHA-256, so that's good. I suggest that the documentation be amended slightly to explicitly call out that SHA-256 or better be used and that SHA-1 and MD5 shouldn't be used.

So we would really need to talk to the release team of each upstream project to convince them to release more secure hashes.

I agree. I think that having the documentation explicitly recommending a more secure hash would be a good step in convincing them. Then people can open PRs in those projects pointing to that part of the documentation as evidence that the change is important.