This is especially important now that --no-grab is the default behavior of GnuPG Agent.

I now got something that works on MIME mail rENIG1cde116d7a3dadcd8ddd45ee1259cc62a4de9cd3. This patch leaves the original mail & decrypted version in the folder on the IMAP server.

Thanks. That reminds me again that a GPA release is due.

Given no feedback, I'm closing this issue.
If there is still problem, please reopen.

In T2919#102889, @stbuehler wrote:

I think bad.trace is very similar in the errors (chan_9 instead of chan_7); the difference is probably that the "bad mail" is not using a detached signature (possibly even encrypted), so mutt cannot find the body without actually decoding the message through gpgsm; the "good mail " is using a detached signature, and the body is the first part of a multi-part message which mutt can decode itself; it still can't verify the signature.

Sure: http://netbsd.gw.com/cgi-bin/man-cgi?getenv_r++NetBSD-current

I recall something about this on our mailing list.

Do you have the specs for getenv_r? I can't find such a thing on FreeBSD or Debian

I think bad.trace is very similar in the errors (chan_9 instead of chan_7); the difference is probably that the "bad mail" is not using a detached signature (possibly even encrypted), so mutt cannot find the body without actually decoding the message through gpgsm; the "good mail " is using a detached signature, and the body is the first part of a multi-part message which mutt can decode itself; it still can't verify the signature.

Sure. Here's the stdout and stderr for gpgme-1.9 with GPGME_DEBUG=9 and

In T2919#102001, @stbuehler wrote:

I just had a look at good.trace and it seems gpgsm --server exits instantly (chan_7 <- [eof]). The path seems to be correct though (/usr/pkg/bin/gpgsm), and /usr/pkg/bin/gpgsm --version reads (the first 79 bytes):

gpgsm (GnuPG) 2.1.18
libgcrypt 1.7.6
libksba 1.3.5
Copyright (C) 2017 Free Soft

The --version call passes the full path in argv[0] (but the full path is always passed as first argument to execv, so it shouldn't make a difference).

Sadly it seems there is no error message from gpgsm, and also the exit code isn't shown. Maybe you could try running gpgsm --server manually; it should greet you with OK GNU Privacy Guard's S/M server * ready. An strace log might provide more insight why gpgsm --server fails.

In Fedora, they use this patch:
https://src.fedoraproject.org/rpms/libgcrypt/blob/6c13b08816b206b3ff2bab09fe55157cb3417fd1/f/libgcrypt-1.8.0-build.patch

Pushed for master.

IIRC, rfc2440 did not forbid partial length encoding for key-material so gpg could use that. rfc4880 limits partial length encoding to non-key-material which causes this error message.

Well, I'm able to reproduce this issue on Parabola. I was also get a different error when I turn off my vpn: `server indicated a failure```, but now I get the dns error again.

elonsatoshi@tyger ~> gpg -vvv --debug-level guru --search elonsatoshi@riseup.net
gpg: using character set 'utf-8'
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /home/elonsatoshi/.gnupg
gpg: DBG: chan_3 <- # Config: [none]
gpg: DBG: chan_3 <- OK Dirmngr 2.1.23 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.1.23
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear hkps://pgp.mit.edu/
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_SEARCH -- elonsatoshi@riseup.net
gpg: DBG: chan_3 <- ERR 167772876 Connection closed in DNS <Dirmngr>
gpg: error searching keyserver: Connection closed in DNS
gpg: keyserver search failed: Connection closed in DNS
gpg: DBG: chan_3 -> BYE
gpg: DBG: [not enabled in the source] stop
gpg: keydb: handles=0 locks=0 parse=0 get=0
gpg:        build=0 update=0 insert=0 delete=0
gpg:        reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0 good=0 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks
elonsatoshi@tyger ~> sudo rc-service openvpn stop
[sudo] password for elonsatoshi: 
 * WARNING: openvpn is already stopped
elonsatoshi@tyger ~> pidof openvpn
elonsatoshi@tyger ~> gpg -vvv --debug-level guru --search elonsatoshi@riseup.net
gpg: using character set 'utf-8'
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /home/elonsatoshi/.gnupg
gpg: DBG: chan_3 <- # Config: [none]
gpg: DBG: chan_3 <- OK Dirmngr 2.1.23 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.1.23
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear hkps://pgp.mit.edu/
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_SEARCH -- elonsatoshi@riseup.net
gpg: DBG: chan_3 <- ERR 167772876 Connection closed in DNS <Dirmngr>
gpg: error searching keyserver: Connection closed in DNS
gpg: keyserver search failed: Connection closed in DNS
gpg: DBG: chan_3 -> BYE
gpg: DBG: [not enabled in the source] stop
gpg: keydb: handles=0 locks=0 parse=0 get=0
gpg:        build=0 update=0 insert=0 delete=0
gpg:        reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0 good=0 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks

FWIW,
the issue might be related to a key form Gentoo, which was expired but was then later renewed (at least it is no longer expired).

I prepared Libgcrypt for the 1.9 series, thus feel free to merge your patches to master anytime you like.

It even worked now (few hours later) :

Well, I'd expect gpg not to alter my digest/compression preferences when changing my cipher preferences and vice versa. So if a user's going to have to lose his previously set preferences for a key in this manner because that's the only reasonably viable way of maintaining backwards compatibility, I think it would be appropriate to let him know beforehand and also suggest that he set it all up at once (as I've so described above) so that nothing is lost in the process.

The way the setpref command works is implementation specific and thus the OpenPGP standard is irrelevant here
.
Are you requesting a change in the behaviour of the setpref command? That would not be easy to implement for backward compatibility.

Can you please try 2.1.23 ? We might have fixed that already.

Go ahead and type your message ...

@aheinecke is completely right. I just copied from Outlook's "show source".

OK, thanks for the info.

Sorry for the delayed response. I am in fact on pinentry 1.0.0, and haven't tested master yet. Looking forward to the patch!

We now explicitly delete the body instead of relying on the fact that the Outlook MAPI to MIME conversion deletes the body. Somehow this worked in the past but no longer does. I could not bisect it as 1.4.0 showed the same problem but old test mails from July 2016 did not show the problem. Newer ones from August 2016 already showed it in the sent mails folder.