Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gpg: signing failed: Inappropriate ioctl for device #313

Open
OJFord opened this issue Oct 25, 2021 · 18 comments
Open

gpg: signing failed: Inappropriate ioctl for device #313

OJFord opened this issue Oct 25, 2021 · 18 comments

Comments

@OJFord
Copy link

OJFord commented Oct 25, 2021

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
Copy link
Member

crazy-max commented Nov 19, 2021

@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
Copy link
Author

OJFord commented Nov 19, 2021

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

@crazy-max
Copy link
Member

@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
Copy link
Author

OJFord commented Nov 19, 2021

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

@crazy-max
Copy link
Member

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
Copy link
Author

OJFord commented Nov 19, 2021

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
Copy link
Author

OJFord commented Nov 19, 2021

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

@OJFord
Copy link
Author

OJFord commented Jan 13, 2022

@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
Copy link
Author

OJFord commented Jan 13, 2022

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

@OJFord
Copy link
Author

OJFord commented Jan 13, 2022

@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
Copy link
Author

OJFord commented Jan 24, 2022

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

@OJFord
Copy link
Author

OJFord commented Jan 24, 2022

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
Copy link
Author

OJFord commented Feb 3, 2022

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

OJFord added a commit to OJFord/terraform-provider-wireguard that referenced this issue Feb 3, 2022
Cf. goreleaser/goreleaser-action#313.

I'm not sure why it's not working, but removing the passphrase seems to
work as a workaround.

Key created with
```
gpg --batch --generate-key <(echo '
Key-Type: default
Subkey-Type: default
Name-Real: ...
Name-Comment: ...
Name-Email: ...
Expire-Date: 0
%no-ask-passphrase
%no-protection
%commit
')
```
@crazy-max
Copy link
Member

crazy-max commented Feb 21, 2022

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
Copy link

mxab commented Aug 4, 2022

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
Copy link

steve-r-west commented Aug 10, 2022

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.

bryanmaclean added a commit to cohesive/terraform-provider-cohesivenet that referenced this issue Oct 17, 2022
@rschmied
Copy link

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
Copy link

jlec commented Jan 3, 2023

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants