Release signing key expired - unable to use the provider

[wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf]

Describe the bug It appears the GPG key used to sign the release(s) expired, which makes the releases unusable, it would appear.. I am not a TF guru, so if there's a (safe) way to work around this, I am in.

To Reproduce (Re-)initialise the provider with terraform init/terraform init -reconfigure.

Expected behavior The provider initialisation should complete without errors about key being expired.

Log Output pic-or-it-didn't-happen:

• Terraform Version

  Terraform v1.6.0-alpha20230719
  on linux_amd64

• Operating System Fedora 38

• Provider Version v0.16.0, tried with v0.15.0 but they were apparently signed with the same key, so I got the same error...

[Lerentis]

Hi @wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf ,

i updated my pgp key in april this year as it was close to expiery. you may want to refresh your local keychain in order to get an updated one: gpg --refresh-keys.

[wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf]

minor EDIT: enclose words in brackets

thanks for the answer @Lerentis. I've tried that (refreshing the keychain).

btw, I have checked <your-github-handle.gpg yesterday and imported the key and it showed as expired.

also, I suspect it's Terraform the CLI tool or the webserver that's checking the signature of the (provider) package, I don't suppose it uses my local gpg keychain.

is it possible that while you did update your key back in april, your gpg still defaulted to using the old key when signing the release(s)?

one argument that would support that claim is that even the *_SHA256SUMS signature asset enclosed in the latest release was signed with the now-expired key, as can be seen in the picture:

i.e. the signature is valid, but the key used is expired according to gpg

if that's the case with the provider file, too, TF CLI might be handling that ungracefully, as we might have seen in the OP.

regardless, the attempted import still results in the same failure.

[Lerentis]

Hmm i am rather sure that i updated the key in github actions as well as goreleaser refuses to sign anything with an exired key. lets use a clean environment to debug this. this is my test setup as of now:

FROM ubuntu:22.04

RUN apt-get update && apt-get install -y software-properties-common gnupg2 curl wget vim

RUN wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
RUN echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | tee /etc/apt/sources.list.d/hashicorp.list
RUN apt update && apt install terraform -y

ENTRYPOINT [ "/bin/bash" ]

building the test image and running it:

docker build -t test .
docker run -it --rm test

content of test.tf:

terraform {
  required_providers {
    gitea = {
      source = "lerentis/gitea"
      version = "0.16.0"
    }
  }
}

inside the container:

root@43d3bc58fb44:/# cd tmp/
root@43d3bc58fb44:/tmp# vim test.tf
root@43d3bc58fb44:/tmp# terraform init

output:

Initializing the backend...

Initializing provider plugins...
- Finding lerentis/gitea versions matching "0.16.0"...
- Installing lerentis/gitea v0.16.0...
- Installed lerentis/gitea v0.16.0 (self-signed, key ID FF0C2839718CAF2E)

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

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

can you try to reproduce this in this environment? i fail to reproduce this on multiple systems as of now :/

[wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf]

hey @Lerentis, thanks for the response. I see, that's weird then.

I did try to recreate the environment as per what you suggested (only I didn't build the image but ran the commands - in a podman-run ubuntu:22.04 - directly..and the results were exactly as yours!

I even tried installing TF on my box using asdf (the version that is used in ubuntu:22.04 - v1.5.4), but the init still fails to finish with the same error..

I'll try to experiment with this on Arch, or Fedora in a container, curious how that works out honestly...

[wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf]

alight I got the provider working by - wait for it - copying both the .terraform.lock.hcl part for the Gitea provider and the provider folder itself from .terraform/.../lerentis/gitea in the container to the host.

I simply ran terraform init on the barebones test.tf from above, with a host directory bind-mounted into the container. I then manually copied the mentioned files over to my original project...once there, apparently TF doesn't mind whatever it did before and happily accepts them. no complains about expired gpg keys, the provider is present and so are its hashes in the lock file so it apparently viewes it as cached and leaves all the checks be..

I was even able to create a test repository, so once the init is done, it all appears to work fine..

I somehow suspect Fedora (SELinux?) to be complicit in all of this, all worked fine on Arch and Ubuntu.. I might do some more Fedora (container+bare metal) tests tomorrow..

I reckon this issue can be closed, as there is this weird workaround now... :thinking:

thanks for all the help @Lerentis

[Lerentis]

As this seems rather related to one specific system i am going to close this issue. thanks for the responsiveness 😃

[wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf]

thank you! also, I am rather happy it works on other systems or even on mine, when kicked hard enough... :))