Which libassuan version are you using?
libassuan-config --version
should show it.

The problem seems to be segmentation fault in tests/basic. The provided
information is not sufficient for a closer look. You need to help us by
debugging the core file to get at least backtrace.

However, I would suggest to report this to this Homebrew thingie and to try
wityh the latest libgcrypt (1.6.3, but 1.6.4 will be release soon)

Did you had a chance to test the patch or 1.19?

Please send us a more detailed bug report. See
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
Do not forget to tell us your OS and also send the output of "gpg --version"
You may also want to update to a decent version of gpg.

ANy news?

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.

Hi,

since April there are 14 crashes recorded in windows event log, one occurred in
function btnDecryptLarge all others in function GetCustomUI.

It happens occasionally when changing between views. So it's not easy to
reproduce the behaviour. Even the log is not very useful because there are no
timestamps in the log entries to check it against windows event log.

There are other 6 active plugins installed.

If you need more info’s, please let me know.

KJ

This should work. GpgOL 2010 just queries the Plain Text from outlook and
encrypts that.

KMail (Which is my primary mail client and testing client) works fine with such
mails.

Robert, could you send an example mail created by GpgOL that kmail does not decrypt?

To: aheinecke@intevation.de

My keyid is: C97822F5

You can find it attached.

Hi, I've just replaced the use of our custom entry widget with the standard Gtk+
entry widget. This should fix the problem. Please report back whether this is
the case. Thanks.

Well is is T2046

JW also posted a response as T2076 (but without the example ;-)

I asked you for an example to replicate the problem. You claimed:

  GCC 3x used to regularly remove that kind of code.

Why do you think it is arrogant to ask for an example in a case where we have
different opinions on how to interpret a standard? I explained why your
arguments can't be applied to our code. Your counter argument may be valid but
I do not see it as my job to tests dozens of compiler versions to find a
compiler bug.

We discussed and improved the wipememory code over many years and I see no new
datapoints which require another change. Iff there is a concrete compiler bug
or a different specs interpretation which leads to the remove of wipememory code
I would like to see an example to find a way to work around it.

Werner Koch <wk@gnupg.org> added the comment:

Please show me the disassembly of an example along with the commands and program
versions you used to create an object file with removed wipememory code.

Please show me the disassembly of an example along with the commands and program
versions you used to create an object file with removed wipememory code.

Following a propriteary platforms best practices without checking is not always
the Right Thing.

volatile is used to make sure the writes actually hit the
memory. gcc is not allowed to remove that for the simple reason, it
can't know whether this plain RAM or a device mapped into the address
space. That is the whole point of using volatile and it has been
introduced back in the 80ies for just this reason (back than to write
to video memory).

Probably already fixed.

Note that our wipememory does not use memset and thus a compiler can't
apply the C specification of memset.

volatile is used to make sure the writes actually hit the
memory. gcc is not allowed to remove that for the simple reason, it
can't know whether this plain RAM or a device mapped into the address
space. That is the whole point of using volatile and it has been
introduced back in the 80ies for just this reason (back than to write
to video memory).

The use of SecureZeroMemory under Windows is not useful because it
does exactly the same what we do with wipememory.

On 06/17/2015 11:01 PM, Jeffrey Walton wrote:

I'm actually more concerned that the optimizer will remove the code
because it surmises its a dead store. That's the issue I am trying to
articulate.

One relatively unimportant misunderstanding is due to the fact that
the standard only talks about accesses to volatile objects. It does
not talk about accesses via volatile qualified pointers. Some
programmers believe that using a pointer-to-volatile should be
handled as though it pointed to a volatile object. That is not
guaranteed by the standard and is therefore not portable. However,
this is relatively unimportant because gcc does in fact treat a
pointer-to-volatile as though it pointed to a volatile object.

It says that it's not guaranteed and it's not portable by the C
language itself.

So, you are right that volatile qualifier to a pointer should be
avoided (from viewpoint of portability).

I think that I am also right that it works with GCC implementation
(in 2008, at least).

I'm actually more concerned that the optimizer will remove the code
because it surmises its a dead store. That's the issue I am trying to
articulate.

Thank you for your auditing libgcrypt. Your effort helps our
development.

You shouldn't use volatile for that when compiling with GCC.

Any references which support this opinion of yours, please?

On Tue, Jun 16, 2015 at 4:31 AM, NIIBE Yutaka via BTS
<gnupg@bugs.g10code.com> wrote:

NIIBE Yutaka <gniibe@fsij.org> added the comment:

I think that JW had some confusion. I believe that his argument is irrelevant
for libgcrypt's implementation of wipememory.

Thank you for clarification.

I think that JW had some confusion. I believe that his argument is irrelevant
for libgcrypt's implementation of wipememory.

(1) Ian is right about multi-processors and memory access. We should use atomic
operations, memory barrier, and mutual exclusion things like lock/unlock.
(2) Compiler can optimize away memory access if computation should be same (as
defined by the language).

libgcrypt's use of volatile qualifier for wipememory is *not* for shared access
by multi-processors.
It is to make sure memory is wiped by its write access.

Certainly, it's not "memory mapped hardware", and it would be abuse. But, this
interpretation does not conflict with current wipememory implementation. Write
access to memory mapped hardware never removed. For correctness of code, I
believe current implementation is OK.

If this were the suggestion for fast wipememory, I would agree for non-use of
volatile qualifier. I think that current implementation is OK, considering use
cases.

Did you asked on the GUIX list whether they have a similar problem?

the reporter noted the same problem in 0.9.0, not just 0.7.6.

still, a re-test with 0.9.2 would be useful

Afaik this is not a pinentry-qt issue as the style looks ok under Unity (ubuntu)
and Windows.

I want to investigate why that is the case and figure out what the problem is
exactly (other KDE password entries in the same style environment look slightly
better) so I left this open to remind me.

I've clarified the title.

Is that still a problem with the latest Pinentry (0.9.1 or 0.9.2)?

Or, SCardControl default timeout is too short. GnuPG doesn't specify the
timeout, but uses 0x00 for bTimeOut, which means using default.
I don't know how we can change default timeout on Windows.

Please take this to gnupg-users. I assume this is a misunderstanding we can't
solve here.

I am sorry but I am not a gnupg developer and I can only understand what the
code effectively does, respective to what I need to know, not what that implies
to your development ideas.

I saw no handling of empty passphrases in 2.1.2. Could be because it doesn't
exist, could be because it was moved somewhere else now. I don't know what you
know about this. But I can clearly see from multiple instances that you do not
read my comments (e.g. you suggest secring.gpg which is inside ~/.gnupg which I
explicitly said to have removed two times now). Which implies that you cannot
have a clear understanding of the issue at all.

The archlinux gnupg is original with flags --enable-maintainer-mode
--enable-symcryptrun --enable-gpgtar .

The archlinux pinentry is 0.9.0 original with flags --enable-fallback-curses
--enable-pinentry-curses .

You are mixing two very different things. The gpg from 2.1 and the one from 2.0
are entirely different when it comes to gpg-agent communication. "Some kind of
failure" is not very helpful in this regard.

I can only suggest to post your problem to gnupg-users to get more comments.

Can you please lookup the description or the symbol for the ERRNO value 141 ?
find /usr/include -name errno.h | xargs grep 141
might reveal it.

Yes it works fine, sorry I did not respond earlier. I'm using your patch since
you published it:
https://github.com/SynoCommunity/spksrc/blob/develop/cross/libgcrypt/patches/001-asm-allow-building-x86-and-amd64-using-old-compilers.patch

Path is in the repo so it will go into 1.7. Might have also been backported to 1.6.

I had another go at this bug this evening. I had a keyserver with reproducable
failures (while I still could use it in gpg1). And suddenly during debugging it
all changed and worked flawlessly. I was down to npth_connect and after I had
added debug output in there it began to work (and kept working after removing
the debug output again, hrmpf)

With regards to the test case from T1773 (aheinecke on Nov 26 2014, 10:35 PM / Roundup). This now (after e8c0ed7 ) returns a
dead host.

Btw. I think the error message could be improved for dead hosts.

gpg2 --keyserver hkp://127.0.0.1 --search foobar
gpg: no keyserver known (use option --keyserver)
gpg: keyserver search failed: No keyserver available

Should be something like "No reachable keyserver found"

Assigned this bug to me to at least provide a clearer example.

Thanks for fixing the 127.0.0.1 lookup error :)

pinentry-qt should have only been the default if you install a gpg4win version
that includes qt.

Could you execute pinetry-qt directly and enter "getpin" in the command line
window that opens?
What happens then?