Please write a proper bug report. Pasting some compiler output into the TITLE field is not a proper bug report we will look at.

should be useful to create such completion stuff. No context specific completion but this is imho anyway a misfeature.

Committed to both branches (master and 2.2), so, closing.

make shure you only use 2 registers !!! 32bit: eax, cl and 64bit rax, cl

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.

I've changed the text of this report from "filter" to "screener" to match the preferred terminology. thanks for the clarification.

[copied from gnupg-devel@]

I can replicate this even with master. Good catch.

I still consider the import screener (the term filter is used in a different way now) a big mess. Using the import feature to maintain the idea of a curated keyring is a bad idea because gpg has not been designed with this in mind. We spent so much time on this screener already and problems pop up again and again.

I think this is now resolved, as of rG926d07c5fa05

I am not proposing changing the order of the *hashed* subpackets in a signature. I'm proposing removing/changing/canonicalizing the *unhashed* subpackets in a signature. Sorry if i didn't make that clear enough in the initial message.

The problem here is that libkleopatrarc did not exist. The error could be nicer but I would say this is a downstream issue that packagers have to make sure libkleopatra-data is installed when kleopatra is installed.
I've opened a debian bug for this some time ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869647

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

But wait. Does my idea really help with comparing? I doubt it because a signature also includes a date and other variable stuff and thus they are already binary identical or it is a different signature.

Right we can't change the order of signature subpackets after they have been created. Given that we create subpackets by directly appending them to a memory buffer instead of keeping a list of subpackets to create, the least invasive method would be a function to shuffle that memory buffer right before the signature is computed.

I thoroughly agree that this is not required by the specs.

Do you mean this?

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

That is not required by the specs. Another way is to provide a tool to compare keys. That seems to be easier to me. Also consider the cases that there are new new packets or signature subpackets with unknown properties to the current implementations. What about different encodings in signed key material?

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 ?