Please check if the directory (of C:\GnuPG) permission is valid. Command would
be: dir C:\GnuPG
Please check if pubring.bak does not exist.

Another small note: The problematic key was in wide-spread use and additionally
it was distributed until few years ago with Apache's KEYS file and still is
listed here: https://people.apache.org/keys/committer/lars.asc

And I would not call my keyring "very large", it contains less than 1700 keys,
mostly fetched using "keyserver-options auto-key-retrieve" when reading mailing
lists.

So it probably does not only affect me.

Two more details:

1. All secret keys become unusable in this situation until you revert to a

backup of the public keyring, therefore I propose status "critical" (data loss)

2. The duplicates (or even triplicates with my own keyring) of the keys only

have one uid, even if the original has more.

Removing non-breaking spaces is a regression. Their appropriate use improves
readability. See, for instance, the following discussion:
https://tex.stackexchange.com/questions/15547/when-should-i-use-non-breaking-space
. If you have patches to improve the use of non-breaking spaces (adding them
where appropriate and removing them when they aren't as per the above), these
would be welcome.

As far as I can tell, this output shouldn't really be parsed anyways: it's only
intended for humans. Please feel free to ask on gnupg-devel how to
appropriately do what you are trying to do.

Thanks.

I was actually wrong (my French is too rusty) "phrase" is a French word.

The non-breaking spaces are contained into .po translated files for French and
Czeck languages for GnuPG-2. If you don't agree well then I'd recommend
consistency across all .po files, using non-breaking spaces also in other
translations and specify this choice in GnuPG's documentation.

Either way I'd be happy to contribute myself a patch for this issue, on top of
current git HEAD.

Just run a search about "non-breaking space" and you'll see. Now I'm wondering why
you are asking: is that non-breaking space meant to be there? in case yes, I'd be
curious about the case it serves. I just quickly assumed it is a bug. Ciao

works fine with gnupg 2.1.6 and pc/sc.

You say that this creates all kinds of problems, but you one cite one case,
which is a fixed bug in zsh. Can you give me a few more examples so that I can
better understand the problem and decide on the best solution. Thanks.

The fixes are included into 2.1.6.
Please test GnuPG 2.1.6.

So the implication here is that users who want to use XDG_RUNTIME_DIR can do:

echo '%Assuan%' > ~/.gnupg/S.gpg-agent
echo '${XDG_RUNTIME_DIR}/S.gpg-agent' >> ~/.gnupg/S.gpg-agent

and it will Just Work for those with an NFS homedir?

Even on non-NFS volumes, this has the nice property that gpg-agent's
"check-own-socket" feature should be able to close down the gpg-agent process
when it's no longer needed by an active session.

What would the failure conditions be if that variable isn't actually set,
though? I guess it would be the same as specifying /S.gpg-agent, which should
result in permission denied, which means a failed gpg-agent. Is that right?

Will 1.4.x or 2.0.x respect such a redirection if they find it in the socket
they're trying to talk to, or is this a 2.1.x-only feature?

I see now I meant to use gpg -u "TestKeyPub MRG App Key 2017"
and not -r.

Probably already fixed.

Indeed the first is a regression in 2.1. Fixed with commit 010e428.

The second is not supposed to work with --with-colons. GPGME uses
--list-options show-sig-subpackets="20,26"
instead.

I've now pushed my version of this patch.

I've now pushed this patch.

Done with commit 9bca96d. Here is how to use it:

  $ gpg-connect-agent 
  > passwd --verify 2C1103C5C84AAD061B5E3221C048A93D878F7EEE
  OK
  > passwd --verify 2C1103C5C84AAD061B5E3221C048A93D878F7EEE
  ERR 83886179 Operation cancelled <Pinentry>
  > passwd --verify 2C1103C5C84AAD061B5E3221C048A93D878F7EEE
  ERR 67108875 Bad passphrase <GPG Agent>

For the OK I entered the correct passpharse, for the bad passpharse I entered a
bad passphrase three times in a row.

PS: The second problem is persistent if GPG4Win is installed or not. But
knowing how to handle it, I think it's no real problem.

Hmm, let's see:

GPG with GPG4Win installed (I indented it a bit):

% gpgconf --check-programs
gpg:GPG for OpenPGP: C%3a\Program Files (x86)\GnuPG\bin\gpg.exe:1:1:
gpg-agent:GPG Agent: C%3a\Program Files
(x86)\GnuPG\bin\gpg-agent.exe:1:1:
scdaemon:Smartcard Daemon: C%3a\Program Files
(x86)\GnuPG\bin\scdaemon.exe:1:1:
gpgsm:GPG for S/MIME: C%3a\Program Files (x86)\GnuPG\bin\gpgsm.exe:1:1:
dirmngr:Directory Manager: C%3a\Program Files
(x86)\GnuPG\bin\dirmngr.exe:1:1:
pinentry:PIN and Passphrase Entry: C%3a\Program Files
(x86)\GnuPG\bin\pinentry-basic.exe:1:1:

after the deinstallation of GPG4Win:

gpg:GPG for OpenPGP: C%3a\Program Files (x86)\GnuPG\bin\gpg.exe:1:1:
gpg-agent:GPG Agent: C%3a\Program Files
(x86)\GnuPG\bin\gpg-agent.exe:1:1:
scdaemon:Smartcard Daemon: C%3a\Program Files
(x86)\GnuPG\bin\scdaemon.exe:1:1:
gpgsm:GPG for S/MIME: C%3a\Program Files (x86)\GnuPG\bin\gpgsm.exe:1:1:
dirmngr:Directory Manager: C%3a\Program Files
(x86)\GnuPG\bin\dirmngr.exe:1:1:
pinentry:PIN and Passphrase Entry: C%3a\Program Files
(x86)\GnuPG\bin\pinentry-basic.exe:1:1:

From within the GPG4Win folder:
weber in /c/Program Files (x86)/GNU/GnuPG [13:26:16]
% ./gpgconf --check-programs
gpg:GPG for OpenPGP: C%3a\Program Files (x86)\GNU\GnuPG\gpg2.exe:1:1:
gpg-agent:GPG Agent: C%3a\Program Files (x86)\GNU\GnuPG\gpg-agent.exe:1:1:
scdaemon:Smartcard Daemon: C%3a\Program Files (x86)\GNU\GnuPG\scdaemon.exe:1:1:
gpgsm:GPG for S/MIME: C%3a\Program Files (x86)\GNU\GnuPG\gpgsm.exe:1:1:
dirmngr:Directory Manager: C%3a\Program Files (x86)\GNU\GnuPG\dirmngr.exe:1:1:

The old scdaemon could be some problem with the setup - I had 2.1.13 installed,
but before filing this bug-report, I used the installer from gnupg.org to udpate
to a current version to re-check the behaviour.

But I think I may have two separate problems here now:

• "Unknown IPC command" on recv-keys (from cmd and zsh) - it seems I can't

reproduce this after reinstalling GPG4Win. Maybe my environment was screwed up
without me noticing it.

• "Unknown IPC command" on gpg-connect-agent <command> /bye (only in zsh) -

this seems to be persistent, but I just noticed if I add an empty argument
between the command and the /bye, I don't get the "Unknown IPC Command".
Which means gpg-connect-agent '' /bye works flawlessly. Maybe something to do
with MSYS2 or zsh.

Sorry for being such a weird case xD

Sorry, I only noticed the properties page and I never use teh task manager
(sysinternals Process Epxlorer is much more useful). The different version
number of scdaemon is an indication that an older version is still installed or
at least running.

To see GnuPG's idea of the installed programs you can use

  gpgconf

or to actually test whether they are installed:

gpgconf --check-programs

It's the running process information from the task manager (right-click the
running process, properties) - I would be astonished if Microsoft would screw
even that up.

Just for testing it, I reinstalled GPG4Win:

% gpg-connect-agent 'getinfo version' /bye
D 2.1.5
OK
ERR 67109139 Unknown IPC command <GPG Agent>

% gpg --version
gpg (GnuPG) 2.1.5
[...]

% gpg-connect-agent --version
gpg-connect-agent (GnuPG) 2.1.5
[...]

% scdaemon --version
scdaemon (GnuPG) 2.1.3

So it is using the right executables for gpg-agent, gpg-connect-agent and gpg,
but as long as GPG4Win is installed in another directory, it fails on some IPC
Commands..
Scdaemon seems to be 0.0.2 versions behind, which irritates me a bit. But it's
definitely not the one from GPG4Win.

Values from within the GPG4Win directory:

weber in /c/Program Files (x86)/GNU/GnuPG [13:09:03]
% ./gpg2.exe --version
gpg (GnuPG) 2.0.27 (Gpg4win 2.2.4)

% ./gpg-agent.exe --version
gpg-agent (GnuPG) 2.0.27 (Gpg4win 2.2.4)

% ./scdaemon.exe --version
scdaemon (GnuPG) 2.0.27 (Gpg4win 2.2.4)

% ./gpg-connect-agent.exe --version
gpg-connect-agent (GnuPG) 2.0.27 (Gpg4win 2.2.4)

The screenshots show the program but not the running process. It is quite
possible that the older one is still running. If that happens again, please run

  gpg-connect-agent 'getinfo version' /bye

to show the version of the running gpg-agent.

Oh, and thanks overall for making me uninstall GPG4Win :)

Yes and no.
The gpg-agent process running was definitely the 2.1.5 version (see screenshots).

But nontheless, uninstalling GPG4Win solved the problem.

On a sidenote: I had installed GPG4Win solely for the purpose of using it's
pinentry, as it was playing along with my SmartCard-Reader better than the GnuPG
version (pinentry on the device vs on screen) - but somewhere in one of the
later updates, the GnuPG-Pinentry seems to have caught up - everything works now
with just one installation - thanks :)

It is very likely that you are running an older gpg-agent (from gpg4win ?) which
does not support GnuPG 2.1. Please de-install gpg4win first.

Pushed as 5e1a844. Thanks.

Ok now I found kbxutil and learned about ephemeral certificates (Yep reading
helps) ;-)

After the first import kbxutil lists the Root certificate three times.
Twice with ephemeral flags, once without. So gpgsm -k shows it only once. But
kbxutil --find-dups already lists those duplicates.

fpr=11:B9:1B:31:EE:09:E0:84:4D:25:4E:58:7A:65:CE:51:84:F3:6B:70 recno=5 7 8
fpr=98:2D:D4:1D:BE:91:EE:72:B3:B8:43:33:F2:21:F7:74:64:39:08:7E recno=2 4 6

Now after the verify gpgsm takes the first of those certificates and unsets the
ephemeral flag as it was used as part of a complete trustchain. (sm/certchain.c:

If the first certificate was ephemeral we now have two certificates that are not
ephemeral but are the same and gpgsm -k shows both.

My solution is to check in keydb_store_cert for ephemeral certificates and
instead of inserting those again without the ephemeral flag to remove the
ephemeral flag of the existing certificate.

It's still unclear to me though why there were three certificates (Two ephemeral
and one normal) I would have expected one ephemeral and one normal certificate.

Patch attached.

D287: 648_0001-sm-Fix-cert-storage-for-ephemeral-certs.patch

I'll second this report, note that I noticed this change in behaviour
when migrating from Wheezy to Jessie and from gnupg2
2.0.25-99intevation2 to 2.0.26-6

More details copied from gnupg-devel@:
----------Original Message----------
From: Bernhard Reiter <bernhard@intevation.de>
Sent: Tuesday 23 June 2015, 16:21:54
To: gnupg-devel@gnupg.org
Subject: trustdb calculation very slow (gpg2.0 vs gpg1)

Hi
on a Debian GNU/Linux Jessie system I have a defect that
the trust calculation of a cert is taking a lot of time.
Almost 2 minutes with 100%cpu.
This used to be different with early gnupg2 versions I've used
and it is different to gpg (1), where it were 20 seconds.

No report found, thus seem to depend on my trustdb.
Any ideas on how to create a good report/debug?

Details:
How to recreate:
gpg2 --delete-key 52D717F3
time LANG=C gpg2 -v --recv-keys 52D717F3
real 1m57.144s
user 1m46.560s
sys 0m9.296s

as compared to gpg verison 1

gpg2 --delete-key 52D717F3
time LANG=C gpg --recv-keys 52D717F3
real 0m19.840s
user 0m18.192s
sys 0m0.900s

ii gnupg 1.4.18-7 i386 GNU privacy guard - a free PGP re
ii gnupg2 2.0.26-6 i386 GNU privacy guard - a free PGP re

With 2.0.25-99intevation2 on Wheezy I did not notice the issue,
but of course, my trustdb changed over time.

----------Original Message----------
From: "Dr. Peter Voigt" <pvoigt@uos.de>
Sent: Tuesday 23 June 2015, 23:35:14
To: gnupg-devel@gnupg.org
[..]

I am just having a fully configured VirtualBox VM of Jessie with Gnome
3 available, but I am not having this problem:

% time LANG=C gpg2 -v --recv-keys 52D717F3
...
LANG=C gpg2 -v --recv-keys 52D717F3 0.11s user 0.06s system 7% cpu
2.304 total

% dpkg -l gnupg2
Desired=Unknown/Install/Remove/Purge/Hold

Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

Name Version Architecture
Description

+++-

ii gnupg2 2.0.26-6 amd64 GNU
privacy guard - a free PGP replacement (new v2.x)

---------Original Message----------
From: Bernhard Reiter <bernhard@intevation.de>
Sent: Wednesday 24 June 2015, 09:17:35
To: gnupg-devel@gnupg.org

On Tuesday 23 June 2015 at 23:35:14, Dr. Peter Voigt wrote:

I am just having a fully configured VirtualBox VM of Jessie with Gnome
3 available, but I am not having this problem:

thanks for trying to reproduce!
As your result is showing as well:
It probably depends on my .gnupg data like the contents of my trustdb,
private keys and settings.

Of course I cannot just make this available,
so I am grateful for hints to find out more about the issue.

I could try to export, delete and reimport the trustdb, but because
gpg 1.4 works on it a lot better I assume that it is not a simple structural
problem of my trustdb. (Which I hope both gpg versions would detect.) So I am
not sure, if this is a good step to take.

----------Original Message----------
From: Pedro Coelho <pedro.msac@gmail.com>
Sent: Friday 19 June 2015, 14:55:41
To: gnupg-devel@gnupg.org
Subject: Issue 1998 Extended and Composed Characters on password.

Hi ,

Sorry to come up again with the same issue.
I posted some weeks ago an issue about gpg that I have detected while
working with gpg on Multiple/Cross systems.

This was passed to the bug tracking system as T1998.
I do not seem to be able to reply/follow-up on the bugtrack system so I
hope to contribute in here for the same issue.

I have tested to encrypt a file with a password that as several types of
characters, ascii, extended and composed.

As stated in the previous email listed below:

T1998

I was able to narrow down the problem to Composed Characters on the
password.

That is if one uses extended characters like the ones resulting from using
<altgr> or <altgr>+<shift> and try to decrypt the file on a different
OS/Computer, obviously the same keyboard layout must be present.
If the characters showing up on the CLI are the same as the ones used on
the password ... no problem for gpg to work correctly.

I made some tests passing the same file to Multiple Distros installed and
reached the conclusion that extended character support is not always
reliable to say the least ... but it can work.
For instance on Centos7 minimal with the exact same keyboard layout the
characters shown on display are not the same as in my default OpenSuSE 13.2
or Ubuntu. But once they are found gpg can decrypt the file.
That is an issue not of gpg but rather of the available mappings an Locales
on those particular systems. One as to simply be advised for those issues
in case of using gpg in multiple environments.

But problems do not stop there.
I have narrow down the problem of the decrypt bad key error to the Composed
Character.
If one uses composed characters problems keep showing up.

I used on the Same PC two sessions: One normal OpenSuSE KDE environment,
the other LXDE environment.
I noticed that on the LXDE session when using extended altgr/altgr+shift
chars I was able to decrypt my file.
The problem came about when dealing with Composed characters ... those
where a Symbol and a regular Character are composed.
Those who write in English most likelly never used such characters ... like
ã or õ. (don't even know if they even display correctly on your email
reader ... )

Those are a problem since in different systems Even with the same Locale
keyboard layout and Locale the use of a single composed chars can be
"misinterpreted".
On pinentry I've also seen for example when trying to enter a composed
character the box showed a double entry ...two chars (asteriscs) instead of
one ...

So this may indeed be a OS/Locale problem rather then a gpg problem ...

We can already do a dummy signature, but it feels sloppy for several reasons:

• it's not clear exactly what to sign with a dummy signature -- should you sign

static text or a dynamic (random) block?

• it's not clear what to do with the signatures after creation. It's

concievable that a dummy signature could be abused/misused if the material being
signed turns out to have some other meaning.

• gpg-agent can be configured to log to an append-only file as a means of

monitoring what signatures have ever been made by a given key. Dummy signatures
introduce spurious signing events that are indistinguishable from real
signatures in this log

• the creation of arbitrary signatures takes more time than testing passphrase

and returning feedback.

Why not doing a dummy signing then?

Thr redirect feature has not yet been documented. You can create a regular file
with the name of the socket file using this format

   %Assuan%
   socket=NAME

   where NAME is the actual socket to use.  No white spaces are
   allowed, both lines must be terminated by a single LF, extra lines
   are not allowed.  Environment variables are interpreted in NAME if
   given in "${VAR} notation; no escape characters are defined, if
   "${" shall be used verbatim, you need to use an environment
   variable with that content.

   The use of an absolute NAME is strongly suggested.  The length of
   the file is limited to 511 bytes which is more than sufficient for
   that common value of 107 for sun_path.

For PC/SC, it is confirmed with GemPCPinpad SmartCard Reader on Debian GNU/Linux.
Fix is applied to the development repo.
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=5e1d2fe6555d06f9dcd2daac713b2edfbc0428a5

I believe that this fix finally resolves the issue.

and to be clear, I'm not suggesting not using ~/.gnupg at all anymore. I'm only
saying that using that as a default location for gpg-agent socket is bad for some
use-cases (like nfs $HOME)

what is this "redirect feature" you mention? how would that help a user logging
into multiple computers using the same (nfs) $HOME ?

scd-change-st-2000-20150619.diff doesn't seem to fix PC/SC - it only
works when PC/SC daemon is not running (and therefor gnupg's internal
CCID driver is used).

I've tested this again and again the problem was no longer visible.

So I ran the following script for some time:

    export GNUPGHOME=$(mktemp -d)
    echo 11B91B31EE09E0844D254E587A65CE5184F36B70 S > $GNUPGHOME/trustlist.txt
    echo disable-crl-checks > $GNUPGHOME/gpgsm.conf
    gpgsm --import aheinecke.der > /dev/null 2>&1
    gpgsm --verify testsig > /dev/null 2>&1
    if [ $(gpgsm -k | grep 0x84F36B70 | wc -l) = "2" ]; then
        echo bug >> bugs
        echo bug
    else
        echo nobug >> nobugs
        echo nobug
    fi
    rm -r "$GNUPGHOME"

This resulted in 85 "bug" and 31 "nobug" entries. Entries were also always in a
row. Like 10 "nobug" followed by 30 "bug" situations and then again 5 "nobug".

Probably related to system I/O.

Werner do you need me to provide more information here or can you reproduce this?

Using ~/.gnupg as gnupg's home directory predates XDG by many years and thus
would be an incompatible change. NFS is not a problem due to thre redirect feature.

Werner:

The primary issue here isn't whether the dialogs should be model, but whether
they require the immediate attention of the user. Messages that don't require
the user's immediate attention should be shown asynchronously as notifications.
One-button dialogs are generally notifications, since they don't actually give
the user any choice. If a one-button dialog does require a synchronous
interaction then it is probably a bug.

Consider the bad passphrase case (and let's ignore the rest, since they are not
relevant to this issue). If we are not enforcing passphrase constraints and the
user enters a bad passphrase, then it makes sense to show a dialog. The user
has two options: "Enter a new passphrase" and "Take this one anyway"; GnuPG
needs more information from the user before it can continue.

If we are enforcing the passphrase constraints, then we currently show a dialog
with a single option: continue. The dialog is informational. However, the
dialog can't be shown as a notification: the user needs to know why he or she
needs to redo the enter-a-new-passphrase step. A background notification is
insufficient. The assertion is that this is actually a bug. This information
can be better shown in the enter passphrase dialog. That's exactly what this
patch does.

Do you agree with this reasoning? Can I apply this patch?

Thanks,

Neal

FWIW, there are 3 different use cases:

• Prompts about failed passphrase constraints: They do not need to me modal
• The prompt "Please insert card with S/N XXX" is really a notification and even gpg-agent will dismiss it w/o user interaction: No need to be modal
• "An ssh process requested the use of key ... please confirm" should IMHO be modal because it has the same purpose as entering a passphrase.

On 06/19/2015 04:13 PM, asdil12 via BTS wrote:

For the pinpadtest script case (without the --add parameter) it actually asks
for the pin, but when I press enter to confirm, the retry counter is decremented
and the stacktrace is shown.

For the pinpadtest script case (without the --add parameter) it actually asks
for the pin, but when I press enter to confirm, the retry counter is decremented
and the stacktrace is shown.

D308: 646_scd-change-st-2000-20150619.diff

I think that:
(1) When all correct, it works well (patched case)
(2) When it's mostly correct but problem with length, it doesn't work (no prompt
to user) and retry counter is decremented. (pinpadtest script case)
(3) When it's bad, it doesn't work and retry counter keeps its value (current gpg)

Here is current patch. This includes change for PC/SC.

Also an interesting fact: the pin retry counter is only decremented,
when using your python script for testing - not when using gnupg.

I narrow this down to commit: 23d2ef83cda644c6a83499f9327350d3371e8a17
Author: Werner Koch <wk@gnupg.org>
Date: Wed May 20 16:13:55 2015 +0200

agent: Cleanup caching code for command GET_PASSPHRASE.

* agent/command.c (cmd_get_passphrase): Read from the user cache.
--

We used to read the passphrase with mode CACHE_MODE_NORMAL but we put
it into the cache with CACHE_MODE_USER.  However, agent_get_cache does
not yet distinguish between them and thus this does not change
anything.

The last fix was wrong and the reaper thread closed a reader object which was
still used by another thread. Fixed with commit c971983:

I assumed that the log_fd also has a reader object but that reader
object is used for stdout and needs to be closed by the consumer.

The real bug with the non-released ldap_wrapper control objects was
that when looping over distribution points we did not closed the used
reader object before the next iteration.  Now, the test case had more
than one DP and thus we lost one reader object.

I traced agent/cache.c:agent_get_cache. The entry is in the cache, but its
cache_mode (CACHE_MODE_ANY) does not match cache mode (CACHE_MODE_USER) and thus
the password is not used:

  p *thecache
  $10 = {next = 0x0, created = 1434627188, accessed = 1434627188, ttl = -1, 
    pw = 0x7f94b4001d80, cache_mode = CACHE_MODE_ANY, key = "2"}

  (gdb) p !strcmp (r->key, key)
  $15 = 1
  (gdb) p r->pw
  $16 = (struct secret_data_s *) 0x7f94b4001d80
  (gdb) p ((cache_mode != CACHE_MODE_USER && cache_mode != CACHE_MODE_NONCE) ||

r->cache_mode == cache_mode)

$17 = 0

I'm sorry for the many mistakes.

In the commit message wouldn't it be:
"If FAILED_CONSTRAINT is not NULL and OPT.ENFORCE_PASSPHRASE_CONSTRAINTS is
TRUE, ..."

Werner:

Some brief background: the Gnome people want one-button confirmations to appear
as notifications, which can be dismissed asynchronously. This patch changes the
passphrase constraint violation 1-button confirmation (when
enforce-passphrase-constraints is set in gpg-agent.conf), which should be
displayed as a synchronous dialog, to instead be an error text displayed with
the next password prompt. Independent of what one thinks of notifications, I
think this change is a usability improvement.

D311: 644_0001-Show-passphrase-constraints-errors-as-password-promp.patch

A few comments:

The special casing is take_this_one_anyway2 is wrong. Instead, in
check_passphrase_constraints, if failed_constraints is not NULL, we just
shouldn't call check_passphrase_constraints.

You also removed a translation.

You didn't update the copyright year.

You didn't include a signed-off-by line.

I've created a new patch.

amd64
libgcrypt 1.6.2
libksba 1.3.4-beta1

Btw. If I roll back your commit the crashes no longer happen.

As an additional note. From checking why dirmngr takes so long in my setup I
know that I have several certificates in my keyring where the CRL is not
available. Maybe thats part of the problem.

x86 or amd64 ?
libgcrypt version?
libksba version?