Allow plugin version to be specified as SHA-1 hash

[morancj]

Introduction

Allow plugin version to be specified as commit hash, as well as tag. Similar to pinning GitHub Actions versions to a commit.

Proposal

For example, instead of

plugin "aws" {
  enabled = true
  version = "0.16.0"
  source  = "github.com/terraform-linters/tflint-ruleset-aws"
}

I'd like to be able to use version = "fa6372da4fafa89fdc1052d966742a070a716725".

plugin "aws" {
  enabled = true
  version = "fa6372da4fafa89fdc1052d966742a070a716725"  # "0.16.0"
  source  = "github.com/terraform-linters/tflint-ruleset-aws"
}

References

https://michaelheap.com/ensure-github-actions-pinned-sha/
https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions

[bendrucker]

Verification is currently provided via a signing_key:

https://github.com/terraform-linters/tflint/blob/master/docs/user-guide/plugins.md#signing_key

In theory we could also provide the ability to set a checksum directly rather than trusting the one in the GitHub release.

0.16.0 refers to a release via a tag. It is the release that contains the built artifacts (compressed binaries, checksums).

In GitHub Actions, the content is stored directly in git, rather than as release artifacts. Git provides built-in immutable identifiers for all content (commit SHAs). Releases are inherently mutable and can be referenced by ID or tag only. It's not possible to refer to releases by a commit SHA.

[wata727]

Maybe we need a dependency lockfile like terraform.lock.hcl?

[bendrucker]

Yeah I'd agree that's the right solution. Finding and pasting checksums is a poor user experience and in practice leads most people opt out of integrity checking. Lock files make integrity checking part of the default workflow.

[wata727]

Opened #1634 for the introduction of dependency lockfile. Closing this issue.