up

Ok, can I append this information in documentation ? I see the website source
code in git repository. Can I add this contribution ?

You need to know the OpenPGP protocol to understand what this is about. IIRC,
the GPH also explains this.

pub = public key oacket
uid = user id packet
sub = public subkey packet
sec = secret key packet
sbb = secret subkey packet
sig = key signature

I've attached the output of configure and make as well as config.log.

That option gives the installation directory of libgpg-error which is in turn
used to run gpg-error-config to get the various build flags. Thus it depends
on how you installed libgpg-error. See also config.log to see what configure
figured out about libgpg-error.

Please send this to Ubuntu. We can't help you with customized versions. All
distributions apply different patches to the upstream source.

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.

gpgsm is the S/MIME cousin of gpg.
No need for that. The files are of course encrypted.

Sorry for being ignorant, but I don't even know what gpgsm is... ;-)

I'm just using the "classical" gpg since it came into life (being a PGP user for
more than 20 years now)...

But since gpgsm seems to use a separate directory for the private keys it's fine
for me as well -- I will then mount that directory as an encrypted one...

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?

The secret keys are stored as separate files below ~/,gnupg/private-keys-v1.d/ -
gpgsm uses this method for more than a decade.

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

This is very odd. I did several installs of Vanilla-2.2.1 and gpg --version
always failed with a missing libgpg-error-0.dll error and a search of the
C:\Program Files\GNU\GnuPG directory and below did not locate the file.

On the same day, I did a custom install of Light-2.2.1 and that worked fine.

Today I downloaded Vanilla-2.2.1 again and replaced Light-2.2.1 with it (I made
sure the install directory was deleted by the uninstall of Light also) and it
works as in the screenshot.

I am running Microsoft Security Essentials but have never seen it quarantine or
block any files from programs I have installed.

I don't understand why an install works today and didn't previously but I guess
that's Windows for you ;-)

Thank you for taking the time to look at this and I guess it can be closed.

Regards,
Neil Darlow

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.

I Just installed gpg4win-vanilla 2.2.1 on a clean VM to check this.
As you can see in the screenshot everything is there and works as expected.

Is it possible that some kind of "Security Software" silently blocked the
installation of libgpg-error for you?

Maybe you could try to install it again into another Directory and check if it
is still missing?

Werner,

I did exactly the steps you requested for the original bug report. The file
libgpg-error-0.dll is not installed.

Does that mean there will only be a single keyring in the future? So that I can
not lock-away my secret key(s) while I don't need them?

Nope; won't be done. We had this in the past and people enabled it and later
complained about disk full stati. And yes, it exposes confidential info.

2.1 will not anymore use a secring and thus this problem will soon vanish.
Fixing this may introduce other bugs, thus we better don't do anything here.

Thus this is a bug in homebrew and not in GnuPG. If you have a solution please
post it here for reference.

Please do us a favor and describe what you see on the screenshot. It is not
easy to grep over a shreenshot.

Please check whether
C:\Program Files\GNU\GnuPG\libgpg-error-0.dll
exists.

You may also test whether there is some problem with the gpg wrapper. You may
also want to test

c:
cd c:\Program Files\GNU\GnuPG
gpg2 --version

Homebrew is an OSX package manager.

It's interesting that it built inside Homebrew, because they do some automatic
adjustment of CFLAGS etc. to make a package more likely to build on OSX.

Probably what happened is they removed a flag which is causing the problem I'm
reporting, but only on XCode5.0

I'm no programmer, but I'll look into this further.

Version numbers are in error. I updated from Vanilla 2.2.0 to 2.2.1.

On 2013-10-16 at 06:16 +0000, asdil12 via BTS wrote:

You might use the known-
readers.txt from ccid
source, which lists usb-ids
and reader ames for
detection via pcscd. As
pcscd adds some text about
reader port to the string,
you can only match the
beginning of the string, but
that should do it.

You might use the known-
readers.txt from ccid
source, which lists usb-ids
and reader ames for
detection via pcscd. As
pcscd adds some text about
reader port to the string,
you can only match the
beginning of the string, but
that should do it.

On 2013-10-15 at 22:53 +0000, asdil12 via BTS wrote:

I applied your patch onto gnupg-2.0.22 source (I couldn't get the automake-foo
run through), and it worked again. (enable-pinpad-varlen set in config).
I used the cherry reader for testing.

I applied your patch onto gnupg-2.0.22 source (I couldn't get the automake-foo
run through), and it worked again. (enable-pinpad-varlen set in config).
I used the cherry reader for testing.

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."

2.0.18 is quite old - please test with a decent version. Some time ago we
overhauled the locking code to better detect "broken" filesystems.

I already fixed that on Friday. Commit 9d89564a.

For auto detection of pinpad, it does the detection itself.

But the reader only works when we have some information on card [0] or
configuration of enable-pinpad-varlen.
That's because there is no good standard way to detect reader's capability
for variable length input.

Internal ccid driver has better support for variable length input detection
based on its USB ID.

It is currently, out of sync and it only works for SCM SPR 532.
I will add KAAN, FSIJ, REINER, VASCO, and CHERRY for PC/SC with USB ID, too.
I need users' help for PC/SC for detection with card reader name.

[0] http://wiki.gnupg.org/CardReader/GemaltoPC

Fixed in 2.0.x and master in git repository.
Please test it out.

BTW: shouldn't scd autodetect pinpad
support, or does this only work when using
internal ccid driver insted of pcsc?

The patch can be found in

http://git.buildroot.net/buildroot/plain/package/gnupg/gnupg-mips64-build-fix.patch