Tracked at: https://bugs.kde.org/show_bug.cgi?id=363309
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 20 2016
May 19 2016
Issue is resolved
Done for new searches.
Thanks. I need a stack backtrace to find the location of the cause.
Please start gpg-agent using:
gpg-connect-agent /bye
The figure out the PID of the gpg-agent process and run
gdb /usr/local/bin/gpg-agent PID
At the gdb prompt enter
handle SIGPIPE nostop noprint pass c
The "c" continues operation of gpg-agent. In another terminal run
gpg2 --sign
as done in your example. GDB in the first terminal will eventually
stop due to the assert. Enter at the gdb prompt:
bt
and post the output. I would also like to know which version of
libgpg-error you are using:
gpg-error --version
should show this (or use gpg-error-config --version).
Here is another session after another three times failure.
This time, unblock by admin with Admin PIN.
$ gpg --card-edit
Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.1.9-87021534)
00 00
Application ID ...: D276000124010200FFFE870215340000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 87021534
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 0 3 3
Signature counter : 6
Signature key ....: 6E9A 631F 1997 F37C 7F4E 9952 8916 1D16 AA0D B710
created ....: 2016-05-19 05:09:13
Encryption key....: 0138 70C9 FA89 986F 2784 31A9 8AAA 8F21 ABD4 A70C
created ....: 2016-05-19 05:09:13
Authentication key: B2FE 8DAF 9494 3320 760F 38E2 30F6 A992 6870 02D6
created ....: 2016-05-19 05:11:14
General key info..: pub rsa4096/AA0DB710 2016-05-19 Chuji Kunisada
<chuji@gniibe.org>
sec> rsa4096/AA0DB710 created: 2016-05-19 expires: never
card-no: FFFE 87021534
ssb> rsa4096/ABD4A70C created: 2016-05-19 expires: never
card-no: FFFE 87021534
ssb> rsa4096/687002D6 created: 2016-05-19 expires: never
card-no: FFFE 87021534
gpg/card> admin
Admin commands are allowed
gpg/card> passwd
gpg: OpenPGP card no. D276000124010200FFFE870215340000 detected
1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit
Your selection? 2
[ Admin PIN ]
[ New PIN ]
[ Repeat New PIN ]
PIN unblocked and new PIN set.
1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit
Your selection? q
gpg/card>
Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.1.9-87021534)
00 00
Application ID ...: D276000124010200FFFE870215340000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 87021534
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 6
Signature key ....: 6E9A 631F 1997 F37C 7F4E 9952 8916 1D16 AA0D B710
created ....: 2016-05-19 05:09:13
Encryption key....: 0138 70C9 FA89 986F 2784 31A9 8AAA 8F21 ABD4 A70C
created ....: 2016-05-19 05:09:13
Authentication key: B2FE 8DAF 9494 3320 760F 38E2 30F6 A992 6870 02D6
created ....: 2016-05-19 05:11:14
General key info..: pub rsa4096/AA0DB710 2016-05-19 Chuji Kunisada
<chuji@gniibe.org>
sec> rsa4096/AA0DB710 created: 2016-05-19 expires: never
card-no: FFFE 87021534
ssb> rsa4096/ABD4A70C created: 2016-05-19 expires: never
card-no: FFFE 87021534
ssb> rsa4096/687002D6 created: 2016-05-19 expires: never
card-no: FFFE 87021534
$
My case with Gnuk Token.
First, I intentionally input wrong PIN for singing three times.
Then, I invoke gpg --card-edit (with 2.1.2 on Debian experimental) to unblock
the token by resetcode.
$ gpg --card-edit
Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.1.9-87021534)
00 00
Application ID ...: D276000124010200FFFE870215340000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 87021534
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 0 2 3
Signature counter : 6
Signature key ....: 6E9A 631F 1997 F37C 7F4E 9952 8916 1D16 AA0D B710
created ....: 2016-05-19 05:09:13
Encryption key....: 0138 70C9 FA89 986F 2784 31A9 8AAA 8F21 ABD4 A70C
created ....: 2016-05-19 05:09:13
Authentication key: B2FE 8DAF 9494 3320 760F 38E2 30F6 A992 6870 02D6
created ....: 2016-05-19 05:11:14
General key info..: pub rsa4096/AA0DB710 2016-05-19 Chuji Kunisada
<chuji@gniibe.org>
sec> rsa4096/AA0DB710 created: 2016-05-19 expires: never
card-no: FFFE 87021534
ssb> rsa4096/ABD4A70C created: 2016-05-19 expires: never
card-no: FFFE 87021534
ssb> rsa4096/687002D6 created: 2016-05-19 expires: never
card-no: FFFE 87021534
gpg/card> unblock
gpg: OpenPGP card no. D276000124010200FFFE870215340000 detected
[ Resetcode ]
[ New PIN ]
[ Repeat New PIN ]
PIN changed.
gpg/card>
Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.1.9-87021534)
00 00
Application ID ...: D276000124010200FFFE870215340000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 87021534
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 6
Signature key ....: 6E9A 631F 1997 F37C 7F4E 9952 8916 1D16 AA0D B710
created ....: 2016-05-19 05:09:13
Encryption key....: 0138 70C9 FA89 986F 2784 31A9 8AAA 8F21 ABD4 A70C
created ....: 2016-05-19 05:09:13
Authentication key: B2FE 8DAF 9494 3320 760F 38E2 30F6 A992 6870 02D6
created ....: 2016-05-19 05:11:14
General key info..: pub rsa4096/AA0DB710 2016-05-19 Chuji Kunisada
<chuji@gniibe.org>
sec> rsa4096/AA0DB710 created: 2016-05-19 expires: never
card-no: FFFE 87021534
ssb> rsa4096/ABD4A70C created: 2016-05-19 expires: never
card-no: FFFE 87021534
ssb> rsa4096/687002D6 created: 2016-05-19 expires: never
card-no: FFFE 87021534
gpg/card> quit
Please note that 'unblock' subcommand is to unblock with resetcode.
May 18 2016
After a release upgrade, in "gnupg 1.4.20-1ubuntu3 amd64", this typo disappeared
(I see "the").
For myself, this issue can be closed.
For some reason, I can't reproduce your problem in 2.1.x. Isn't it a problem of
your smartcard implementation?
Please describe the specific version number of GnuPG which is possible to
unblock this particular implementation of smartcard.
May 17 2016
This is with gnupg 2.1.12, I don't have the same issue with gnupg 2.0.30
1.4.18-7ubuntu1
$ dpkg-query -l gnupg
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend | |
| / Err?=(none)/Reinst-required (Status,Err: uppercase=bad) | |
| / Name Version Architecture Description | |
+++-===================-==============-==============-============================================
ii gnupg 1.4.18-7ubuntu amd64 GNU privacy guard - a free
PGP replacement
Hi Werner,
It's Linux 3.10.0-229.4.2.el7.x86_64 and GnuPG 2.0.22 libgcrypt 1.5.3.
If you mean the commands to delete the test secret key that is now somehow
still showing up when I try to delete the new public key, just imported,
that's:
gpg --delete-secret-keys 'user ID...'
Trying to edit the newly imported key:
gpg -u 'user ID for the key that is used to sign/trust keys' --edit-key
'user ID of the new key'
also tried
gpg -u 'user ID for the key that is used to sign/trust keys' --edit-key
keyID...
I hope this helps, thanks.
Raf
Which GnuPG version?
Please report this to Debian. This is not a part of upstream Pinentry.
Which version of GnUPG are you using?
Which operating system?
Can you please provide the commands you used?
I can't decide right now whether this might be a bug; You may also want to ask
on gnupg-users for help.
Which version of GnuPG are you using?
May 15 2016
Sorry for the delay. Here is the complete log:
- SNIP ---
languitar@bird ~> gpg --card-edit
Reader ...........: REINER SCT cyberJack RFID standard (XXXXX) 00 00
Application ID ...: XXXXXX
Version ..........: 2.0
Manufacturer .....: Yubico
Serial number ....: XXXXXX
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: forced
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 127 127 127
PIN retry counter : 0 3 3
Signature counter : 3
Signature key ....: Some Stuff
created ....: Some Stuff
Encryption key....: Some Stuff
created ....: Some Stuff
Authentication key: Some Stuff
created ....: Some Stuff
General key info..: pub rsa2048/0xXXXXXXXXXXXXX somedate somename
<somemail@example.org>
sec> rsa2048/0xXXXXXXXXXXXXXXXX created: somedate expires: never
card-no: 0006 XXXXXX
ssb> rsa2048/0xXXXXXXXXXXXXXXXX created: somedate expires: never
card-no: 0006 XXXXXX
ssb> rsa2048/0xXXXXXXXXXXXXXXXX created: somedate expires: never
card-no: 0006 XXXXXX
gpg/card> admin
Admin commands are allowed
gpg/card> unblock
[GUI asks for admin PIN and new PIN, which I entered]
gpg: OpenPGP card no. XXXXXX detected
Error changing the PIN: Conditions of use not satisfied
gpg/card> passwd
gpg: OpenPGP card no. XXXXXX detected
1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit
Your selection? 2
Error unblocking the PIN: Conditions of use not satisfied
1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit
Your selection? q
gpg/card> q
languitar@bird ~> gpg --version
gpg (GnuPG) 2.1.12
libgcrypt 1.7.0
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later https://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
languitar@bird ~> uname -a
Linux bird 4.5.4-1-ARCH #1 SMP PREEMPT Wed May 11 22:21:28 CEST 2016 x86_64 GNU/Linux
- SNIP ---
Same thing works without problems using an older version of GPG on my mac.
May 13 2016
Anything else I can do to help?
May 12 2016
We had the same effect here and it was caused by a V3 public key in the
keyring.
This key does not show up while listing the public keys with GnuPG 2.1.12. We
could only identify and remove it by accessing the keyring with a GnuPG 1.4.x
installation.
It should be considered to either
- display the key also during the list-keys command (to help the user to track
down the problem)
or
- ignore it silently while building the trust db.
PS: forget the --homedir thing, it is even reprodicable in the default folder in
%appdata%.
Sorry, forgot my import cmdline:
C:\Program Files (x86)\GNU\GnuPG\2.1.12\bin>gpg --batch --homedir
%tmp%\_tempKeyring --import "P:\2EEC2B65A2B4B3EF.sec.asc"
gpg: Die "Keybox" `C:/Users/ranftd/AppData/Local/Temp/_tempKeyring/pubring.kbx'
wurde erstellt
gpg: C:/Users/ranftd/AppData/Local/Temp/_tempKeyring/trustdb.gpg: trust-db erzeugt
gpg: Schlüssel A2B4B3EF: Öffentlicher Schlüssel "Daniel Ranft (Giegerich &
Partner GmbH)" importiert
gpg: Schlüssel A2B4B3EF: "Daniel Ranft (Giegerich & Partner GmbH)" nicht geändert
gpg: Schlüssel A2B4B3EF: geheimer Schlüssel importiert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 4
gpg: importiert: 1
gpg: unverändert: 1
gpg: gelesene geheime Schlüssel: 3
gpg: unveränderte geh. Schl.: 2
gpg: keine ultimativ vertrauenswürdigen Schlüssel gefunden
May 11 2016
Please ask on the gnupg-users mailibng list for help.
Hmm, it is not about the maintainer mode...
commit 2a9fc56 fixes the access to uninitialized buffers. Given that GnuPG puts
all senstive data into a special memory area which is cleared before a free, I
don't see a problem with a possible data leak.
What is left is the problem that the parser does not always detect invalid
encodings. This can be improved but I am not anymore convinced about that table
driven parser.
Fixed in 83a90a916e8e2f8e44c3b11d11e1dd75f65a87fb (master).
This patch seems to solve the segfault for me, thanks!
Thank you for the report and your cooperation.
At least, this fix is needed.
Include trace.log
Thanks. I would actually prefer to handle this by mail because this makes
communication easier and faster. It would also be useful to known on what you
are working or plan to work on, so that we do not need to rush out releases
while there are other obvious things to fix.
Now I regret reporting so many different problems as a single ticket. Note that if possible
information leaks are the only thing we are concerned with, all the issues in this ticket can be
solved by systematically initializing dynamically allocated memory, so they have that in common.
This won't solve the problems that several inconsistent .crt files are in fact accepted as valid,
showing contents of the freshly initialized allocated memory in place of information that should have
come from the .crt file. I would much prefer fixing these logic errors individually so that use of
uninitialized memory can remain a useful symptom of other logic errors, but ultimately, this is your
choice to make.
Here is a fourth instance of use of uninitialized memory (uninitialized4.crt).
The tis-interpreter diagnostic is:
Certificate in `t.crt':
serial....:
02
3A
83
issuer....:
`CN=GeoTrust Global CA,O=GeoTrust Inc.,C=US'
subject...:
`CN=Google Internet Authority G2,O=Google Inc,C=US'
notBefore.:
2013-04-05 15:15:56
notAfter..:
2016-12-31 23:59:59
hash algo.: (null)
Extn: 2.5.29.35 at 517 with length 24
SubjectKeyIdentifier:
none
src/ber-help.c:213:[kernel] warning: accessing uninitialized left-value:
assert \initialized(buf);
stack: _ksba_ber_parse_tl :: src/cert.c:1836 <-
_ksba_cert_get_auth_key_id :: src/visibility.c:280 <-
ksba_cert_get_auth_key_id :: tests/cert-basic.c:190 <-
list_extensions :: tests/cert-basic.c:546 <-
one_file :: tests/cert-basic.c:593 <-
mainsrc/ber-help.c:213:[kernel] warning: completely indeterminate value in mallocksba_malloc_l130_935 with offsets 4152 bits.
In order to make the use of uninitialized memory visible, apply the following patch:
~/instrumented/libksba-1.3.4$ diff -u src/ber-
ber-decoder.c ber-decoder.lo ber-dump ber-help.c ber-help.h ber-help.o
ber-decoder.h ber-decoder.o ber-dump.c ber-help.c~ ber-help.lo
pascal@TrustInSoft-Box-VII:~/instrumented/libksba-1.3.4$ diff -u src/ber-help.c{~,}
- src/ber-help.c~ 2016-05-03 18:12:09.000000000 +0200
+++ src/ber-help.c 2016-05-11 03:04:34.361037076 +0200
@@ -210,7 +210,7 @@
/* Get the tag */ if (!length) return premature_eof (ti);
- c = *buf++; length--;
+ c = *buf++; printf("|%02hhX|\n", c); length--;
ti->buf[ti->nhdr++] = c; ti->class = (c & 0xc0) >> 6;
With the above instrumentation in place, the command "./tests/cert-basic uninitialized4.crt" shows:
Certificate in `uninitialized4.crt':
serial....: (#023A83#) issuer....: `CN=GeoTrust Global CA,O=GeoTrust Inc.,C=US' subject...: `CN=Google Internet Authority G2,O=Google Inc,C=US' notBefore.: 2013-04-05 15:15:56 notAfter..: 2016-12-31 23:59:59 hash algo.: (null)
Extn: 2.5.29.35 at 517 with length 24
SubjectKeyIdentifier: none
| 30 | |
| 3E | |
cert-basic.c:219: ksba_cert_get_auth_key_id: Invalid certificate object
KeyUsage: Not specified
ExtKeyUsages: none
CertificatePolicies: none
cert-basic.c:557: expected EOF but got: BER error
The line |3E| indicates access to uninitialized memory.
Here is a third instance, much like the second one. As the read from uninitialized memory happens in append_ucs2_value(),
the uninitialized memory is harder to recognize in the output.
tis-interpreter information:
Certificate in `t.crt':
serial....:
02
3A
83
src/dn.c:522:[kernel] warning: accessing uninitialized left-value:
assert \initialized(tmp_1);
(tmp_1 from s++)
stack: append_ucs2_value :: src/dn.c:619 <-
append_atv :: src/dn.c:667 <-
dn_to_str :: src/dn.c:692 <-
_ksba_dn_to_str :: src/cert.c:609 <-
get_name :: src/cert.c:744 <-
_ksba_cert_get_issuer :: src/visibility.c:190 <-
ksba_cert_get_issuer :: tests/cert-basic.c:424 <-
one_file :: tests/cert-basic.c:593 <-
mainsrc/dn.c:522:[kernel] warning: completely indeterminate value in mallocksba_malloc_l130_935 with offset 1384 bits.
May 10 2016
re: T2324 (justus on Apr 18 2016, 05:22 PM / Roundup)
- gpg --export-secret-key should export unprotected keys that are stored w/o a passphrase"
That would violate the policy we implement in gpg-agent. The
gpg-agent is responsible for private keys and a client may not use a
private key without the agent's consent. If we would allow that by
default there won't be any protection at all and keys can be easily
exported and used. A required confirmation via the Pinentry would
solve the practical problem. However, there is the question what to
do on unattended systems - the only way it can be done right now is
configuring gpg-agent to use a custom pinentry, or by extending the
loopback mode.
Thanks. Fixed in the repo.
May 9 2016
I see. I just pushed two fixes.
Thanks. Fix released with 2.0.30 and 2.1.12.
We can close this bug after the release of 1.4.21
Fixed in all branches.
Master 2.1: d9f9b3be036747c9f55060aed47896f951bfb853
1.4: d957e4388f72581b1ec801613b5629b5ea3f586d
2.0: eb7806d63df63663170ba86f0673caa34b944c28
For some reason, the commit messages of 1.4 and 2.0 refers
master commit of 2f3e42047d17313eeb38d354048f343158402a8d.
Perhaps, I did in my repo and it was 2f3e420 and apply it to 1.4 and 2.0.
Then, I pushed 1.4, 2.0, and 2.1. and 2.1 was failed because of
non-fast-forward. Then I rebased for 2.1.