Page MenuHome GnuPG
Create Task
Maniphest T2076

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

Description

I've recently updated from pinentry-gtk-2 0.9.1 to 0.9.5 and suddenly couldn't
decrypt
anymore. On input of character 16 at the latest, gpg stopped with the somewhat
cryptic
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
to
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
whether
it breaks automatically on input of character 16 or on enter with input
characters 0-
15).

Downgrading to 0.9.1 immediately fixes the issue.

Details

External Link
https://bugs.gentoo.org/show_bug.cgi?id=560158
Version
0.9.5

Related Objects

Event Timeline

• werner mentioned this in T1878: wipememory relies upon volatile qualifier.Mar 30 2017, 7:15 PM
ciil set Version to 0.9.5.Aug 21 2015, 12:07 PM
ciil added projects: pinentry, Bug Report, Gentoo.
ciil added a subscriber: ciil.

669_pinentry-output.txt14 KBDownload

neal added a project: Info Needed.Aug 24 2015, 11:01 AM
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
  ==3611== 
  OK Pleased to meet you
  getpin
  D 012345678901234567890
  OK

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?

Thanks.

neal added a comment.Sep 15 2015, 11:58 AM

Kristian Fiskerstrand pointed out that there is more information about this bug
at: https://bugs.gentoo.org/show_bug.cgi?id=560158

ciil added a comment.Sep 15 2015, 8:09 PM

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.

neal added a comment.Sep 22 2015, 2:56 PM

ciil: Thanks for the update!

• werner set External Link to https://bugs.gentoo.org/show_bug.cgi?id=560158.Sep 22 2015, 3:21 PM
neal closed this task as Resolved.Nov 20 2015, 10:33 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.

neal removed a project: Info Needed.Nov 20 2015, 10:33 PM