D405: 934_libdns.patch

would this patch[0] be acceptable for inclusion in branch?

note from patch composer:

"""
Comment by Gaetan Bisson (vesath) - Friday, 23 December 2016, 07:22 GMT
So I came up with a fix that does two things:

• fallback on the old, standard resolver code
• if no SRV record is found, use CNAME (as expected but some weird error code

apparently broke this)
"""

[0] fetched from
https://git.archlinux.org/svntogit/packages.git/tree/trunk/libdns.patch?h=packages/gnupg

From my network, when I input:

KEYSERVER --clear hkps://oteiza.siccegge.de

It results the error, because the network to the host is unreachable.
It is likely that it is an error of the network or the server.
And --standard-resolver thing is fixed by my commit.

I think that this bug is related to libdns. Unfortunately, it is not
reproducible for me.

Well, somehow related, I pushed my change:

commit d26c51825e2255fe58305cbc1cd74fa43f80d93e

In my environment, compiling with --disable-libdns or --standard-resolver at
runtime for dirmngr, it works fine. Before the fix, I confirmed that it failed
with --standard-resolver.

I tested some more and found out problem is bigger than only move. Copy also
doesn't work, but save message as .msg or exporting to pst folder doesn't work
also. So it seems nothing can be done with message to save or archive it
somewhere else then orginal folder. Tried official stable version of gpgol, but
this has the same problems. Also tried this stuff on android with K9 client and
openkeychain, whereas these problems do not exist, it simple works as expected.

Thanks for the report.

This is fixed in commit 6e96cdd41a0e55b672309431062f37c4a4a9f485, but there is
no release with that version. Sorry for the inconvenience.

D402: 933_01-rijndael-ssse3-fix-compiling.patch

Attached patch should solve LTO problems with rinjdael-ssse-amd64.c.

'memcpy' problem seems to be because of bad interaction between -flto and
#pragma "no-sse". Strangely switching memcpy to buf_cpy solved problem, even
through buf_cpy itself just uses memcpy (on x86).

With this issue solved, I ran in to problem with rijndael-ssse3 assembly code
blocks going missing with -flto and link failing. So rest of the changes in
patch are for fixing lto visibility of assembly.

FWIW, I doubt that 2.1.17 fixes the issue. But, I've improved the debugging
out, so if you would try to reproduce the problem, it would still be useful.
Thanks!

2.1.17 has been released. I would suggest to try it first so that we do not
need to evaluate an older version.

Yes, sure.

That seems to be a regression due to commit 02eb9fc9d5863abcfed6af704e618f8cac7cc2e8

    If the user's CFLAGS include -Werror, then some configure tests fail.
    To avoid this, we only add the user's CFLAGS after all of the
    configure tests have run.

That patch was obviously wrong because configure now has a different picture on
the build system than make. A better solution to the -Werrror problem would be
to pass -Werror only to the make invocation - or more robust to add an
--enable-werror configure flag.

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.