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?

Program received signal SIGSEGV, Segmentation fault.
0xd065ea30 in int_vasprintf ()

from /opt/freeware/lib/libassuan.a(libassuan.so.0)

(gdb) bt
#0 0xd065ea30 in int_vasprintf ()

from /opt/freeware/lib/libassuan.a(libassuan.so.0)

#1 0xd065e9d8 in _assuan_vasprintf ()

from /opt/freeware/lib/libassuan.a(libassuan.so.0)

#2 0xd065e868 in _assuan_debug ()

from /opt/freeware/lib/libassuan.a(libassuan.so.0)

#3 0xd065d5b0 in assuan_new_ext ()

from /opt/freeware/lib/libassuan.a(libassuan.so.0)

#4 0x1005e818 in ?? ()
#5 0x1005bee4 in ?? ()
#6 0x1005cd8c in ?? ()
#7 0x1005a338 in ?? ()
#8 0x1005a898 in ?? ()
#9 0x10058434 in ?? ()
#10 0x100804cc in ?? ()
#11 0x10082508 in ?? ()
#12 0x10074518 in ?? ()
#13 0x1007ac70 in ?? ()
warning: (Internal error: pc 0x100071a3 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x100071a3 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x100071a3 in read in psymtab, but not in symtab.)

#14 0x100071a4 in ?? ()
warning: (Internal error: pc 0x100001bb in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x100001bb in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x100001bb in read in psymtab, but not in symtab.)

#15 0x100001bc in ?? ()
(gdb) info r
r0 0xd06689a0 3496380832
r1 0x2ff20be0 804391904
r2 0xf15b74e4 4049302756
r3 0x2ff20d14 804392212
r4 0x80 128
r5 0xb8050012 3087335442
r6 0x7f7f7f7f 2139062143
r7 0x3 3
r8 0x25700a00 628099584
r9 0x28 40
r10 0xd0668a2c 3496380972
r11 0xd06689c8 3496380872
r12 0xf02a56f8 4029306616
r13 0x100afe54 269155924
r14 0x3001bdd8 805420504
r15 0x800 2048
r16 0x30005e08 805330440
r17 0x0 0
r18 0x0 0
r19 0x2 2
r20 0x0 0
r21 0x100ab0b0 269136048
r22 0x3000507c 805326972
---Type <return> to continue, or q <return> to quit---
r23 0x0 0
r24 0x0 0
r25 0x0 0
r26 0xd06689b0 3496380848
r27 0x0 0
r28 0x68 104
r29 0x2ff20cb0 804392112
r30 0xd06689c8 3496380872
r31 0x2ff20cd0 804392144
pc 0xd065ea30 0xd065ea30 <int_vasprintf+56>
msr 0xd032 53298
cr 0x42322022 1110581282
lr 0xd065ea20 0xd065ea20 <int_vasprintf+40>
ctr 0xd0105800 3490732032
xer 0xc 12

and rpm -qa | grep libassuan
libassuan-2.1.1-1

Here it is.

I need at least a stack backtrace to fix that. The easiest way to produce one
is to run gpg under a debugger. I do not know which debugger is installed on
your systen (adb, xdb) - with gdb you would run it this way

$ gdb gpg
(gdb) run --edit-key KEYID
[after the segv]
(gdb) bt
(gdb) info r

Post the output here if possible.

It is good that you reported this now because I was about to do a 2.0.25 today.

Oh sorry. It is not readily viewable in the browser due to the MIME type.

This issue has already been discussed on the mailing list and another bug
report. Your problem is a messed up toolchain installation. We can't do
anything about that. If you want to follow up on this, please do so on the
mailing list. The audience of the bug tracker is too small and we don't have
any OSX stuff here for testing.

Then please describe the error building GnuPG using the one and only way -

everything else is not supported.

??? I *did*, in this very bug report right here, in my original post. Is my
attachment not viewable?

Then please describe the error building GnuPG using the one and only way -
everything else is not supported.

Homebrew is the only way building with Xcode5 can SUCCEED. Building the "normal"
way, with ./configure --stuff && make, FAILS. The bug is in gnupg2. Homebrew has
somehow stepped around the bug.

Used the latest MacPorts version available as of today.

Now the picture changed somewhat:

• 8x -----------

$ gpg2 --delete-keys 450F89EC
gpg (GnuPG) 2.0.21; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: keyblock resource `/Users/theUser/Documents/Encrypted/gpg/secring.gpg': No
such file or directory

pub 1024D/450F89EC 2003-02-03 PAUSE Batch Signing Key 2011 <pause@pause.perl.org>

Delete this key from the keyring? (y/N) y

• 8x -----------

As you see gpg2 STILL for whatever reason tries to do "something" with the
secret keyring (even though I would not expect this since the command supposedly
only operates on PUBLIC keys), but this time it succeeds.

So this is only a minor annoyance, but still I consider it "quirkish."

Please re-open if you still see this problem.

We did some work on ttyname_r portability and close this report. If there are
still issues, please create a new report. Thanks!

There is no version 2.1 of GPA.
Please tell us more details.

Thanks, Werner, for your reply and your suggestions. I'll have a look at the
GPGME solution.

We had some other reports on the ML about similar problems. Really time to go
after it.

I believe we tracked it down to the sending machine (an IBM mainframe) writing the encrypted
bytestream out to a FB (Fixed Blocked) dataset. This results in the PGP datastream being padded
out to a specific width as defined in the DCB. When gpg tries to decrypt this, it finds these
padding bytes and all hell breaks loose with a variety of different errors.

No response to my last message. It seems to be an IPC bug and not related to
GPG given that other GUIs don't have these problems.

Seems to be fixed in gpg4win 2.1.0

Already fixed, will be in 1.5.0

Should probably beretested with Gnupg 2.1(beta or later)
because agent startup might have changed.

http://pkgs.fedoraproject.org/gitweb/?p=libgcrypt.git;a=blob_plain;f=libgcrypt-1.4.5-ImplicitDSOLinking.patch;hb=HEAD

The given patch URL is not valid.

ping. Is that bug still relevant?

ping

Requested information has been sent by e-mail.

Forget my previous comment. All checks should be there. Can you please send me
your config.log file by PM (wk at gnupg.org)?

D110: 264_dirmngr-1.0.3-allow_only_complete_dps.diff

Previous patches does not solve problem that one of DPs failes.

Just for clarification about DP list in certificate syntax and its semantics:

My previous patch does not delete all duplicate CRLs from cache if one entry is
recognised as still usable.

D111: 263_dirmngr-1.0.3-dont_overwrite_usable_crls-2.diff