Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Thank you for checking and pinpointing the issue. So it turns out that there is a simple workaround:
$ gpg2 --import --batch < admin.asc
or to install pinentry package. With the pinentry installed, also the following syntax works for me just fine, but asks for passphrase using pinentry-curses prompt:
$ gpg2 --import ../admin_secure.asc
The original import without --batch and with stdin occupied by the input was unexpectedly failing, is probably a bug in everything newer than RHEL8, but I do not think of very high priority as we have reasonable workarounds on table.
I believe the gnupg can import the encrypted secret key without asking for passphrase and unlock it only when it will be needed, but it when it asks for passphrase, it can probably process more information from the key or run some checks. The options are:
* the secret key import should not ask for passphrase ever
* it should ask, but if it fails, fail more gracefully
Running with more debug information we can see what leads to this issue. The gnupg spawns gpg-agent to import the key and that one asks for the passphrase:
$ gpg2 --debug-all --import < ../admin_secure.asc
[...]
gpg: DBG: chan_4 -> KEYWRAP_KEY --import
gpg: DBG: chan_4 <- [ 44 20 d3 97 5b 78 26 32 e0 c1 6d 7f 5d e8 b5 fc ...(2 byte(s) skipped) ]
gpg: DBG: chan_4 <- OK
gpg: DBG: chan_4 -> SETKEYDESC Please+enter+the+passphrase+to+import+the+OpenPGP+secret+key:%0A%22admin%22%0A2048-bit+RSA+key,+ID+5837CBC0332DDAE9,%0Acreated+2022-03-18.%0A
gpg: DBG: chan_4 <- OK
gpg: DBG: chan_4 -> IMPORT_KEY
gpg: DBG: chan_4 <- INQUIRE KEYDATA
gpg: DBG: chan_4 -> [ 44 20 e9 9e ee c4 45 17 1f 68 d5 54 ba 0b ea 80 ...(982 byte(s) skipped) ]
gpg: DBG: chan_4 -> [ 44 20 6d 88 da fc 2c be 1a fb 7e 1a bf a0 c6 65 ...(122 byte(s) skipped) ]
gpg: DBG: chan_4 -> END
gpg: DBG: chan_4 <- INQUIRE PINENTRY_LAUNCHED 8133 curses 1.1.0 - xterm-256color -
gpg: DBG: chan_4 -> END
gpg: DBG: chan_4 <- ERR 83918950 Inappropriate ioctl for device <Pinentry>
gpg: key 5837CBC0332DDAE9/5837CBC0332DDAE9: error sending to agent: Inappropriate ioctl for device
gpg: error building skey array: Inappropriate ioctl for device
This points me deep into the code to the function agent_import_key(), which already takes argument and passes to the agent if the import should be unattended or not.
So I think the gnupg2 shoud check that for the secret key import the file does not come from stdin. Filled https://dev.gnupg.org/T5885
FYI, setting
GPG_TTY=$(tty)
export GPG_TTY
before calling the import should solve the issue.
But I am still in contact with upstream if we can improve the error message somehow so it is easier for customers to migrate from older versions of gnupg to newer ones.