Terraform-provider-aws: 2.67 Checksum mismatch

Created on 22 Jun 2020  ·  13Comments  ·  Source: hashicorp/terraform-provider-aws

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

2020/06/22 12:19:20 [INFO] Terraform version: 0.12.26
2020/06/22 12:19:20 [INFO] Go runtime version: go1.12.13

  • provider.aws v2.66.0
  • provider.azurerm v2.15.0

Affected Resource(s)

All aws assets and resources within 2.67

Terraform Configuration Files

Able to replicate it with fresh tf install. Able to resolve the issue by forcing the aws provider version to 2.66

Debug Output


https://gist.github.com/zachgatesak/5a283317dbda49fd9c3f79ce4093c463

Expected Behavior


Init of the aws provider

Actual Behavior


Checksum failure

Steps to Reproduce

Fresh windows install of terraform for either chocolately or downloading the .exe directly. Create providers.tf files with a single line:
provider "aws" {}

  1. terraform init

Important Factoids

Issue goes away if specifying version 2.66

References

  • #0000
bug provider

Most helpful comment

Hello again, this issue should be resolved for Terraform AWS Provider v2.67.0 and was due to an internal release problem that caused the provider to be half released. The underlying release issue was resolved shortly after the problem was discovered and the provider release was re-published with no actual changes. It appears that some of the CDN caches were catching some older release files, which is the cause for this checksum mismatch issue.

Please reach out if this issue is not resolved as of June 22, 14:15 EDT.

All 13 comments

Hi folks 👋 Sorry you are running into trouble with this. The fix is being deployed currently and I will post an update when there is more information or in the next 30 minutes. Thanks.

Hello again, this issue should be resolved for Terraform AWS Provider v2.67.0 and was due to an internal release problem that caused the provider to be half released. The underlying release issue was resolved shortly after the problem was discovered and the provider release was re-published with no actual changes. It appears that some of the CDN caches were catching some older release files, which is the cause for this checksum mismatch issue.

Please reach out if this issue is not resolved as of June 22, 14:15 EDT.

Maybe release a dot 1 version to bump the CDN issue?
Re-releasing same version with different hash is a big no no and we already had similar issues in the past with hashi

I can verify that it is fixed from my side.

cat ~/Downloads/terraform-provider-aws_2.67.0_SHA256SUMS | grep linux_amd64
5d874f14004e3900ae386c2a94ff581aec898397d962f69448a2cf649e46b192  terraform-provider-aws_2.67.0_linux_amd64.zip
md5sum ~/Downloads/terraform-provider-aws_2.67.0_linux_amd64.zip 
aae0e9f6e8b38b1afd6670c276f652a2  ~/Downloads/terraform-provider-aws_2.67.0_linux_amd64.zip

I just try again, but still have the same issue.

Re-releasing same version with different hash is a big no no and we already had similar issues in the past with hashi

@FernandoMiguel According to the SHA256SUMS file (downloaded both before and after the issue), the SHA256 checksums of the binaries did not change.

I also tested by calculating the SHA256 checksums of the binaries themselves.

Before the issue:

$ sha256sum terraform-provider-aws_2.67.0_linux_amd64.zip 
5d874f14004e3900ae386c2a94ff581aec898397d962f69448a2cf649e46b192  terraform-provider-aws_2.67.0_linux_amd64.zip

After the issue:

$ sha256sum terraform-provider-aws_2.67.0_linux_amd64.zip 
5d874f14004e3900ae386c2a94ff581aec898397d962f69448a2cf649e46b192  terraform-provider-aws_2.67.0_linux_amd64.zip

@mouglou I believe you are looking for the MD5 checksum instead of the SHA256 checksum that the checksum file stores. To view the SHA256 checksum, you can use the shasum -a 256 command:

$ shasum -a 256 ~/Downloads/terraform-provider-aws_2.67.0_linux_amd64.zip
5d874f14004e3900ae386c2a94ff581aec898397d962f69448a2cf649e46b192  /Users/bflad/Downloads/terraform-provider-aws_2.67.0_linux_amd64.zip

Question - was the zip file damaged or was it modified?

@mouglou I believe you are looking for the MD5 checksum instead of the SHA256 checksum that the checksum file stores. To view the SHA256 checksum, you can use the shasum -a 256 command:

$ shasum -a 256 ~/Downloads/terraform-provider-aws_2.67.0_linux_amd64.zip
5d874f14004e3900ae386c2a94ff581aec898397d962f69448a2cf649e46b192  /Users/bflad/Downloads/terraform-provider-aws_2.67.0_linux_amd64.zip

My bad !! Your're right @bflad , sorry about that.
So I check, and yes, the update seems good for me.

@arnvid I was able to pull the raw build artifacts from the failed released and confirmed the binaries themselves are the same between the failed release and successful release, e.g. on darwin 64 bit:

shasum -a 256 ~/Downloads/terraform-provider-aws_v2.67.0_x4*
15303dfdb1e55005e47559799f5c38f5d8bbca517db42898172c9d637d5b8113  /Users/bflad/Downloads/terraform-provider-aws_v2.67.0_x4 # failed release
15303dfdb1e55005e47559799f5c38f5d8bbca517db42898172c9d637d5b8113  /Users/bflad/Downloads/terraform-provider-aws_v2.67.0_x4 2 # successful release

The checksum difference is only due to the updated zip timestamp:

$ zipinfo ~/Downloads/terraform-provider-aws_2.67.0_darwin_amd64.zip # failed release
Archive:  /Users/bflad/Downloads/terraform-provider-aws_2.67.0_darwin_amd64.zip
Zip file size: 39625480 bytes, number of entries: 1
-rwxr-xr-x  3.0 unx 188324656 bx defN 20-Jun-18 19:57 terraform-provider-aws_v2.67.0_x4
1 file, 188324656 bytes uncompressed, 39625264 bytes compressed:  79.0%
$ zipinfo ~/Downloads/terraform-provider-aws_2.67.0_darwin_amd64\ \(1\).zip # successful release
Archive:  /Users/bflad/Downloads/terraform-provider-aws_2.67.0_darwin_amd64 (1).zip
Zip file size: 39625480 bytes, number of entries: 1
-rwxr-xr-x  3.0 unx 188324656 bx defN 20-Jun-18 21:37 terraform-provider-aws_v2.67.0_x4
1 file, 188324656 bytes uncompressed, 39625264 bytes compressed:  79.0%

Given the particular place in the release process where it failed, it unfortunately left that small gap where releases.hashicorp.com contained files that were visible to Terraform 0.11 and earlier, any manual scripts pulling from there, and CDNs for caching with the older timestamped files in the zip and making the checksums slightly different than the newer release. Trying to re-release the old files may be error prone, so I do not believe we intend to cut a new release since the issue of incorrectly cached files was resolved and the binaries are the same. Otherwise, a new version of this project will be released on Thursday as part of our regular release cadence.

It is worth noting that as part of our next major version release process, we will no longer be publishing files to releases.hashicorp.com and instead solely to the Public Terraform Registry, which in of itself at some point in the future after that, will be based off published GitHub release assets for this codebase.

I'm still seeing this error:

Error: Checksums did not match for
Expected: 0278c861186aa156ee49865a18445cccbdfdabdba66963c0f943a656eee5d19a
Got: 5d874f14004e3900ae386c2a94ff581aec898397d962f69448a2cf649e46b192
*sha256.digest

Is it just a matter of waiting for the updated file to propagate?

Confirmed the issue is resolved over here:

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.aws: version = "~> 2.67"
* provider.azurerm: version = "~> 2.15"

Terraform has been successfully initialized!

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!

Was this page helpful?
0 / 5 - 0 ratings