scdaemon is part of GnuPG.
OpenSC is entirely unrelated to GnuPG.

Please take this to a mailing list (e.g. gnupg-users)

Yes, "ascii" could be written uppercase, but it looks better in
lowercase here and we won't change it after >18 years w/o complains

"keyserver" is the common spelling and thus used this way.

The algorithm names are listed in the way the various options require them.

Btw, Taher Elgamal wants his surname spelled without uppercase 'G".

Finally, I managed to reproduce the same (I suppose) situation.
Please see: https://lists.gnupg.org/pipermail/gnupg-devel/2016-June/031211.html
It is READ vs. WRITE race condition.

I think that this patch improve the situation.
It moves the creation of the hash table to the place where it creates version
record (holding the lock).

D205: 846_gpg14-create_hashtable-fix.diff

Sorry for going AWOL on this, Werner. Do you still need a backtrace from me, or is the
one from 2371 enough?

Thank you for update.
msg8431 seems to be another race condition. I only fixed one race in 2015.

My saying in T1675 (gniibe on May 25 2015, 07:38 AM / Roundup) sounds wrong (now, for me).
For example, create_hashtable does lseek to SEEK_END.
When some another process is adding new entry (say, also calling
create_hashtable), we have a valid race condition here.
I mean,

(1) process A calls lseek with SEEK_END, seek goes to a point.
    Then, context switch.
(2) process B calls lseek with SEEK_END. seek goes same point as A.
(3) process B update info using the point.  context switch to A.
(4) process A wrongly overrides info using the point.
    It results inconsistent data.

It was fixed in db1ecc8212defdd183abbb6b1407fcc8d2dc9552 for 2.1.
In 2.1, HDRLEN=0 for all callers, so, there will be no same "Ohhhh jeeee" any more.

In 1.4 and 2.0, HDRLEN is used as a hint. There is no need to change 1.4 and
2.0. Detail is described in:
https://lists.gnupg.org/pipermail/gnupg-devel/2016-June/031178.html

Just noticed this issue as it was mentioned in T2359 which is "my" issue
about this topic ;-)
I've actually implemented the algorithm outlined in T1143 (dkg on Sep 23 2009, 06:53 PM / Roundup) in libkleo/ QGgpME
for a better opportunistic encryption support in kmail (
https://phabricator.kde.org/T2520 )

Werner told me that something like that will be done in GnuPG itself. Afaik the
current plan is to have --locate-keys use a similar algorithm to return exactly
one "best" key if a mailbox is given. And if I understood werner correctly this
would then also be the key used when you would do a "gpg -er <mailbox>"

Should this be closed as Superseded?

So, how do we proceed? Release 2.1.13 and wait for potential problems?

related: T1143

Fixed in the repo (commit 536c721)

We have meanwhile implemented such a check.

gpgkey2ssh has been removed from master (2.1)

Most thingd have probably been implemented in the meantime.

Seem to be a regression in 2.0. 2.1 works as expected.

I'm still able to make this fail, though quite less often.
Example is here.

$ wget https://bugs.gnupg.org/gnupg/file443/show-race.sh -O show-race.sh
$ chmod 755 show-race.sh
$ dpkg-query --show gnupg
$ gnupg --version
gpg (GnuPG) 1.4.20
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://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, RSA-E, RSA-S, ELG-E, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,

CAMELLIA128, CAMELLIA192, CAMELLIA256

Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

$ sed -i.dist -e 's,precise-updates,precise,' -e
's,20101020ubuntu136.15,current,' show-race.sh
$ diff -u show-race.sh.dist show-race.sh

• show-race.sh.dist 2016-06-06 16:37:25.845783450 -0400

+++ show-race.sh 2016-06-06 16:37:26.645771713 -0400
@@ -37,7 +37,7 @@

mkdir "$GNUPGHOME" && chmod 700 "$GNUPGHOME"

fi

-url="http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/20101020ubuntu136.15/images"
+url="http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images"
kr=/usr/share/keyrings/ubuntu-archive-keyring.gpg
for f in SHA256SUMS SHA256SUMS.gpg; do

   [ -f "$f" ] && continue

$ i=0; while i=$(($i+1)); do rm -Rf out*; echo -n "$i "; ./show-race.sh ||
break; done
1 max=100 cmd=gpg --verify args:
2 max=100 cmd=gpg --verify args:
3 max=100 cmd=gpg --verify args:
4 max=100 cmd=gpg --verify args:
...
67 max=100 cmd=gpg --verify args:
68 max=100 cmd=gpg --verify args:
69 max=100 cmd=gpg --verify args:
3 failed: out.3 [2]

$ cat out.3
gpg: Signature made Mon 23 Apr 2012 03:52:09 PM EDT using DSA key ID 437D05B5
gpg: error opening lockfile `/tmp/xt/out.gnupghome/trustdb.gpg.lock': No such
file or directory
gpg: lockfile disappeared
gpg: 12: read expected rec type 10, got 0
gpg: lookup_hashtable failed: trust database error
gpg: trustdb: searching trust record failed: trust database error
gpg: Error: The trustdb is corrupted.
gpg: You may try to re-create the trustdb using the commands:
gpg: cd /tmp/xt/out.gnupghome
gpg: gpg2 --export-ownertrust > otrust.tmp
gpg: rm trustdb.gpg
gpg: gpg2 --import-ownertrust < otrust.tmp
gpg: If that does not work, please consult the manual

7257ea2 switches to none.

There is also a new option --with-subkey-fingerprint which keeps the compact
fingerprint format also for subkeys. The Lead-in text for fingerprints n the
listing is in any case not anymore printed if keyid-format is none.

Just pushed the --keyid-format=none feature. Changing the default will be done
with another commit.

Replacing revoked keys made me wonder if we actually need an auto-refresh key.
If we try to return one valid key with --locate-keys wouldn't it make more sense
semantically if we use the auto-key-locate mechanisms with locate-keys when a
key is expired in the local store?

This would also work better for revoked keys where a Parcimonie style auto
refresh would pick up the revocation and locate-keys would then look for a new key.

How do you plan to handle the case that "local" lookup only yields expired or
revoked keys. Will GnuPG then automatically fall back to other locate-keys methods?
This would be my wish so that a MUA / User of that command does not have to care
about that case :-)

Ah sorry I understood you were saying the bug is in OpenSC. Where can I report
to scdaemon? I can't find it.

FireFox is not GnuPG and does not support the OpenPGP card.

As I said, the card may work with gpgsm because I once developed support for the
Belgian eID card. But it is likely to need some tweaking (gnupg/scd/app-p15.c)

I saw that it says not supported, but DNIe is actually supported. I can use it
flawlessly with Firefox for instance.

Please see:
https://github.com/OpenSC/OpenSC/wiki/DNIe-%28OpenDNIe%29#update-2013-08-27
https://github.com/OpenSC/OpenSC/issues/774#issuecomment-222468916

Thanks!

Please ask on the gnupg-users mailing list for help.

Some quick hints:
Is your pinentry properly installed? Is gpg-agent running? Does gnome-keyring
interfere with gpg-agent?

This is the current output with keyid-format=none

pub dsa2048 2007-12-31 [SC] [expires: 2018-12-31]

80615870F5BAD690333686D0F2AD85AC1E42B367

uid [ full ] Werner Koch <wk@gnupg.org>
uid [ full ] Werner Koch <wk@[...]>
uid [ unknown] Werner Koch <werner@[...]>
sub dsa1024 2011-11-02 [S]
sub rsa2048 2014-01-02 [E] [expires: 2016-12-31]

The problem I have is how to decide when to use the compact fingerprint format.
My idea is to always use the compact format unless --fingerprint switched back
to the old format (which is easier to read).

I started working on this.

I tried it but I think it looks prettier without. A rationale might be that the
fingerprint is a property of the "pub" (public key) and the line should be
considered a continuation line.

This looks great to me. I've always been frustrated by the c+p difficulty.

Does it make sense to put an "fpr" at the beginning of the fingerprint line, to
match with "pub" and "uid" ?

For example:

pub dsa2048 2007-12-31 [SC] [expires: 2018-12-31]
fpr 80615870F5BAD690333686D0F2AD85AC1E42B367
uid [ full ] Werner Koch <wk@gnupg.org>

Have you started work on this change or would you like patches?

The current --with-fingerprint output is

pub dsa2048/F2AD85AC1E42B367 2007-12-31 [SC] [expires: 2018-12-31]

Key fingerprint = 8061 5870 F5BA D690 3336  86D0 F2AD 85AC 1E42 B367

uid [ full ] Werner Koch <wk@gnupg.org>

One problem I have with this format is the c+p of the fingerrpint is
not easy, because you need to mark the entire fingerprint and then use
quotes to use it. What about changing the default format (i.e. w/o
any fingerprint options to

pub dsa2048/F2AD85AC1E42B367 2007-12-31 [SC] [expires: 2018-12-31]

80615870F5BAD690333686D0F2AD85AC1E42B367

uid [ full ] Werner Koch <wk@gnupg.org>

or

pub dsa2048/1E42B367 2007-12-31 [SC] [expires: 2018-12-31]

80615870F5BAD690333686D0F2AD85AC1E42B367

uid [ full ] Werner Koch <wk@gnupg.org>

or

pub dsa2048 2007-12-31 [SC] [expires: 2018-12-31]

80615870F5BAD690333686D0F2AD85AC1E42B367

uid [ full ] Werner Koch <wk@gnupg.org>

or aligned in some other way?

Personally I would like to keep the long keyid at least for subkeys
because it makes the key listing easier to read and forced selection
of a signing subkey easier. However, removing information which is
in most cases useless and partly dangerous has a higher priority.
Thus a listing of my key may look like this:

pub dsa2048 2007-12-31 [SC] [expires: 2018-12-31]

80615870F5BAD690333686D0F2AD85AC1E42B367

uid [ full ] Werner Koch <wk@gnupg.org>
uid [ full ] Werner Koch <wk@[...]>
uid [ full ] Werner Koch <werner@[...]>
sub dsa1024 2011-11-02 [S]
sub rsa2048 2014-01-02 [E] [expires: 2016-12-31]

To implement that I would indeed suggest a keyid format "none" which
will be the default and select the above new listing format.

Not really making it simpler but --quick-gen-key can now take an expiration date.

Let's keep this bug open to track other improvements.

Ok,
Let me summarize how I understand the workflow is supposed to be:

• Generate a Key with the limited batch keygen.
• After key creation add subkeys as wanted with --quick-addkey
• Add additional UID's with --quick-adduid

I think I can work with that.
For full flexibility T2364 would be nice so that one could create a certify
only key this way and subkeys for everything else.

But yeah thats icing on the cake.

Still does not solve the Problem how to figure out which algrithms with which
parameters / capabilities are supportet but meh, I guess you can't have everything..

We also have --quick-addkey now.

We now have gpg --quick-addkey fpr algo usage expire
(for2.1.13)

In 1.4 and 2.0, --import just copies the block, so the bug doesn't hit. In 2.1,
when it tries to write to keybox, the bug hits.

The check what Neal introduced is somehow orthogonal to the change of mine.

The key in question, there is a User ID packet of length >= 256 (because he
include ssh key string in his User ID).
In the code of build-packet.c, gpg assumed the length of User ID is < 256 and it
is hard coded to have header length 2.
With the check (in gpg 2.1), it causes an error. I think that, in gpg 1.4 and
2.0, gpg creates malformed packet with incorrect length (LSB of the length).

fwiw, i first encountered this by doing a full-keyring refresh from the
keyservers. Dying rather than adjusting or accomodating the malformed header
meant that all keys after this one failed to refresh.

In general, dying outright seems likely to make an observed problem worse than
it needs to be.

I can confirm one defect with 2.1.11:
The ability to export a secret key without passphrase available in gnupg2.0
is gone. My use case is to write a testcase that automatically imports the key.

Duplicate of T2324

I am resolving this issue as duplicate of T2324
in the case of intented empty passphrase for the exported key.
(the export-reset-subkey-passwd flag should be taken to an entirely different
issue.)

FWIW, I added the stricter check. Previously, we specified the header size, but
didn't check that it was respected. When discussing this with Werner, he said
that respecting the header size was important, which is why I chose to die
rather than silently change the header size.

Bernhard: Please do not assign bugs to me without my consent.

Duplicate of T2374

Duplicate of T2307

We need to look at the history of the patch which introduced the stricter
checks. The problem we have is that some packets are indeed malformed but must
be exported/re-packaged exactly in their original broekn format.

I don't know the reason, but User ID length is hardcoded.

diff --git a/g10/build-packet.c b/g10/build-packet.c
index 4bfc2ac..1353a86 100644

• a/g10/build-packet.c

+++ b/g10/build-packet.c
@@ -329,7 +329,7 @@ do_user_id( IOBUF out, int ctb, PKT_user_id *uid )

  }
else
  {

• write_header2( out, ctb, uid->len, 2 );

+ write_header2( out, ctb, uid->len, 0 );

    rc = iobuf_write( out, uid->name, uid->len );
  }
return rc;