I don't know this file.

This does not look like any GnuPG related code. Did you want to report this to
OpenSSL?

GKD hijacks the gpg <-> gpg-agent IPC. It does this for a long time now but
most users don't care about this and the mainainer keeps this as the default.
Everone using gpgsm has always run into this problem.

Yes, this is hijacking.

The gpg--agent emulation of GKD is indeed dangerous. GnuPG consists of several
closely connected components. Arbitrary replacing an compenent breaks the whole
thing. On proprietary systems such a behaviour would be called malware.

PKIX is entirely broken. Even the most expensive SSL certificate does not get
you any assurance. To avoid man-in-the-middle threats, please check the OpenPGP
signature with an existing version of gpg4win or compare the published
SHA-1checksums with those from the announcement mails.

Sorry, the fix does not remove the bug:

[/home/permail/RHEL5/devel/gpgfamily/bin/gpgsm] [--no-greeting] [--yes]
[--auto-issuer-key-retrieve] [--batch] [--no-tty] [--homedir]
[/home/p/perske/.perMail/gnupghome] [--base64] [--detach] [--local-user]
[&7CF2C58D823C0ED461ED6B1FD13F9E96B6F7C436] [--status-fd] [8] [--output]
[/index/permail/RHEL5/devel/sso/work/pgp.89542620000040ef.out] [--sign]
[/index/permail/RHEL5/devel/sso/work/pgp.89542620000040ef.dat]
(using a self-written pinentry replacement)

gpgsm: note: non-critical certificate policy not allowed
dirmngr[25485.0]: permanently loaded certificates: 0
dirmngr[25485.0]: runtime cached certificates: 0
dirmngr[25485.0]: no CRL available for issuer id
A52EFAEFBC86EF98C5E9AA92B3ECEC4101080F0A
gpgsm: certificate not found: Ambiguous name
dirmngr[25485.0]: assuan_inquire(SENDCERT) failed: IPC call has been cancelled
dirmngr[25485.0]: error fetching certificate by subject: No data
dirmngr[25485.0]: crl_parse_insert failed: Missing certificate
dirmngr[25485.0]: crl_cache_insert via DP failed: Missing certificate
dirmngr[25485.0]: command ISVALID failed: Missing certificate
gpgsm: certificate
#1700BFBB98F74B/1.2.840.113549.1.9.1=#636140756E692D6D75656E737465722E6465,CN=Zertifizierungsstelle
Universitaet Muenster - G02,O=Universitaet Muenster,C=DE
gpgsm: checking the CRL failed: Not found
gpgsm: can't sign using `&7CF2C58D823C0ED461ED6B1FD13F9E96B6F7C436': Not found

Currently used versions:

dirmngr-1.1.1.tar.bz2
dirmngr-1.1.1-pth-fix.patch
gnupg-1.4.17.tar.bz2
gnupg-2.0.24.tar.bz2
libassuan-2.1.1.tar.bz2
libgcrypt-1.6.1.tar.bz2
libgpg-error-1.13.tar.bz2
libksba-1.3.0.tar.bz2
pinentry-0.8.3.tar.bz2
pth-2.0.7.tar.gz
(my own) pinentry.c

The assuan_inquire(SENDCERT) above requests a certificate by distinguished name,
not by authority key identifier (see T1644 (perske on May 23 2014, 07:05 PM / Roundup)), thus it does not matter that the
certificates re-issued by the DFN-PKI kept their authority key identifiers; the
problem is triggered by (correctly) keeping the Distinguished Name.

(I did not yet analyze your bugfix.)

Done for 2.1 with commit 03018ef

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libassuan.git;a=patch;h=134c045c7d1f93ce61f62193d33af8a6e8825543

should workaround your bug unless you enable debugging.

Fic for master with commit c434de4. However decryptyed files are not subject to
this because that would for sure breakk too man applications.

Okay, that looks more like a bug in libassuan. Without me really looking
at backtrace; might this patch

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libassuan.git;a=patch;h=46b6d97b4a396c16df53e82872c3cc772d427623

help?

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.

Just for my information, do you have done some tests for GnuPG2 on boot (because existant script are based on gpg) ?

okay.

Hello Werner,

Applied to master and 2.0.

I'll apply the patch. Thanks.

I don't think that it is worth the trouble. A pinpad reader make most sense on
desktop machines and there we have 2.x. 1.4 is maintained for use on servers
where card support is anyway hard to operate.

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.

I can confirm to you as I've write last time, but this time with new gnupg2 (2.0.24)
and gnupg (1.4.16) version, than Vega reader works fine with gpg-agent, but failed without it.

It seems that you missed the patch attached to the original submission, which
has all the required info: vendor ID is VENDOR_GEMPC (0x08e6), product ID is
0x3437, and the change to be applied indeed is in the internal CCID driver.

The reader is supported by PC/SC-lite, which never uses non-null NADs.

In 2.1.x (development), scdaemon and its pinpad support has been improved
(including name change from "keypad" support), and it's backported to 2.0.x.

However, it is not backported to 1.4.x. For gpg of 1.4.x, it only works when
you use gpg-agent and scdaemon of 2.?.x.

Some fixes (such as PC/SC support for MacOS) are backported to 1.4.x, though.

For Covadis Vega-Alpha, we would need to backport pinpad support improvement, as
well as CCID driver support improvement (for no auto configuration feature).

Changes are not trivial to merge, I don't know if it's worth for 1.4.x.

Could you please give more information, such as its USB vendor ID and product ID?
I assume that you are using GnuPG's internal CCID driver.
If you have a patch, please attach it here.
Is the reader supported by PC/SC-lite? If so, we could see how it is handled.

commit 045c979 has the patch to be released with 2.0.25.

The gnupg version mentioned in T1402 (aheinecke on Jun 25 2014, 03:48 PM / Roundup) should be 2.0.22 and not 2.0.18

I can confirm the problem described in the redhat bug still exists. Ran into it
on ubuntu 14.4 with gnupg 2.0.18 (with use-agent in the gpg config).

gpgsm --import <cert> failed with decryption failed without opening pinentry.
But after unsetting GPG_AGENT_INFO it worked.

Fixed in master.

I meant 2.0.24 of course.

Sorry, I do not understand. Please describe exactly what you did. You need to
follow the syntax rules of the parameter file. See doc/DETAILS for a description.

I ran additional test.

It appears that was because the file I was trying to generate the key from was
named gpg.conf

Which still shouldn't be.

Done for 2.0.14 with commit e790671c

I consider to do this for 2.1

Fixed for 2.0.24.

Documented in master. Will be used by 2.0 as weel.

I improved the description in GIT master. This will be used for all
new releases. For 2.1 it reads:

     --export-secret-keys
     --export-secret-subkeys

              Same as --export, but exports the secret keys instead.
              The exported keys are written to STDOUT or to the file
              given with option --output.  This command is often used
              along with the option --armor to allow easy printing of
              the key for paper backup; however the external tool
              paperkey does a better job for creating backups on
              paper.  Note that exporting a secret key can be a
              security risk if the exported keys are send over an
              insecure channel.

              The second form of the command has the special property
              to render the secret part of the primary key useless;
              this is a GNU extension to OpenPGP and other
              implementations can not be expected to successfully
              import such a key.  Its intended use is to generated a
              full key with an additional signing subkey on a
              dedicated machine and then using this command to export
              the key without the primary key to the main machine.

              GnuPG may ask you to enter the passphrase for the key.
              This is required because the internal protection method
              of the secret key is different from the one specified
              in the OpenPGP protocol.

Thanks

Seem to be fixed in recent versions.

I improved this by adding missing CFLAGS and re-ordering some.
But that this is not a complete solution. The libgpg-error include
directory has now a higher preference but ld may not pick up the right
library if another one is installed. The problem is that the -L
option and the -l options are not emitted separately by
gpg-error-config.

Please no bug reports against a version under development.

Backported to 2.0