If you create a file without -a the standard suffix will be .asc. But if you use -o FILE, just must give the full filename..

Just for information:
The gnupg version does allow .asc output.
As a workaround I created a batch file consisting of the lines

The new unified compliance checker was not initialized. Fixed in the 2.2 branch.

Fixed in master.

I'm fine with (and i totally understand) wanting nothing but UTC in the machine interface and internal representations.

I'm having the exact same issue, also Outlook 2016 and Beta 299.
[edit]
I want to add, my Outlook also often freezes by just changing the folder. Outlook will try to open a message when chaning the folder, but regardless if it's encrypted or not, Outlook might freeze.
I did not change any GpgOL default settings.

[copied from gnupg-devel@]

I can replicate this even with master. Good catch.

success, thank you for the help!

In GnuPG 2.1, secret keys are under control of gpg-agent. Currently, it is not deleted by gpg frontend.
Please run:

$ gpg -K --with-keygrip

The only mitigation I can see for this is a better error message.

I think any existing script that assumes UTC should add an explicit Z suffix. (that is, i don't think the breakage is a big deal, and anyone writing scripts that needs this kind of precision will be more likely be thankful that we have a sensible, normalized interface).

It is pretty much confusing. When a user specify in YYYY-MM-DD format with no hh:mm:ss, it is interpreted as local time (noon of that day).
When a user adding Thh:mm:ss, it is UTC.

While I confirmed that GnuPG interprets YYYY-MM-DDThh:mm:ss in UTC (which should be interpret as local time according to ISO-8601), I don't know how we can fix this.
If I change the interpretation of GnuPG (possibly supporting the format with Z suffix and timezone), it may break existing script which assumes UTC.

Bug confirmed in rGa766a37290cf: Print keyid in gpg --list-packets..

When Thhmmzz is specified, no adding 12 hours, that's the intention of the code, I suppose.
However, the implementation is wrong, since the beginning (not supporting "Z" or timezone for ISO-8601. interpret the string as UTC).
I will take that, too.

Is it possible that this is related to T3278 ?

I think that adding 12 hours by parse_expire_string make sense.
The test suite should be fixed.
I will.

fwiw, i agree that GnuPG should interpret these as ISO-8601 strings. At the very least:

Nice find, @gniibe ! So this looks like a bug either in GnuPG's test suite, or in parse_expire_string, right? How do you think it should be addressed?

In the log, I found:

Possibly, timezone (of build machine) matters.

Please try this patch:

Please try: rA87c2bb5708ff: We can't support fd passing, if the system doesn't support it.
It disables the particular test.

I think that file descriptor passing is not supported on Cygwin.
We should disable the feature of libassuan.

It will be in the next release (2.4.4).
Thanks for reporting.

The description of this bug report is not correct.
_POSIX_C_SOURCE should *not* be defined to use INADDR_LOOPBACK for the system.

With following files, I managed to emulate similar experiment. My intention is to replicate.

For me, I cannot replicate this issue with 2.1.20, either.

I tried to reproduce the problem with gpg-2.1.22 or later, but I couldn't.
What I did was:
(1) Prepare expired key of 2D182910, by removing three signature of current public key.
(2) Set "ultimate" trust with the key.
(3) Import current public key of 2D182910.

Let me explain the situation.

No, there isn't any error message or output, and it not accept any input.
Here is a GIF capture, but may not helpful.

@aheinecke thanks for your findings.

I suspect CRL / Root certificate fetching because it works after you once manually investigated the certificate chain through -> Properties -> Digital Signatures.

dirmngr is meanwhile an integral part of GnuPG. The old 1.1 dirmngr is entire obsosolete and won't do what gpg expects from it. To better diagnose the problem you can do this:

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.

I recall something about this on our mailing list.

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.

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

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).

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.

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