Registry docs fail to specify that GPG1 is necessary.
StephenWithPH opened this issue · 3 comments
Having followed the docs at https://github.com/hashicorp/terraform-website/blob/master/content/source/docs/registry/providers/publishing.html.md and copied the example GitHub Actions and goreleaser config files, I received the following error in the GitHub Action:
gpg: signing failed: Inappropriate ioctl for device
Some digging led me to:
Based on some hints in those issues that the GPG version matters, I replaced the key created using GnuPG2 (the default on most systems) with one created using GnuPG1, and the problem went away.
Given this behavior could arise from the version of the runner, several of the helper actions, or something in goreleaser, it's probably more user-friendly to hint to Terraform Registry users that they may have more luck with a GPG1-generated key.
Would you accept a PR adding this hint to the docs?
Hi @StephenWithPH, I'm one of the developers on the Terraform Registry. Thanks for reporting this issue, and I'm sorry for the long delay in responding. GPG 2 keys shouldn't be a problem for signing artifacts. I don't think we want to encourage people to use GPG 1 by default because as you mentioned, most systems default to GPG 2 (e.g. brew install gpg is going to install GPG 2).
That being said, if there's a specific gotcha around key creation/usage, that could be worth calling out in the docs. What key type/bit size did you use for your GPG 2 key? It also might be worth pulling in the latest version of the release manifest from the scaffolding repo as well to see if that resolves any issues.
@jbonhag, enough time has passed that I'm not going to rely on my memory for the details. I'm pretty sure I naively followed the tutorial and ended up with the error.
I suspect the problem is/was really in the GitHub Actions' runner's environment (no TTY). If lots of people doing your tutorial are still being bitten by this, I'm sure it will cross your radar again.
FYI I ran into the same problem during a recent rotation of our GPG key and concluded this was caused by password-encrypted key which I assumed was not encrypted (hence GPG was asking for the password via TTY).
Sadly that GPG error message doesn't make that obvious at all.
One solution is to provide unencrypted key. Assuming you'd store the password in the same place (such as GitHub Secret) as the key itself both would be subject to the same risk profile anyway, so seems to be little benefit to using encrypted key.