Thank you for your patch. I think that it is more useful.
Well, it will change the semantics of "reader-port" option slightly (exact match
to partial match).
In this case, isn't it more useful for users to allow default reader when no
match (my patch attached)?

Please let me know your name so that I can acknowledge your name as original
patch author.
Please test my patch.

Do you mean GnuPG doesn't detect second card change?
Currently, GnuPG doesn't support multiple readers and multiple cards.

Or, SCardControl default timeout is too short. GnuPG doesn't specify the
timeout, but uses 0x00 for bTimeOut, which means using default.
I don't know how we can change default timeout on Windows.

The error value is 0x79, which means ERROR_SEM_TIMEOUT on Windows.
It seems for me that there was another application which tried to access the
smartcard and the reader, which interfered.
Did you use solely GnuPG?

Fix committed as 971d558e862db878a7310e06ed7116dbe36886ab.

Let me confirm. Does this bus still exist in recent version of gpg 1.4 and/or
2.0, 2.1?

Please give me the output of lsusb -v -d 058f:9540
and debug log of scdaemon.
Do you mean --card-status works bug --decrypt fails?

Thank you for further information.
Now, I understand your situation of mixture of architectures.
I think that your source code was once configured by 32-bit environment (which
created links to 32-bit), and then you tried to configure and to compile by
64-bit environment which caused errors.

I think that "make distclean; configure; make" would success even on the 32-bit
environment with different host OS.

It is fixed by the commit: f82c4a6d0d76e716b6a7b22ca964fa2da1f962a0
This is not a perfect solution (it updates key storage by "learn --force" command
of gpg-agent), but it works fine usually.

It seems for me that your build environment is not clean and has some links for
i386, while your arch is x86_64. It is i386's mpih-add1 which has ALIGN(3) at
line number 44.

Please do 'make distclean' and configure, then make.

I understand your case.

As I wrote to #712744, distribution nowadays is conservative enough for its
default kernel settings, and it doesn't require each application to have special
settings.

I think that we will be able to close this soon.

Confirmed. I think that this is a regression.
EXPORT_KEY command of gpg-agent should return the stub secret key.

werner: Please go ahead.
I don't have enough knowledge about keybox implementation (and its plan).
My message is basically to share information, and my proposed change is not the
real fix, but something
pointing the (major) cause.

Thank you for your report.

I think the document is right. Yes, it's somehow confusing.

It explain "two conditions" using GPG default values, but then,
it says : "This example assumes that two marginally-trusted keys
or one fully-trusted key is needed to validate another key.
The maximum path length is three."

It would be better explaining with default values, though.

In 2.1, secret key handling has been changed.
It's now *not* in secring.gpg but files under private-keys-v1.d.
I think that there were some migration problems for your environment (and GnuPG
2.1.0) and one of your secret key is not converted.

I don't know the reason, but I guess that your key is only available in
secring.gpg and not in pubring.gpg.

About secret key reference (in secring.gpg for 1.4/2.0, under private-keys-v1.d
for 2.1) can be generated by accessing card.
With 2.1.1, --card-status will register key reference. With 2.1.0, you can do:

  $ gpg-connect-agent learn /bye

Once you have public key entry and private key reference to your card, it should
work well.
Could you please try installing your public key with 2.1.0 and making private
key reference?

I confirmed that --check-trustdb results broken trustdb.
We can check by --list-trustdb.

It should be something like:

rec 30, trust A405E58AB3725B396ED1B85C1318EFAC5FBBDBCE, ot=6, d=0, vl=34
rec 31, valid 10FBD3A5C90C815ECDE1D7F3B64A505EB55CC999, v=6, next=0
rec 32, valid 669CC039409AA2E143FDA46B0636052BB5875E07, v=6, next=31
rec 33, valid 8797B8E208A2F9947790975948D15DF75034A882, v=6, next=32
rec 34, valid 3B623D1260F1F12E06655DB6182516BB82E8F60F, v=6, next=33
rec 35, trust 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9, ot=0, d=0, vl=38
rec 36, valid F5118E19309A256D9C802AF3B8179AC5AA9D04E4, v=5, next=0
rec 37, valid 867625B137AE05F8579F82DC29B5EAF274386304, v=5, next=36
rec 38, valid 328A5C6C1B2F0891125ECBE4624276B5A2296478, v=5, next=37

But 2.1.1 updates like:

rec 30, trust A405E58AB3725B396ED1B85C1318EFAC5FBBDBCE, ot=6, d=1, vl=34
rec 31, valid 10FBD3A5C90C815ECDE1D7F3B64A505EB55CC999, v=2, next=0
rec 32, valid 669CC039409AA2E143FDA46B0636052BB5875E07, v=2, next=31
rec 33, valid 8797B8E208A2F9947790975948D15DF75034A882, v=2, next=32
rec 34, valid 3B623D1260F1F12E06655DB6182516BB82E8F60F, v=2, next=33
rec 35, trust 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9, ot=0, d=0, vl=38
rec 36, valid F5118E19309A256D9C802AF3B8179AC5AA9D04E4, v=5, next=0
rec 37, valid 867625B137AE05F8579F82DC29B5EAF274386304, v=5, next=36
rec 38, valid 328A5C6C1B2F0891125ECBE4624276B5A2296478, v=5, next=37

That is, DEPTH=1 and VALIDITY=2, which is wrong.

I investigated and realized that keybox_search function in kbx/keybox-search.c
is not yet mature. That is, it doesn't support skipfnc yet.

In this situation, something like following is needed:
diff --git a/g10/trustdb.c b/g10/trustdb.c
index 1bf664b..a946c29 100644

• a/g10/trustdb.c

+++ b/g10/trustdb.c
@@ -1625,6 +1625,12 @@ validate_key_list (KEYDB_HANDLE hd, KeyHashTable full_trust,

merge_keys_and_selfsig (keyblock);
clear_kbnode_flags (keyblock);
pk = keyblock->pkt->pkt.public_key;

+ if (search_skipfnc (full_trust, pk->keyid, NULL))
+ {
+ release_kbnode(keyblock);
+ continue;
+ }
+

if (pk->has_expired || pk->flags.revoked)
  {
    /* it does not make sense to look further at those keys */

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.

With current 2.0 branch of git repository, I believe that Vega-Alpha works fine.
Please confirm.

Fixed in the git master branch.

Thanks for information (Note: I don't have experiences for Android).
I realized that fork/exec is basically not supported for applications on
Android.
If this were true, it makes sense to ifdef-out the calls to pthread_atfork for
Android.

The reason why we need to call pthread_atfork is to reset signal mask for
executable fork/exec-ed by the program. We had a bug which stoped killing
pinentry (which was fork/exec-ed by gpg-agent).

I checked the source code of Bionic libc. There is the function defined:
https://github.com/android/platform_bionic/blob/master/libc/bionic/pthread_atfork.
cpp

Is it compile time option not including this function?

On 2013-11-13 at 23:29 +0000, asdil12 via BTS wrote:

The fix for the login-data thing works fine.

On 2013-11-12 at 21:29 +0000, asdil12 via BTS wrote:

asdil12 <dominik@heidler.eu> added the comment:

OK, I tested gnupg-2.0.22 with both patches applied, and it worked again.

I also noticed, that the pinpad won't be used - you would be asked via software

• (even if enable-pinpad-varlen was specified), if this

Login data .......: gpguser\n\x14P=6,8\n
thing was set on the card.

On 2013-11-09 at 15:36 +0000, asdil12 via BTS wrote:

I just retried today using gnupg-2.0.22 with your patch, and it
failed again, if the enable-pinpad-varlen option was set:

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.

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.

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.

Err... Sorry for your troubles. It's my fault.

I maintain scute in Debian. It works for me for years.
I suspect it was build time issue.

The option --default-cert-level is described in the manual.
Thus, this bug report is about web.
Changing "category" from gnupg to gpgweb.

Reporter's intention would be:
Given a public key with user id="", importing that key fails.

IIUC, this bug report were talking aboug
http://www.gnupg.org/download/release_notes.en.html

At that time (2008-12-08), there were 1.4.9 and 2.0.9, but the page didn't have
information of those version. There is no information about 1.4.9 and 2.0.9,
still now.

I think that Andrew's name in Chinese in UTF-8 cannot be interpreted as iso8859-1,
it goes as is, but usually it is interpreted as iso8859-1 as a fallback.

If you are sure it's utf-8 encoded, you can use --utf8-strings option.

This bug is still there in 2.0.20.
It would be better to add following line in main of gpgv.c.

gcry_control (GCRYCTL_INITIALIZATION_FINISHED, NULL);

I think that original reporter's intention is to prevent attaching by ptrace.
By PR_SET_DUMPABLE disabled, ptrace PTRACE_ATTACH won't work any more.
This would be better if we care about kernel compatibility.
In http://bugs.debian.org/714107, I found that setrlimit64 doesn't work reliably
for 2.6.34 or older. PR_SET_DUMPABLE seems to work for even 2.4.x.

Fixed in 212a325d428e0ab5c51c42a3ea33efb21ad1f79f

To be useful bug report, please specify version number of your program. Also,
please show us your configuration file (if any). Specifically, do you have
enable-ssh-support option for gpg-agent?

To diagnose, please create a file .gnupg/scdaemon.conf with something like:

debug-level guru
debug-all

log-file /var/tmp/scd.log

Let us know the content of the file, when you see the problem.

I analyze this issue. The problem is that the reader only supports:
dwFeatures: 0x000207B2

   02.... Short APDU level exchange

With this condition, application program (GnuPG), which needs to send larger
APDU, requires to use command-chaining. However, current V2 cards doesn't
support command-chaining. Alas, there is no way for application program to
process such a request by its user.

Cases are: decryption and key write to card for larger keys.
We need to detect those cases and should notify error to users, though.

This bug is fixed for 2.0.

http://git.gnupg.org/cgi-bin/gitweb.cgi?
p=gnupg.git;a=commit;h=ae22d629b6028aa994ff09f012e1cb029575eeae