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

D112: 262_dirmngr-1.0.3-dont_overwrite_usable_crls.diff

So, here it is. It's little verbose, be free to remove log_infos. This is output
I get (LDAP enabled) with this patch:

As time permits I should be able to check this out myself. Actually I will need
to do this because Iswitched to a kreebsd kernel on my laptop with a cm4040.
FWIW, I received the Design and Implementation of FreeBSD today.

I will have access to a MacOS system soon and will take care of ttyname_r then.
Leaving this open as a reminder until then.

Well that value is 0xFFFFFFFFFFFFFFFF.

Hm. Comparing --debug-all on both architectures I see clear differences. Not
sure if they count. But the value for length on the amd64 box, when it re-enters
the loop looks weired:

i386: no loop

Might be a zlib problem; see also T1011 .

JFTR: I have only tested on an amd64 box. But I can check this later with an
i386 box too.

I see this then:

Tested with gpgsm 2.0.10-svn4835 and pinentry-curses 0.7.4. Works fine now. I
did have to explicitly set GPG_TTY, though, to make pinentry-curses work, but
that's unrelated to this issue.

No response, assuming it has been fixed.

The build is broken. We had a report on the mailing list from SuSE and they
figured that the SuSE Toolchain is broken. Thus you need to update your OS - I
am not sure whether this is available. Please check the gnupg-users or
gnupg-devel mailing lists for further info.