[gentoo-dev] gpg: signing failed: Inappropriate ioctl for device

[gro...@gentoo.org]

Hello *,

Today, when trying to push my commit to the repo, I got

gpg: signing failed: Inappropriate ioctl for device
gpg: signing failed: Inappropriate ioctl for device
error: gpg failed to sign the data
fatal: failed to sign the push certificate
fatal: The remote end hung up unexpectedly

When I did repoman commit, it did not ask me to type my passphraise,
because I did another commit not so long ago (and successfully pushed it
to Gentoo). But this commit sits in my copy of the tree, and I cannot push
it. What can I do?

Thanks in advance,
Andrey

[Thomas Deutschmann]

On 2016-12-11 15:13, gro...@gentoo.org wrote:
> But this commit sits in my copy of the tree, and I cannot
> push it. What can I do?

You can't push because the commit isn't signed?

If it is the last commit, just run `git commit --amend -S`

If it isn't the last commit, try `git log` to get the commit id before
your unsinged commit followed by `git rebase -i
<COMMITID_BEFORE_YOUR_UNSINGED_COMMIT>^`. Now set the unsigned commit to
"EDIT" (don't touch any other commits, keep "PICK") and run `git commit
--amend -S` and continue rebase to finish.

Now your commit should be signed and you should be able to push.

For future, apply settings like shown in
https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Repository_settings to
the Gentoo repository to prevent situations like that.


--
Regards,
Thomas

[Kristian Fiskerstrand]

On 12/11/2016 03:13 PM, gro...@gentoo.org wrote:
> gpg: signing failed: Inappropriate ioctl for device

this might indicate a want for export GPG_TTY=$(tty)


--
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

[gro...@gentoo.org]

On Sun, 11 Dec 2016, Kristian Fiskerstrand wrote:
> On 12/11/2016 03:13 PM, gro...@gentoo.org wrote:
>> gpg: signing failed: Inappropriate ioctl for device
> this might indicate a want for export GPG_TTY=$(tty)

I don't understand what has really happened. I removed my last commit, an
attempt to commit it again failed with gpg: signing failed. Then I logged
out of the box on which I have the git tree (I log in this box via ssh),
and logged in again. After that the commit succeeded.

Thanks,
Andrey

[Sam Jorna]

I was also getting some odd issues with commit signing, though it seemed
to settle for me when I switched to pinentry-curses (since I use
awesome), so I figured it was probably a local issue. Perhaps there's a
wider problem here?

--
Sam Jorna (wraeth)
GnuPG Key: D6180C26

[Sam Jorna]

If anyone else is getting this, it seems to be resolved by exporting
GPG_TTY=$(tty) either immediately before attempting to sign or in your
shell ~/.*rc file.

[Mart Raudsepp]

I'd consider this a temporary workaround. The real issue would just be
workarounded with this, which is nice to get something committed, but
not so nice longterm.
I had similar issues, but it turned out some pinentry issues for me
iirc, so properly fixed by now and not needing such hackery anymore.


Mart

[Fabian Groffen]

https://www.gnupg.org/documentation/manuals/gnupg-devel/Common-Problems.html

gnupg is just weird like that...

Fabian

--
Fabian Groffen
Gentoo on a different level

[Andrew Savchenko]

This is not a workaround, but officially recommended practice, from
man gpg-agent:

You should always add the following lines to your .bashrc or
whatever initialization file is used for all shell invocations:

GPG_TTY=$(tty)
export GPG_TTY


Best regards,
Andrew Savchenko

[Mart Raudsepp]

Then the packages or eselect pinentry or whatever should be taking care
of it, not have users have to mess with .bashrc to have stuff work.

I don't have GPG_TTY and it works fine, but I use a graphical password
asking agent.


Mart

[Mike Gilbert]

This is not practical.

Adding it to the global /etc/bashrc is a bad idea. It would slow down
every shell startup (fork/exec), even for users who do not actively
use gpg (like root).

Also, there is no way to know what shell each gpg user will be using.

[M. J. Everitt]

Sounds to me like a perfect candidate for an elog/einfo, no??

[Mike Gilbert]

Who reads those? ;-)

It's not a bad idea though.

[M. J. Everitt]

I do, but only usually if its the last package of an emerge because
otherwise its lost many many thousands of lines upwards. Thank goodness
for portage's savelog feature. - Actually that reminds me .. someone
mentioned a useful tweak to that, with an appropriate FEATURES switch,
it would categorise the output of the logging system .. must look that
one up again, or poke the wiki team .......

[Rich Freeman]

On Wed, Dec 14, 2016 at 10:27 AM, M. J. Everitt <m.j.e...@iee.org> wrote:
>
> I do, but only usually if its the last package of an emerge because
> otherwise its lost many many thousands of lines upwards. Thank goodness
> for portage's savelog feature. - Actually that reminds me .. someone
> mentioned a useful tweak to that, with an appropriate FEATURES switch,
> it would categorise the output of the logging system .. must look that
> one up again, or poke the wiki team .......
>

IMO, emailing elogs to root should probably be the default. By all
means let people turn it off, but I bet a lot of people don't realize
it is an option.

This goes in all my make.conf files:
PORTAGE_ELOG_CLASSES="warn error log"
PORTAGE_ELOG_SYSTEM="save mail"
PORTAGE_ELOG_MAILURI="a...@a.com smtp.server.address"
PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} merged on \${HOST} with notice"

Yes, some packages are a bit spammy and this should be fixed, but in
general it has prevented more headaches than it has caused.

--
Rich

[M. J. Everitt]

I would tend to agree that in a sysadmin role this would be very helpful.

At the risk of repeating myself, is there any einfo/elog displayed when
portage is (first) updated, to alert users of this functionality? A link
to the wiki page explaining the features [poke wiki team!] mentioned
would probably be most useful.

[Doug Freed]

On Wed, Dec 14, 2016 at 10:52 AM, M. J. Everitt <m.j.e...@iee.org> wrote:
> I would tend to agree that in a sysadmin role this would be very helpful.
>
> At the risk of repeating myself, is there any einfo/elog displayed when
> portage is (first) updated, to alert users of this functionality? A link
> to the wiki page explaining the features [poke wiki team!] mentioned
> would probably be most useful.
>

The PORTAGE_ELOG_* variables are documented in
/usr/share/portage/config/make.conf.example, which is referenced by
the make.conf man page.

-Doug