I suggest to report this to the mintty developers.

The problem itself has been fixed. Please open another bug for the UX problem.

We wont fix that because it has been fixed in 2.1 and backporting make no sense
given that an easy workaround is available.

Please given an example.

I am not sure about which code part you are talking. Please can one of you
explain. If this is what I assume, please have a look at commit 25f0f05.

FWIW, we do not copy to create the backup but use atomic renames:

  lock(pubring.gpg.lock)
  read(pubring.gpg) -> process -> write(pubring.tmp)
  rename(pubring.gpg, pubring.gpg~)
  rename(pubring.tmp, pubring.gpg)
  unlock(pubring.gpg.lock)

Thus the worst case is that another non-updating process sees no pubring.gpg
during the time between the two renames.

Note that under Windows we don't have inodes :-(
See also T2135 .
As I remarked several times in the past the only solid way to handle these
problem is to allow access to the keyrings only via a dedicated processs.

We have never seen a real-world bug here. Thus I change this to a minor-bug.
You solution is not that easy becuase we need to maintain that order for all
time and we can't cope with older gpg versions which are still in use on the
same ~/.gnupg - they would have a different lock order and that would indeed
lead to a deadlock. As of now this is mitigated by all gpg versions using the
same config file and thus the same order of keyrings.

Fix will be in 2.1.11. Thanks for testing.

I have pushed chnages to master to fix this problem. One drawback is that
during an import another process "gpg -k" may rarely see no keys at all. A full
fix would either require that we lock the keyrings during all read-only
operations, which would severely hit on the performance of all common
operations, or change the whole system to use a new key access daemon.

If this works the changes need to be backported to 2.0.

Actually this is a copy of the web site version. I fixed both versions. Thanks.

Please ask on the gnupg-users mailing list for help. This is a bug tracker and
not a help forum, sorry.

It would be different issue, but we have similar problem for 'fetch' failure
with an error message like:

gpg: key B00DC692: rejected by import filter" followed by "gpg: Total number
processed: 1

Finally, I confirmed the problem. Sorry for taking long time. My understanding
was bad. I'm going to fix this.

OK, thanks for the response Werner. Perhaps this bug then is to update the website
docs to reflect what I gather may be big changes to this feature as compared to earlier
gnupg releases.

It seems that everything that can be found here (the best source I have found for using
gnupg w/ DNS) is now outdated and will no longer work:
http://gushi.org/make-dns-cert/HOWTO.html

I wanted to learn more about the new changes but I was only able to find the following
references which I'll document here in case someone else comes across it.
Unfortunately, I won't be able to test out the new method as I don't run my own bind
server and like many of us rely on a DNS provider that doesn't allow me to create the
form of DNS record output by --print-pka-records.

I only found three references to the new '--print-pka-records':

2.1.3 Announce:
https://lists.gnupg.org/pipermail/gnupg-announce/2015q2/000365.html

"* gpg: New option --print-pka-records. Changed the PKA method to use

   CERT records and hashed names."

gnupg docs:
https://www.gnupg.org/documentation/manuals/gnupg/GPG-Input-and-Output.html

"--print-pka-records
Modify the output of the list commands to print PKA records suitable to put into DNS
zone files. An ORIGIN line is printed before each record to allow diverting the records
to the corresponding zone file."

And finally an announcement from you in gnupg-devel from last year where you state that
all of the old functionality for PKA has been removed and replaced with something
entirely new (which is just for key 'validation' and not for key installation?):
http://marc.info/?l=gnupg-devel&m=142488047809150&w=2

That website is outdated. The format of the PKA records changed. Use

gpg --print-pka-records -k <userid>

to create a record.

You also need to build gnupg with a proper DNS resolver library and make sure
that you are using the matching dirmngr version.

For further questions please resort to the gnupg-users mailing list so that
others may help or learn from the replies.

That is no bug. gpg clearly states this. The factory reset is an optional
feature of the OpenPGP card specs.

D343: 751_0001-doc-Fix-typo-gen-full-key-in-whats-new-in-2.1.txt.patch

Here's a patch produced with git format-patch.

the OS shows ld is resolved to GNU ld:
$ which ld
/home/alelai/binutils-2.25/bin/ld

not sure why configure script pick up the ccs version.
I tried:
export LD=/home/alelai/binutils-2.25/bin/ld

configure shows:
...
checking if the linker (/home/alelai/binutils-2.25/bin/ld) is GNU ld... yes
...
(please see the attached new config.log.20160107)

But the error occurred:

Assembler:

"/var/tmp//ccFCDwOq.s", line 25 : Syntax error
Near line: " addl $(Loop-L0-3),%eax"

Makefile:590: recipe for target 'mpih-add1-asm.lo' failed
make[2]: * [mpih-add1-asm.lo] Error 1
make[2]: Leaving directory '/home/alelai/libgcrypt-1.6.4.src/mpi'
Makefile:477: recipe for target 'all-recursive' failed
make[1]: * [all-recursive] Error 1
make[1]: Leaving directory '/home/alelai/libgcrypt-1.6.4.src'
Makefile:408: recipe for target 'all' failed
make: *** [all] Error 2

Sorry, I can't see any problem here.

The "priotr-old" key is actually the newer key because an expiration date was
added to that copy of the key (2012-07-09) and that key has meanwhile expired.
Thus you can't encrypt using this key.

When you import the "piotr" key that is actually the same key but w/o the update
with the expiration date. Thus gpg does not chnage the exiting in key because
the existing key has a newer self-signature (where the expiration date is
stored) than the new key. So nothing changes, which is correct.

If you delete the .gnupg directory you don't have the newer key and by importing
the key w/o the expiration date you can encrypt to that key.

Great to hear that! And again let me Thank YOU for your incredible patience and
assistance with logs to help track down / fix this problem. This was really a
nasty bug.

After installing gpg4win 2.3.0 (GpgOL 1.3.0) I had no more crashes.
Thanks for your fix.

Same behaviour with gpg-2.1.10 (Arch), libgcrypt 1.6.4.

1.4.12 is heavily outdated (from 2012). Please update to 1.4.20 or at least
1.4.19 and check again.

No Kleopatra does not open the pubring. Let's leave kleopatra out of this.

This bug is about multiple GnuPG processes that conflict with each other. See
msg7466 for an example.

Do you mean Kleo opens the pubring file itself?

Commit e70f7a5 fixes this for 2.1.
Should be backported.
Thanks.

According to the posted config log this seems to be about
SunOS 5.10 on i86.

The extra option CC=-m32 is used with configure.

gcc versions is 5.2.
The linker is /usr/ccs/bin/ld, i.e. not GNU ld.

Duplicate of T1837

Closing this as noinfo.

Probably the same problem as handled in T1837

Sorry that there has been no response on this but we did not have time to work
on gpgOL.

GpgOL for Outlook 2003 is no longer maintained and support for this in gpg4win
is likely to be dropped soonish.

I'm closing this as nobug to help us clean up the bugtracker. The word editor is
not supported in Outlook 2003 and we will not add support for this. Sorry.

Uhm five years and not reply ;-) Sorry but we did not have much time to work on
GpgOL and the little time we had we spent on Outlook 2010 and later (which is a
different codebase)

The code for 2003 and 2007 is still basically unmaintained. We are looking into
the possibility to remove 2003 support and use the 2010 and later codebase for
2007, too. From your debug output it looks like you are using exchange. This is
not supported for the < 2010 addon. (It is supporeted in the current development
version that will be part of gpg4win 3.0.0)

So you can either switch to Outlook 2010 or later (and for now use the gpg4win
3.0.0 test version) ( https://wiki.gnupg.org/Gpg4win/Testversions ) or hope that
we will enable that codebase for 2007, too.

Sorry that I am marking this as nobug but we will not fix this for 2007 only and
in later versions it already works.

There are several reports about such problems. So far I'm unable to reproduce /
debug this. But we have to look into conditions that might cause this and at
least improve error reporting in these cases.

So far I can only think of that the UIserver socket file
(%APPDATA%\gnupg\S.uiserver) has permissions that kleopatra can not create it.

Renamed the issue to my current understanding of this problem. Locking on
Windows does not work properly.