gpg: signing failed: Inappropriate ioctl for device

[tbhb]

In attempting to use the GPG signing functionality as documented with the use of crazy-max/ghaction-import-gpg I can't seem to find a way around the following error when GoReleaser gets to the signing pipe:

      • signing                   cmd=[gpg --batch -u BF9DE7B4E2AD83A41CFD7713280CAB053A042287 --output dist/protomy-v0.0.0-SNAPSHOT-c05f10f-checksums.txt.sig --detach-sign dist/protomy-v0.0.0-SNAPSHOT-c05f10f-checksums.txt]
      • gpg: signing failed: Inappropriate ioctl for device

(See here for the full action log)

I've been comparing back and forth between my own GitHub workflow configuration and the one in use by this repository's own CI workflow, but can't seem to spot any differences between the two that could lead to this error, which has been confounding given that the CI workflow for goreleaser/gorelease-action itself is passing, with virtually the same configuration other than the key itself.

Seems as though there's been a similar issue referenced elsewhere in actions/runner#241 (comment) but again that would be confusing given that the workflow is passing in the GoReleaser action's own tests 😄

[crazy-max]

Hi @craftyphotons, this is because you export GPG_TTY. Remove this step and it should be ok.

[tbhb]

Unfortunately it's still occurring even with that step removed: https://github.com/protomy/protomy/runs/690511183

[crazy-max]

Ok how do you export your GPG key? Do you follow the Prerequesites?
This should look like this

[tbhb]

Yep! I even re-followed everything just now to be sure, and reuploaded secrets with the keys GPG_PRIVATE_KEY and PASSPHRASE instead of the names I formerly had for them.

https://github.com/protomy/protomy/runs/690545899

I included an additional step as you show in the documentation to echo out the GPG key/user information to verify that the gpg import action is working appropriately.

The only difference I can ascertain at this point is that your build from a couple days ago ran against version 20200430.1 of ubuntu-latest and mine is running against 20200512.2, so perhaps there was some sort of regression there in GitHub's Ubuntu environment.

I'm also getting the error on macos-latest though: https://github.com/protomy/protomy/runs/690567394

[crazy-max]

I re-run our CI workflow and everything works fine.
I will take a closer look on this but this is maybe a pinentry-mode issue. Keep you in touch.

[tbhb]

Thanks @crazy-max — definitely must be something with my key then. I'll dig into it from my side some more and see if I can narrow things down more.

[crazy-max]

@craftyphotons Can you test with uses: crazy-max/ghaction-import-gpg@pinentry-loopback ?

[tbhb]

[tbhb]

FWIW I just took a look at that branch and looks like you're doing the same thing that I attempted a bit ago:

(The OK in the output of the first step is from me bouncing the GPG agent)

Which unfortunately still yielded the same result.

[crazy-max]

@craftyphotons Ok thanks for your feedback. I've made some new changes, can you try it? (with uses: crazy-max/ghaction-import-gpg@pinentry-loopback)

[tbhb]

No dice still but something different this time!

[crazy-max]

Ok this is what I tought. It looks like your GPG key requires a special input which is not allowed in batch mode. Could you give me more information on how you created the key? In particular the version of GnuPG.

Can you also try creating a key following those steps of GitHub.

[tbhb]

I think I just came to the same conclusion myself by creating a new key here on my laptop, which worked.

However now the mystery deepens, as the non-working key was created on a different machine with the same procedure and the same gpg.conf!

Here's the gpg.conf that's on both machines:

# Avoid information leaked
no-emit-version
no-comments
export-options export-minimal

# Displays the long format of the ID of the keys and their fingerprints
keyid-format 0xlong
with-fingerprint

# Displays the validity of the keys
list-options show-uid-validity
verify-options show-uid-validity

# Limits the algorithms used
personal-cipher-preferences AES256
personal-digest-preferences SHA512
default-preference-list SHA512 SHA384 SHA256 RIPEMD160 AES256 TWOFISH BLOWFISH ZLIB BZIP2 ZIP Uncompressed

cipher-algo AES256
digest-algo SHA512
cert-digest-algo SHA512
compress-algo ZLIB

disable-cipher-algo 3DES
weak-digest SHA1

s2k-cipher-algo AES256
s2k-digest-algo SHA512
s2k-mode 3
s2k-count 65011712

Both machines are also running gpg 2.2.17.

In any case though, sounds like I'm probably an odd edge case here... I'll keep trying to determine how the key on the other machine might be different though and let you know if I find anything.

Thanks a lot for spending the time to help me track this down!

[crazy-max]

Thanks, don't hesitate to come back to me, I close this issue in the meantime.

[StephenWithPH]

I'm throwing a breadcrumb here for future searchers... a key generated with GPG2 gave me the same error. Using a key generated by GPG1 worked just fine. actions/runner#241 (comment) was helpful in figuring this out.

[OJFord]

@crazy-max I have the same issue with an RSA 4096 bit signing key generated with GNUPGHOME="$(mktemp -d)" gpg; where gpg --version is 2.2.29, using [email protected] and goreleaser-action@v2.