build: Pin docker images with SHA instead of tag.

[naveensrinivasan]

• Pinned the docker images to be based on SHA instead of tags.
• https://github.com/ossf/scorecard/blob/main/docs/checks.md#pinned-dependencies
• Tags can be moved which poses a security risk.

[davecgh]

Thanks for the PR. I commented inline, but these hashes don't match the official images for me.

[davecgh]

Confirmed hashes.

Please use rebase to squash the two commits into a single commit and make the title match the one in the PR per the code contribution guidelines for commit messages.

---

As a bit of an aside, I am aware using hashes is generally the recommendation and therefore I'm fine with accepting this, but honestly, I'm not really convinced it's all that great of a recommendation in general.

I completely understand the potential security issue, since the tag could be changed, but it comes at the expense of being limited to a single architecture per Dockerfile (amd64 in this case) and is also potentially worse for security in the sense it means you are no longer getting the latest versions with security patches applied unless you happen to notice and/or go check every day for updates manually.

So, which one is actually a bigger threat though? Dockerhub being compromised and having an image changed right before someone pulls or almost positively running out of date software that likely has security vulnerabilities in it?

This, among several other reasons, are a big part of why I never use docker personally.

[naveensrinivasan]

Confirmed hashes.

Please use rebase to squash the two commits into a single commit and make the title match the one in the PR per the code contribution guidelines for commit messages.

I will squash the commits.

As a bit of an aside, I am aware using hashes is generally the recommendation and therefore I'm fine with accepting this, but honestly, I'm not really convinced it's all that great of a recommendation in general.

I completely understand the potential security issue, since the tag could be changed, but it comes at the expense of being limited to a single architecture per Dockerfile (amd64 in this case) and is also potentially worse for security in the sense it means you are no longer getting the latest versions with security patches applied unless you happen to notice and/or go check every day for updates manually.

The upgrades of these shouldn't be an issue if https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/about-dependabot-version-updates is enabled in the repository.

Dependabot is aware of these hashes and would upgrade to the latest version of the hash.

This is a practice for avoiding supply chain attacks. Supply chain attacks are the low hanging fruits when compromised can have a large impact.

On a different note why not enable dependabot for getting security updates?

So, which one is actually a bigger threat though? Dockerhub being compromised and having an image changed right before someone pulls or almost positively running out of date software that likely has security vulnerabilities in it?

This, among several other reasons, are a big part of why I never use docker personally.

[davecgh]

Dependabot is aware of these hashes and would upgrade to the latest version of the hash.

Good to know, I wasn't aware it worked with Docker images. I thought it was aimed more at node.js since that is where I have seen all of the notifications from other repos.

On a different note why not enable dependabot for getting security updates?

Some of the repositories that are less critical have it enabled. For dcrd though, our security policy is that every dependency update for the main process (I plan to move Docker stuff to the contrib folder in the future because it falls outside of that) must be manually reviewed. That includes all of the commits in the dependency and any of its dependencies, etc. Letting 3rd-party applications, such as dependabot, make changes to the code automatically is a no go since that would make all code in the repository vulnerable if that 3rd-party application were to be compromised.

That said, I think it's possible to enable it without giving permission to change code so it can notify, but not automatically update. That would be worth doing and is a good suggestion.

EDIT: Actually I see dependabot alerts are already enabled for the repo.

[naveensrinivasan]

Dependabot is aware of these hashes and would upgrade to the latest version of the hash.

Good to know, I wasn't aware it worked with Docker images. I thought it was aimed more at node.js since that is where I have seen all of the notifications from other repos.

On a different note why not enable dependabot for getting security updates?

Some of the repositories that are less critical have it enabled. For dcrd though, our security policy is that every dependency update for the main process (I plan to move Docker stuff to the contrib folder in the future because it falls outside of that) must be manually reviewed. Letting 3rd-party applications, such as dependabot, make changes to the code automatically is a no go since that would make all code in the repository vulnerable if that 3rd-party application were to be compromised.

That said, I think it's possible to enable it without giving permission to change code so it can notify, but not automatically update. That would be worth doing and is a good suggestion.

Dependabot opens a PR and it gives an option to verify changes. Also, dependabot notifies on security vulnerability only to repo owners.

[naveensrinivasan]

Squashed my commits into a single commit.