Page MenuHome GnuPG

every input in pinentry-gtk-2 results in core dump
Closed, ResolvedPublic


I've recently updated from pinentry-gtk-2 0.9.1 to 0.9.5 and suddenly couldn't
anymore. On input of character 16 at the latest, gpg stopped with the somewhat
error message

"gpg: public key decryption failed: End of file
gpg: decryption failed: No secret key"

I tracked the issue down to pinentry (only the -gtk-2 version seems affected,
neither -
curses nor -qt4 show the same behavior). It seems to me like it's maybe related
issue 1996.

I'm running on kernel 4.1.5 and use ibus as GTK input method, if that's of any
relevance. I've attached the output of getpin. (It's basically the same output
it breaks automatically on input of character 16 or on enter with input
characters 0-

Downgrading to 0.9.1 immediately fixes the issue.


Event Timeline

ciil added projects: pinentry, Bug Report, Gentoo.
ciil added a subscriber: ciil.

neal added a subscriber: neal.

Thanks for the report. I'm having trouble reproducing this. I run pinentry
(from the build directory) as follows:

  $ valgrind gtk+-2/pinentry-gtk-2
  ==3611== Memcheck, a memory error detector
  ==3611== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
  ==3611== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
  ==3611== Command: gtk+-2/pinentry-gtk-2
  OK Pleased to meet you
  D 012345678901234567890

I enter a 21 character password and pinentry doesn't crash and valgrind doesn't
report any error. I tried with both 0.9.5 and the latest version from git.

Are you able to reproduce the problem using the above method? Can you provide
an example of how to cause the crash using only pinentry?


Kristian Fiskerstrand pointed out that there is more information about this bug

Sorry for not having provided more information earlier. The bug seemed to only appear
on my work machine (and I've been to busy at work the last few weeks to provide more
information), but now I can reliably reproduce it on my home machine, too, funnily
enough after a clean re-install of Arch Linux.

It certainly seems to be the same bug as the Gentoo bug #560158 you linked. I cannot
reproduce the behavior in either gdb or valgrind, but without those the command fails
every time.

I've since downloaded and manually built 0.9.5 and 0.9.6. I could reproduce it in the
standalone 0.9.5 build (again, neither valgrind nor gdb could be coerced into also
showing the behavior. The issue seems to be fixed in 0.9.6, though! Arch doesn't yet
provide the new version as an official package. I'll tell you if the issue's also fixed
when that package comes out.

Still have no idea what caused it though.

ciil: Thanks for the update!

werner set External Link to 22 2015, 3:21 PM
neal claimed this task.

Given that this bug does not appear to be reproducable with 0.9.6, I'm marking
this as resolved.