Terraform rejects expired signatures when downloading providers through registry

[josemgom]

Terraform Version

terraform version
Terraform v1.6.0
on linux_amd64

### Terraform Configuration Files

```cat versions.tf
terraform {
  required_providers {
    bigip = {
      source = "f5networks/bigip"
    }
    phpipam = {
      source = "lord-kyron/phpipam"
    }
  }
  required_version = "< 2"
}

Debug Output

Initializing provider plugins...
- terraform.io/builtin/terraform is built in to Terraform
- Finding hashicorp/null versions matching "< 4.0.0"...
- Finding f5networks/bigip versions matching "< 2.0.0"...
- Finding lord-kyron/phpipam versions matching "< 1.4.0"...
- Finding hashicorp/dns versions matching "< 4.0.0"...
- Installing lord-kyron/phpipam v1.3.8...
- Installed lord-kyron/phpipam v1.3.8 (self-signed, key ID AFA614F0D7D39AB0)
- Installing hashicorp/dns v3.3.2...
- Installed hashicorp/dns v3.3.2 (signed by HashiCorp)
- Installing hashicorp/null v3.2.1...
- Installed hashicorp/null v3.2.1 (signed by HashiCorp)
- Installing f5networks/bigip v1.19.0...

Partner and community providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://www.terraform.io/docs/cli/plugins/signing.html
╷
│ Error: Failed to install provider
│
│ Error while installing f5networks/bigip v1.19.0: error checking signature: openpgp: key expired
╵

Expected Behavior

Terraform init must work as expected

Actual Behavior

Terraform init fails throwing a key expired error.

Steps to Reproduce

terraform init

Additional Context

No response

References

No response

[Zeneixe]

Same error with the Statuscake provider StatusCakeDev/terraform-provider-statuscake#150

[NyanKiyoshi]

Based on my investigations, this may have been caused by this commit 1fe57d4. It appears that terraform wasn't checking whether or not the PGP signature was expired when using golang.org/x/crypto/openpgp but github.com/ProtonMail/go-crypto may be doing it automatically on-behalf of terraform.

This may have been an accidental breaking change.

We can verify why statuscake mentioned-above is failing (#33984 (comment)):

$ curl https://registry.terraform.io/v1/providers/StatusCakeDev/statuscake/2.2.0/download/linux/amd64 | jq -r '.signing_keys.gpg_public_keys[0].ascii_armor' | gpg --show-keys -
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  4851    0  4851    0     0   2944      0 --:--:--  0:00:01 --:--:--  2948
pub   rsa4096 2021-01-28 [SC] [expired: 2022-01-28]
      A4FFCEB73654749457FCA6684E916C2959C4EAA9
uid                      StatusCake <developers@statuscake.com>
sub   rsa4096 2021-01-28 [E] [expired: 2022-01-28]

GPG says the key was expired on 2022-01-28 thus the maintainer would need to renew their key. Same issue appears here: cyrilgdn/terraform-provider-postgresql#357 (comment)

There is also this point at ProtonMail/go-crypto#21 (comment) that could relate to this issue:

Here's a current list of changes:

• [...]
• Detect expired signatures; though leaving it up to the caller whether they want to reject them

[apparentlymart]

Thanks for sharing that, @NyanKiyoshi. I agree that seems like a plausible explanation.

I think then we will have a decision to make about whether not having been checking those expirations before qualifies as a (retroactively-discovered) security problem that is now fixed per the security exception in our 1.x compatibility promises. To decide that I think we'll need to evaluate the risk tradeoff of continuing to allow expired keys.

If the decision is that we want to continue allowing expired keys for some transitional period to give time for provider developers to renew their keys then it seems like (from what you shared) it should be possible to do that.

Another possibility is for Terraform to check whether the key was expired at the time the provider was published, rather than at the time the provider is being installed. That seems the most pragmatic to me since these signatures are a point-in-time assertion made by the author when publishing and not something we expected folks to have to constantly redo. However, I'm not sure off the top of my head whether the provider registry protocol provides enough metadata to know when a provider was published, and indeed it might be wrong for Terraform CLI to trust the registry about when the publication happened.

I think to decide what's best here we'll need to seek advice from our product security team. We'll post more updates once we have a clearer idea of what the situation is and what options are available.

Thanks again!

[marcispauls]

by security best practices - the software (in this case terraform provider) developer should take care of his code including dependencies and including to keep them up2date. if some of software package dependencies are not kept up2date it means the software vendor should replace the dependency with safer and with dependency which follows security best practices.