gpg: signing failed: Inappropriate ioctl for device

[OJFord]

I mentioned this in a comment on closed issue: #201 (comment) but opening fresh as I've been unable to work around it, and perhaps the underlying cause is different.

https://github.com/OJFord/terraform-provider-wireguard/blob/fea1d2fcd9e1f90a2a6fe9dea220fb0fda35a311/.github/workflows/release.yml#L22-L36

The key is 4096-bit RSA, generated with a fresh GNUPGHOME and gpg --version 2.2.29, imported with ghaction-import-gpg@v4.1.0 and failing with this error in goreleaser-action@v2:

    ⨯ release failed after 414.87s error=sign: gpg failed: exit status 2: gpg: signing failed: Inappropriate ioctl for device
gpg: signing failed: Inappropriate ioctl for device

Error: The process '/opt/hostedtoolcache/goreleaser-action/0.183.0/x64/goreleaser' failed with exit code 1

I have tried exporting GPG_TTY= (blank) and adding no-tty to ~/.gnupg/gpg.conf, but no change.

[crazy-max]

@OJFord Are you able to repro with uses: crazy-max/ghaction-import-gpg@v3?:

      - name: Import GPG key
        id: import_gpg
        uses: crazy-max/ghaction-import-gpg@v3
        with:
          gpg-private-key: ${{ secrets.GPG_PRIVATE_KEY }}
          passphrase: ${{ secrets.PASSPHRASE }}

[OJFord]

@crazy-max I needed v4.1 since it's a signing key only.

[crazy-max]

@OJFord

I needed v4.1 since it's a signing key only.

Ok, fwiw it looks like the key is imported correctly: https://github.com/OJFord/terraform-provider-wireguard/runs/3999550316?check_suite_focus=true#step:4:32. I will try to repro with GoReleaser.

[OJFord]

Yup absolutely, not blaming ghaction-import-gpg, that's why I opened here 🙂. Thanks.

[crazy-max]

Ok seems to work fine with GoReleaser: https://github.com/goreleaser/goreleaser-action/runs/4262700166?check_suite_focus=true#step:6:83

So I would guess it's linked to your subkey. I will add some tests here with a subkey and try to repro with it.

[OJFord]

You have two keygrips there: https://github.com/goreleaser/goreleaser-action/runs/4262700166?check_suite_focus=true#step:4:39

suggests it's not just a signing key?

[OJFord]

Oh sorry think I misunderstood your comment. Yes, agreed.

[OJFord]

@crazy-max Any progress with this? I just tried changing the key to one with encryption too; (RSA4096) not just the signing key, and I get the same:
https://github.com/OJFord/terraform-provider-wireguard/runs/4803454647

[OJFord]

Perhaps 4096-bit RSA is what's common and somehow the problem? Is it worth trying EC, or lesser-bitted RSA?

[OJFord]

@OJFord Are you able to repro with uses: crazy-max/ghaction-import-gpg@v3?:

      - name: Import GPG key
        id: import_gpg
        uses: crazy-max/ghaction-import-gpg@v3
        with:
          gpg-private-key: ${{ secrets.GPG_PRIVATE_KEY }}
          passphrase: ${{ secrets.PASSPHRASE }}

(Having changed the key to not be signing-only, so that that isn't the problem) yes.

[OJFord]

This seems related to actions/runner#241? I don't understand why seemingly only I have this issue with goreleaser-action though!

[OJFord]

With pinentry-mode loopback in my ~/.gnupg/gpg.conf and allow-loopback-pinentry in gpg-agent.conf (and having subsequently reloaded gpg-agent), I get the same identified in #201:

release failed after 395.00s error=sign: gpg failed: exit status 2: gpg: Sorry, we are in batchmode - can't get input

But I'm not sure what the solution is, what input it's looking for - #201 was resolved by the author recreating the key, and then it just happened to work. I've tried multiple newly created keys and seen the same each time.

I've also tried regenerating a key with all defaults (in gpg v2.2.32) - RSA&RSA, 3072 bit, no expiry; with a different passphrase, this time with no special characters.

I'd appreciate any ideas, I'm at a bit of a loss; for now I think I'll just have to release outside of CI (i.e. with a tty).

[OJFord]

Feel silly for not thinking of this sooner, but creating the key without a passphrase seems to work around it successfully.

[crazy-max]

Was not able to repro on my side with a subkey only or not and also with or without a passphrase. I will add some tests like I said but so far no issue.

[mxab]

We're also facing this issue. removing the passphrase isn't something I feel comfortable with. Did anyone find another way yet?

[steve-r-west]

I figured something out, different sources use a different secret name for the passphrase.

Goreleaser and grazy-max/ghaction uses passphrase: `${{ secrets.PASSPHRASE }} in it's documentation, but ghaction-import-gpg which recently became deprecated (hashicorp/ghaction-import-gpg#11), uses the passphrase passphrase: ${{ secrets.GPG_PASSPHRASE }} specifically in the place where it tells you to switch in the README.md

So my guess is this error comes up if you are no longer reading an existing secret. Switching it back to PASSPHRASE fixed it for me.

[rschmied]

To provide an additional data point: This is my working GPG configuration:

      - name: Import GPG key
        id: import_gpg
        uses: crazy-max/ghaction-import-gpg@v5.2.0
        with:
          gpg_private_key: ${{ secrets.GPG_PRIVATE_KEY }}
          passphrase: ${{ secrets.GPG_PASSPHRASE }}

With the matching names in actions/secrets for the repository:

IMO, the name (GPG_PASSPHRASE) is irrelevant -- it could be WHATEVER as long as it matches on both ends, e.g. in the action and in the secrets store.

Btw, I've automated the storing (and removal) of secrets so that they are only put on Github for the duration it takes to build a release. When done, I'm having it removed again. This can be done with gh CLI, example in this script here. Since this is not my repo/key, the key/passphrase is not handled in this script -- but it illustrates how to do it with other temporarily stored secrets for release builds.

[jlec]

No passphrase works using the example, having a passphrase chocks at

- run: echo "foo" | gpg --sign --armour