On Windows we copy the new file; on Unix we link-rename it. It might be worth
to change that old code to use estream and the same method for file updates as
we use elsewhere.

Justus: This is mostly about the test suite, can you please take care of this bug?

GnuPG 2.1 requires the agent and thus the Pinentry. --use-agent is thus a
no-op. The Pinentry can be replaced by the --pinentry-mode=loopback but I don't
think that this is a good idea.

2.1.17 along with pinentry 1.0 does much better error reporting for badly
configured system (e.g. an incomplete installed GCR when using pinnetry-gnome,
or a missing GPG_TTY for the curses fallback.)

Too much time has passed since I worked with Jeffrey to fix gpg problems in Evo.
I can't even remember whether Evo uses GPGME (which I would strongly suggest).
Anyway, Milan may ask for advice on gnupg-devel and I take care that the GnuPG
teams helps him to get things fixed. he might also chime in on gnupg-devel at
conference.jabber.gnupg.org

More info from our evolution maintainer Milan Crha:

I would rather like to see a fallback on the gnupg2 to instruct the caller that
the password is missing, like it does when gpg-agent is turned off (there was a
use-agent option in the past, maybe only in gpg1?).

The --passphrase-fd option works only with conjunction with --batch command in
gpg2, but the libcamel uses --batch only if no password is needed. There is used
the --command-fd to provide passwords, which worked for years. Really, the
problem is that gpg2 doesn't claim that it requires password, it simply fails,
because gpg-agent failed when it was supposed to ask for the password.

ping (see T2370 (wk on Nov 18 2016, 08:44 AM / Roundup))

D401: 931_0001-qt-Add-test-for-CryptoConfig.patch

Can you repeat this also with GPA, which uses the gpgconf for ages?

Yes, It's even more visible in GPA because according to the gpgme log GPA does a
list options right after the change. So e.g. If you check "quiet" in the gpg
options then hit apply the check box gets unselected after apply although the
config is changed. Log is similar to the ones attached. Change options is
visible but afterwards the list-options still returns the old value.

On Linux I could not reproduce it with gpa, but as I think it's a timing issue
that might be expected. Attached is a patch that adds a Qt test which exposes
the problem on Linux. I can translate that to plain C if it helps. But I think
the attached Logs are already obvious that there is an issue.

werner: Well... Doesn't it destroy libgcrypt's performance?

Jussi: would you be so kind and look at this problem?

The configure option --disable-asm might help.

See also T1001 for the reason why we use /bin/pwd .

Right, /bin/pwd defaults to -P but the shell internal may have a different
default. I checked autoconf and automake and they always use just pwd. The
shell code in our Makefiles should reflect this of course.

Can you repeat this also with GPA, which uses the gpgconf for ages?

This is a misunderstanding. 'delkey' only operates on public keys. I have
updated the documentation to make that clear.

Fixed in a76fe9e86d7802e67373218bd1759168585e92ab.

Unfortunately, it is currently not possible to delete secret subkeys while
keeping the secret identity key. You can use gpg --delete-secret-keys to delete
the whole secret key though.

This is by design.
The reason the encryption key is by default created off-card is too allow to
restore that key. For a signing key this is not important because it is easy to
create a new signing key. Decryption is more problematic because without the
encryption key on the card you won't be read older documents encrypted to your key.

Use gpg --edit-card and the then "keytocard" to restore a backupkey to a fresh
smartcard.

The problem still occured after the update of Libgcrypt, but Im pretty sure now
that I determine the origin of the problem. In the end it is somehow my fault: By
time I got more and more email accounts which are synchronized with offlineimap and
the passwords for each account are encrypted with gpg.
Offlineimap offers an option for multitheading, which synchronize the accounts in a
prallel manner. By changing to a strict serialized synchronistaion the problem
seems to vanish. My guess is, it was simply to much at once.
For those, who encounter the same problem try the '-1' option of offlineimap.

Thanks for your time and work (in general)!

Fixed in 3c7d6a1769ed6cc90d86247a814a0dce341512a3.

Thank you for your excellent bug report!

I can reproduce the problem with current git master. Using my regular homedir /
certificates. I was having that for some time now but did not notice as I
thought it was a bug in using old kmail with 2.1 and I rarely use S/MIME. For me
KMail always showed "encryption failed" for S/MIME but the pinentry came up. I
entered my pin and hit sent again and it worked because the agent had cached my
passphrase and pinentry would not come up ;-)

Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x000000000040fc65 in gpgsm_proxy_pinentry_notify (ctrl=ctrl@entry=0x1,

line=line@entry=0x68f548 "PINENTRY_LAUNCHED 14400 unknown 0.9.8-beta24") at

../../sm/server.c:1492
1492 if (!ctrl || !ctrl->server_local
(gdb) bt
#0 0x000000000040fc65 in gpgsm_proxy_pinentry_notify (ctrl=ctrl@entry=0x1,

line=line@entry=0x68f548 "PINENTRY_LAUNCHED 14400 unknown 0.9.8-beta24") at

../../sm/server.c:1492
#1 0x00000000004102da in default_inq_cb (opaque=0x7fffffffd990, line=0x68f548
"PINENTRY_LAUNCHED 14400 unknown 0.9.8-beta24")

at ../../sm/call-agent.c:197

#2 0x00007ffff747663c in assuan_transact (ctx=0x68f3f0, command=<optimized
out>, data_cb=0x443080 <put_membuf_cb>,

data_cb_arg=0x7fffffffd9a0, inquire_cb=0x4102b0 <default_inq_cb>,

inquire_cb_arg=0x7fffffffd990, status_cb=0x0,

status_cb_arg=0x0) at client.c:291

#3 0x0000000000410882 in gpgsm_agent_pksign (ctrl=0x1, keygrip=0x68bffc "",
desc=0x7fffffffd9f2 "", digest=0x68bffc "",

digestlen=20, digestalgo=2, r_buf=0x7fffffffdec8, r_buflen=0x7fffffffde18)

at ../../sm/call-agent.c:269
#4 0x00000000004179c2 in gpgsm_create_cms_signature (ctrl=0x7fffffffe0a0,
cert=0x6b2e20, md=0x69d650, mdalgo=2,

r_sigval=0x7fffffffdec8) at ../../sm/certcheck.c:430

#5 0x00000000004203e5 in gpgsm_sign (ctrl=0x7fffffffe0a0, signerlist=0x68f548,
data_fd=0, detached=1, detached@entry=0, out_fp=0x0)

at ../../sm/sign.c:707

#6 0x000000000040aa65 in main (argc=1, argv=0x7fffffffe230) at
../../sm/gpgsm.c:1798

I can easily provide more debug output.

Fixed in ca02a8b78fca8815388a859962584d75169ae3ee.

I'm going to write some documentation about the programmatic use of GnuPG.

Applied with commit 0a90f87799 to master. I will backport and release 1.7.5 today.

The Gentoo bug report for this has a
proposed fix, correcting a typo (EGAIN-

EAGAIN) in an autoconf script.

https://bugs.gentoo.org/show_bug.cgi?
id=602502#c5

@werner, have you looked into the patch?

AC_CHECK_FUNCS([mmap]) on Fedora fails to find mmap() due to missing -fPIC.
/usr/bin/ld: /tmp/ccvNyAcN.o: relocation R_X86_64_PC32 against undefined symbol
`mmap@@GLIBC_2.2.5' can not be used when making a shared object; recompile with
-fPIC

We have -fPIC somewhere in default CFLAGS, so just resotre user CFLAGS
before making checks for functions.

I'm glad that git has this fixed. Well, then the actual problem is that it is
broken in release.

Even being gentoo user, I cannot install gnupg from git easily (there's no live
ebuild for gnupg yet). So users will suffer from this until you make next
release and distros maintainers update packages.

So regarding functional tests for shell utils... Any suggestion how to arrange
that? Or would you review whatever I come up with?

I improved our test suite so that it detects this problem.

This is indeed a bug in libgcrypt. Thanks for the report.

/bin/pwd does produce the full name off the current directory, but it doesn't
canonicalize it, taking into account symlinks, the way $(readlink -f) does.
Thus, the comparisons may fail, and that's what happened in the case of our
build.

I just tried it with the current version from git and I see no real problems.
The only annoyance is that you need to enter the passpharse (or no passphrase)
for each subkey.

"Can you please compile gpg with debugging symbols"...

Sorry, I am not currently setup to compile GnuPG and all its dependencies and I'm not
even sure of the details as to how to go about doing so. As I mentioned I am installing
pre-compiled binaries compiled server side by the homebrew project which installs those
binaries.

I would imagine the GnuPG project has an OS X development machine to test/debug on. No?

If you have specific changes you would want me to make to the homebrew recipe I linked
to I can try to do that.

I just released Libgcrypt 1.7.4 - whcih should fix that bug.

No info recevied and thus closing. You should switch to 1.7 (and soon 1.8)
anyway. A lot of things have been fixed since 1.6.

FWIW, we do not see any problem with current Libgcrypt in our CUI system running
under Sierra.

Given that the patent expired I consider touching that comment not important.

Thanks for the feedback! Can you please compile gpg with debugging symbols, add
a break point on log_debug in string_to_ulong (in g10/tofu.c), and then do 'run
--verify ts.txt'. When you hit the breakpoint, please do a 'bt full', print out
the value of "string" and "tail" (using gdb's 'p' command), and repeat (continue
execution using 'c').

Thanks!

FYI, here is the homebrew formula that is used to compile GnuPG

https://github.com/Homebrew/homebrew-versions/blob/master/gnupg21.rb#L46

Hmmm. So since I filed this bug I happened to do a key transition so I started with a
brand new gnupg dir. So in trying to replicate this again I was starting from scratch.
I imported the key and downloaded the signed file from the gist I sent you. I still see
the same output! This leads me to wonder if there is something different about how the
tofu code compiles when installed on OS X via homebrew?? The gnupg installation didn't
change, but my whole .gnupg dir is new.

$ gpg2 --verify ts.txt
gpg: Signature made Wed Nov 23 23:08:29 2016 PST
gpg: using DSA key 0x6F3B2E6AB748A8F8
gpg: Good signature from "TrueTimeStamp <signing-department@TrueTimeStamp.org>"
[marginal]
gpg: DBG: tofu.c:2772: strtoul failed for DB returned string (tail=): Invalid argument
gpg: DBG: tofu.c:2774: strtoul failed for DB returned string (tail=): Invalid argument
gpg: signing-department@truetimestamp.org: Verified 1 signature in the past

0 seconds, and encrypted 0 messages.

gpg: Warning: we've only seen one message signed using this key and user id!
gpg: Warning: you have yet to encrypt a message to this key!
gpg: Warning: if you think you've seen more signatures by this key and user

id, then this key might be a forgery!  Carefully examine the email address
for small variations.  If the key is suspect, then use
  gpg --tofu-policy bad 83289060F40DED088CF246B56F3B2E6AB748A8F8
to mark it as being bad.

gpg: WARNING: This key is not certified with sufficiently trusted signatures!
gpg: It is not certain that the signature belongs to the owner.
Primary key fingerprint: 8328 9060 F40D ED08 8CF2 46B5 6F3B 2E6A B748 A8F8

In general a bug tracker is not a help line. Anyway, please describe you
environment (OS, NFS mounts etc) and give an exact description on what you did.

I tested with the GnuPG version 2.0.30 (GPG4WIn) as well as the current 2.1.16
Windows binaries. SCdaemon was running but was unable to get exclusive card access.
Why?
The Cisco Network Manager as well as Cisco Anyconnect VPN did both gain shared
card access (they were not told to do so!). I needed both programs to get access
to the university network.

Uninstalling both Programs and restarting did resolve the issue. To find the
two offenders I used Process Explorer (Processes for all users) and used the
Find Handle or DLL functon with the search term "SCARD". All crosschecked all
Processes (except for scdaemon which sould access the card) and Services
(svchost) to be only scdaemon aswell as the services to be Windows internal.
To determine the inital issue I used
https://sourceforge.net/projects/pcsctracker/ which told me the status of my
Yubikey (as Present,InUse -> Shared Access).

As a suggestion I like to see the experimental option to change the accessmode
from exclusive to shared on the commandline (If for example the other
application cannot be uninstalled).