[Bug]: v5.71.0: archive has incorrect │ checksum

[tanayagrawa1]

Terraform Core Version

1.8.5

AWS Provider Version

5.71.0

Affected Resource(s)

No response

Expected Behavior

pass

Actual Behavior

│ Error: Failed to install provider
│ 
│ Error while installing hashicorp/aws v5.71.0: archive has incorrect
│ checksum
│ zh:e746662547a839b0344729783bb57bdf6899f78d3de19e545d58d0acff9567c4
│ (expected
│ zh:c164d3ed13eb4c28ac243221591fc4ac3cfe621f8cd20af533dedd98a6387363)

Relevant Error/Panic Output Snippet

No response

Terraform Configuration Files

skip

Steps to Reproduce

install provider

Debug Output

No response

Panic Output

No response

Important Factoids

No response

References

No response

Would you like to implement a fix?

None

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• 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.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[odcheck]

│ Error: Failed to install provider│ │ Error while installing hashicorp/aws v5.71.0: archive has incorrect│ checksum│ zh:21f5d77f2859d9ddb5fafa7b6cfd0efdf82977c631ce788e56728afc6da17323│ (expected│ zh:c164d3ed13eb4c28ac243221591fc4ac3cfe621f8cd20af533dedd98a6387363)

quick-fix

    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.45, != 5.71.0"
    }

[joelrozen-bbm]

This issue is intermittent for us - we have ~ 10 CI pipelines, they started producing this error on terraform init this morning, seems that re-running them a few times they will pass and download 5.71 successfully and other times throw the checksum error.

[gurupreet18121990]

Hello Team,
Even I am facing the similar issue at present.

09:58:11 │ Error: Failed to install provider
09:58:11 │
09:58:11 │ Error while installing hashicorp/aws v5.71.0: archive has incorrect
09:58:11 │ checksum
09:58:11 │ zh:e746662547a839b0344729783bb57bdf6899f78d3de19e545d58d0acff9567c4
09:58:11 │ (expected
09:58:11 │ zh:c164d3ed13eb4c28ac243221591fc4ac3cfe621f8cd20af533dedd98a6387363)
09:58:11 ╵

As a workaround, I am locking the version to 5.70.0 in my provider file.
required_providers {
aws = {
source = "hashicorp/aws"
#version = ">= 3.28"
version = "= 5.70.0"
}
}
}

[XinRanZhAWS]

+1, with same wrong checksum, but some time correct

[nitinjain999]

`Error: Failed to install provider

Error while installing hashicorp/aws v5.71.0: archive has incorrect checksum
zh:e746662547a839b0344729783bb57bdf6899f78d3de19e545d58d0acff9567c4 (expected
zh:c164d3ed13eb4c28ac243221591fc4ac3cfe621f8cd20af533dedd98a6387363)`

[jeremychauvet]

It seems the tag 5.71.0 has been overridden 2 times, which may explain the checksum issue 🔽

[Guillaume-Alexandre]

Hello 👋🏼 Running a terraform init -upgrade should help.

It does not work here ... Still the same issue.

However this :

quick-fix

    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.45, != 5.71.0"
    }

is a good workaround while waiting for the issue to be fixed.

[kevineor]

The github action looks to have published a version without publish SHA256SUMS
https://github.com/hashicorp/terraform-provider-aws/actions/runs/11282276110/job/31380943498
It have been retried but maybe the terraform registry does still point to the previous provider uploaded

[andrazjelenc]

The problem is only with provider for linux amd64 architecture, for other architectures the checksums look fine.

[wmenant]

Tested by adding version = "= 5.70.0" as provided by @gurupreet18121990 and it seems to work on Ubuntu 22.04

[sunitha8687]

We have linux/amd64 and tried the workaround suggested above and i still get followup error:

    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.45, != 5.71.0"
    }

[ericbl]

The workaround to force the previous version is working fine for us.
We added a terraform.tf file containing the following along our other tf files, and our ci/cd pipeline job is now ok.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "= 5.70.0"
    }
  }
}

but I don't want to add this in our 20+ repos, so hope for a real fix asap.

[edmundcraske-bjss]

We have linux/amd64 and tried the workaround suggested above and i still get followup error:

    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.45, != 5.71.0"
    }

@sunitha8687 I think you've added it to your provider definition, rather than to your terraform required_providers (as per https://developer.hashicorp.com/terraform/language/providers/requirements)?

[asktushar]

Can anyone confirm if there is any ETA for this fix, I don't want to change all the repos in the company.

[MattBlack85]

we have everything blocked, if anyone needs a shortcut and, as us, was using the ~> versions, here a oneliner to replace it everywhere

grep -rl "~> X.X" your/path | xargs sed -i "s/~> X.X/= 5.70.0/g"

[sap147]

This is causing issues for us as well.

[joehainess]

Can we please get an update on the status of this @ewbankkit? This has been blocking us all day and implementing the workaround to avoid v5.71.0 in every one of our modules is ridiculous.

Even if a simple re-release is done to bump to 5.71.1 so that the latest version is able to install.

[rusekjf]

Hello @austinvalle, is there any update on this bug resolution? Thanks!

[DanielCastronovo]

it's seems to be fixed 💚

[gurupreet18121990]

the issue has been fixed.
19:24:24 - Installing hashicorp/aws v5.71.0...
19:24:30 - Installed hashicorp/aws v5.71.0 (signed by HashiCorp)
19:24:30 - Installing hashicorp/random v3.6.3...
19:24:30 - Installed hashicorp/random v3.6.3 (signed by HashiCorp)

[ymd-xxx]

This have been fixed! :)

[anneadb]

Is the version gone entirely now?

[justinretzolk]

Hey everyone 👋 Thank you very much for taking the time to raise this, and for adding reactions to help ensure it was brought to our attention -- that's extremely helpful. We ran into an issue with our release process that led to this, and so have pulled the 5.71.0 release to resolve the immediate issue. We're working through the release issue internally, and will make a new release once we're confident that it has been resolved.

Since the issue reported here has been resolved, I'm going to close this issue out. Thank you again to all who reported -- if you run into issues in the future, please do continue to let us know!

[github-actions]

Warning

This issue has been closed, meaning that any additional comments are hard for our team to see. Please assume that the maintainers will not see them.

Ongoing conversations amongst community members are welcome, however, the issue will be locked after 30 days. Moving conversations to another venue, such as the AWS Provider forum, is recommended. If you have additional concerns, please open a new issue, referencing this one where needed.

[rsi-mrobinson]

anyone else still running into issues like this? Updating my lock files I see

│ Error: Could not retrieve providers for locking
│ 
│ Terraform failed to fetch the requested providers for darwin_amd64 in order to calculate their checksums: some providers could not be installed:
│ - registry.terraform.io/hashicorp/aws: the previously-selected version 5.71.0 is no longer available.

Still need the workaround provided above to resolve this.

[lordmat0]

@justinretzolk

Doesn't this go against best practices of deleting versions and instead a new version should be released that rolls back the changes?

Unsure if something like renovate bot can handle removing a version.

[jithinjose2004]

@justinretzolk

Doesn't this go against best practices of deleting versions and instead a new version should be released that rolls back the changes?

Unsure if something like renovate bot can handle removing a version.

yes

Error: Resource instance managed by newer provider version
│
│ The current state of
│ module.****** was
│ created by a newer provider version than is currently selected. Upgrade the
│ aws provider to work with this state.

[jithinjose2004]

@justinretzolk are we going to release a new version anytime soon ?

[justinretzolk]

@jithinjose2004 thanks for checking in here. We plan on releasing version 5.72.0 on Thursday morning (October 17th), and have updated the changelog to reflect this.

As far as the best practice of not deleting a version, and instead releasing a new version that rolls back the changes -- in this case, that wasn't really an option. The issue wasn't that there was a particularly offensive bug in the provider; rather that an issue with the release process caused issues with the release itself. Leaving the broken release up would mean that anyone who attempted to install it (most without the context of this GitHub Issue) would receive checksum errors, and never be able to install the release at all. Many people opt not to pin provider versions and so would not be able to use the provider without updating their configurations to explicitly pin a lower version. Queue the influx of high-severity support cases.

The natural next question is as to why we didn't release a new version immediately. Before we could do so, we needed to resolve the issues with the release process -- something we didn't feel we could guarantee on a Friday before a long weekend (half of our team is in Canada, where today is a national holiday). Compounding the difficulty of releasing a new version as quickly as possible, HashiConf, our annual conference is this week. With all of those factors in mind, Thursday was the soonest that we were able to get the next release scheduled for. I hope that information helps to give a bit more context as to why we are where we are.

[github-actions]

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.