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

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: