Patch applied in dc417bf0c555a7416d0aedde6645fd1087660f92 (Dec 15, 2015)

iirc, we removed the patch from 2.1 due to some problems. We plan to work on it
in 2.3.

Neal, what is the status of this bug?

We still need to check whether has been fixed for 1.4 and 2.0.

Duplicate of T2348

For which branches has this been fixed?
Do we have releases for all of them?

2.1.12 does a verbose check and fix during --edit-key. We will eventually call
that reorder function during import. But let's wait for bug reports with the
--edit-key triggered code.

Fixed in 2.1.12

closing due to the release of 2.1.12.

Fixed in 2.1.12

Should be solved now: Use Libgpg-error 1.22 and GnuPG 2.1.12.

Thanks for the clarification. I'll ignore it in QGpgME then, too.

And after grepping for KEYEXPIRED in doc I have now found the DETAILS
documentation of which I was unaware until now. :-)

This is documented behaviour; see below. GPA ignores this status line.

• KEYEXPIRED <expire-timestamp> The key has expired. expire-timestamp is the expiration time in seconds since Epoch. This status line is not very useful because it will also be emitted for expired subkeys even if this subkey is not used. To check whether a key used to sign a message has expired, the EXPKEYSIG status line is to be used. Note, that the TIMESTAMP may either be a number of seconds since Epoch or an ISO 8601 string which can be detected by the presence of the letter 'T'.

Another problem has been fixed in 6677d8b.
I intentionally set up more hubs from computer to the device to cause an error.
When an error occurred, scdaemon continued to report "Card error", even after I
inserted the device directly to the computer.
Now, it returns "No such device" for severe errors, and scdaemon can recover
from such errors.

D366: 825_fix-in-gpgmepp.patch

Note to self.

The problem is that editinteractor in edit_interactor_callback_impl checks
status_to_error before the GpgSignKeyEditInteractor::nextState implementation
has the chance to ignore that status with needsNoResponse.

A fix in GpgMEpp could be to ignore the error if the state machine was not
started. E.g. we have not yet send any command.

Attached patch fixes the problem. But I'm not sure that this does not cause
regressions e.g. when trying to add a uid to an expired key or trying to
actually sign expired uid's. :-/

The particular problem of T2306 (aheinecke on Apr 25 2016, 06:53 PM / Roundup) has been fixed in cb4fee8.

I think that it was not always reproducible because it depends on timing (only
when it detected an error at bulk_in, the problem happened). I'm not sure if
the difference of old/new libusb mattered for this problem.

Those libraries are not GnuPG specific.

Thank You. I noticed later that, indeed, at the first instance,
there's a problem with the library, but I corrected that issue
with the other try, the one that is described at

https://bugs.gnupg.org/gnupg/file821/2016_04_gnupg_v_2_1_11_build_log.txt

---citation--start----
gcc -DHAVE_CONFIG_H -I. -I.. -I../common -
DLOCALEDIR=\"/home/ts2/m_local/bin_p_originaalid/GNU_Privacy_Guard/v2016_04/gnup
g/share/locale\" -
DGNUPG_BINDIR="\"/home/ts2/m_local/bin_p_originaalid/GNU_Privacy_Guard/v2016_04/
gnupg/bin\"" -
DGNUPG_LIBEXECDIR="\"/home/ts2/m_local/bin_p_originaalid/GNU_Privacy_Guard/v2016
_04/gnupg/lib\"" -
DGNUPG_LIBDIR="\"/home/ts2/m_local/bin_p_originaalid/GNU_Privacy_Guard/v2016_04/
gnupg/lib64/gnupg\"" -
DGNUPG_DATADIR="\"/home/ts2/m_local/bin_p_originaalid/GNU_Privacy_Guard/v2016_04
/gnupg/share/gnupg\"" -
DGNUPG_SYSCONFDIR="\"/home/ts2/m_local/bin_p_originaalid/GNU_Privacy_Guard/v2016
_04/gnupg/etc/gnupg\"" -
DGNUPG_LOCALSTATEDIR="\"/home/ts2/m_local/bin_p_originaalid/GNU_Privacy_Guard/v2
016_04/gnupg/var\"" -
I/home/ts2/m_local/bin_p_originaalid/GNU_Privacy_Guard/v2016_04/libgcrypt/includ
e -
I/home/ts2/m_local/bin_p_originaalid/GNU_Privacy_Guard/v2016_04/libksba/include
-Wall -Wno-pointer-sign -Wpointer-arith -mtune=native -ftree-vectorize -MT
libkeybox_a-keybox-util.o -MD -MP -MF .deps/libkeybox_a-keybox-util.Tpo -c -o
libkeybox_a-keybox-util.o test -f 'keybox-util.c' || echo './'keybox-util.c
In file included from keybox-defs.h:42:0,

from keybox-util.c:29:

../common/stringhelp.h: In function ‘make_filename’:
../common/stringhelp.h:55:52: error: expected declaration specifiers before â
€˜GPGRT_ATTR_SENTINEL’
char *make_filename( const char *first_part, ... ) GPGRT_ATTR_SENTINEL(0);

^

---citation--end------

Besides, given the small size of the GnuPG, shouldn't the
few GnuPG specific libraries just be subfolders of the
GnuPG project? If not in the repository, then at least
at the release tar-ball? It would avoid the
"library wrongly installed" part.

libksba has not been installed properly.

I can make "a" problem (not sure if it is "the" problem) reproducible with the
following command (as root):

AUTHFILE="/sys/bus/usb/devices/4-1.2/authorized" ; echo 0 > "$AUTHFILE" ; sleep
1 ; echo 1 > "$AUTHFILE"

This was based on:
http://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line/61165#61165

where 4-1.2 is the id of my reader. The error message in scdaemon log is
slightly different but the behavior is the same. It's in an error state until I
kill it.

I'm not sure, if it is relevant, but
I tried to build the newer version, the v2.1.11, id est the "GnuPG Modern"
and it did not go so well either, despite the fact that
I custom-built the dependent libraries and put their bin folders to
PATH and lib64 folders LD_LIBRARY_PATH prior to attempting
to build the gnupg.

Thanks for the explanation, Werner.

This note might also be worth adding to the gpg-preset-passphrase manpage.

gpg1 does not known about keygrips. Instead of the keygrip, gpg1 uses the
fingerprint as cacheid for gpg-agent. The agent's command GET_PASSPHRAE, as
used by gpg1, uses a different cache mode from what gpg-preset-passphrases uses.
Thus even if you replace the keygrip with the fingerprint of the (sub)key, it
won't work.

I'll add

Note, that the tool @command{gpg-preset-passphrase}, which comes
with GnuPG-2, cannot be used to preset a passphrase for this
version of GnuPG.

to the gpg 1 man page.

I'm reading the implementation of new libusb.
If I guess correctly, the picture of the problem would be:

• New libusb somehow caches (or uses cache of kernel's) USB device list structures.
• When the device is plugged off/on (or hardware failures), the cache should be

updated.

• GnuPG's ccid-driver possibly keeps using staled data of USB device list.

I'll check the implementation detail, and try fixing this.
I think that current ccid-driver with new libusb has an issue for memory leaks
for device list, so, it should be reviewed and modified anyway.

It would be good if we could have a reproducible scenario.

I have implemented iconv in libgpg-error master (commit 1cd1ddb). This is a
stripped down version of win-iconv where I removed the feature to load another
libiconv and disabled the mlang.dll (whatever this is) for now.

With gnupg master commit bd4d656 tehre is no more need for libiconv for Windows.

I already sent Justsus some code I started with to restore that feature.

Fixed in f8adf1a.

Thanks for looking into this, Justus.

While you're working on this, it might make sense to consider restoration of the
--export-options export-reset-subkey-passwd flag, which was dropped in 2.1.

This flag was used by at least one GnuPG downstream (monkeysphere); its absence
causes "monkeysphere subkey-to-ssh-agent" to fail.

In GnuPG 1.4.x and 2.0.x, the option was defined this way:

export-reset-subkey-passwd
       When  using  the  --export-secret-subkeys  command,  this
       option resets the passphrases for all exported subkeys to
       empty. This is useful when the exported subkey is  to  be
       used  on an unattended machine where a passphrase doesn't
       necessarily make sense. Defaults to no.

Related T2324.

Werner: Yes please.

I have some stashed work to fix this but it is not ready - let me know if you
want to work on it.

commit d02de6c should fix that.

Use '=' for an exact match and optionally '*' for a substring match.

*See also T2070

I think I was confused by the fact that I didn't use ssh-add to add the key and
I didn't realize that I could add it manually to sshcontrol. I did that and it
now works as expected. Sorry about the noise.

Although maybe it would be nice to be able to make 'confirm' the default for
keys which are not listed in sshcontrol. But that's a very minor thing.

See also issue20170

Please describe the interaction. IIUC, isn't it pinentry problem?
Did you input your PIN? For "2 - unblock PIN" operation, you need to
authenticate as admin, did you input your PIN for admin? Wasn't it a failure of
PIN input for admin or user, whatever?

libgcrypt 1.7.0 is out. Please test with it.

HKPS won't be the reason, we use plain HKP

as of gpg.conf
keyserver hkp://keyserver.int.myCompany.com:11371

BTW. The versions in the previous post should have been 2.0.28 and 2.0.30 vs.
2.1.11, of course.

Hello. If you are using https to talk to your keyserver, your problem might be
Issue 1950 which we fixed in GnuPG 2.1.10.

A collegue of mine now has a similar problem with GnuPG on MacOS during gpg
--refesh-keys from an in-house SKS keyserver (set in gpg.conf)

Happens with GnuPG 2.2.28 and GnuPG 2.2.30. Problem disappeared with GnuPG 2.1.11.
Hence changed category back to gnupg as it's no Windows-only problem anymore.
Still assume that it is somewhat related to larger key rings.

gpg: Total number processed: 392
gpg: unchanged: 392
gpg: keyserver communications error: Not found
gpg: keyserver communications error: Bad public key
gpg: keyserver refresh failed: Bad public key

I understand the reason for re-encrypting -- i'm quite happy that the agent is
sensible about improving the security of the key when it adopts it.

my concern is that users don't know what to expect, and that different workflows
result in different sets of keys stored in the agent.

So i'd recommend that when importing without --batch, if the password fails for
any reason, gpg should fall back to the fast migration "kludge" rather than just
skipping that keyblock. That way the imported secret key material will still be
available and can be cleaned up/hardened on first successful use.