You are right, this is a new feature that could be useful but is now in high demand and not a bug so Wishlist is more appropiate.

While trying to replicate your findings I might have found a but in the import code which rejected one of the keys (using gnupg 2.2). I'll take care of this.

According to our rules an initial set of tags should never be a milestone but be in the Backlog or, if work already started,in the WiP column. Because it is anyway invalid, I removed the tags.

T6536 has been fixed. With today's commits the Brainpool curves are now also flagged as compliant in gpgsm.

Now fixed in 2.2 and 2.4 (commits rG08f0b9ea2e955209d467f1ff624bf7abd10ae7ac and rG7661d2fbc6eb533016df63a86ec3e35bf00cfb1f). See also T6752

In T6637#177217, @jukivili wrote:

Yes, int8_t/int16_t/int32_t/uint8_t/uint16_t/uint32_t should not be used. There is size-specific integer types defined in src/types.h which can be used instead (byte/u16/u32). This header does not yet have signed integer types, but those can be added (for example, s8/s16/s32).

For the export of multiple certificates (i.e. not group export), this task is blocked by the wishlist issue T5847: Kleopatra: New Feature for bulk certify. Either this issue is also wishlist or the other issue is needs to become normal.

IMO for LDAP we should not warn at all. Because there it is possible to remove certificates.

In T6637#176910, @fse wrote:

OK, fine, however, in order to be able keep an overview of our tasks I would still keep track of them in our GitHub, where I can create a sub-issue from the list of tasks with one click. But we will post our comments and results here as well as far relevant for the purpose of documentation. I think most of the points Jussi raised are more or less clear to me anyway.

Yes, int8_t/int16_t/int32_t/uint8_t/uint16_t/uint32_t should not be used. There is size-specific integer types defined in src/types.h which can be used instead (byte/u16/u32). This header does not yet have signed integer types, but those can be added (for example, s8/s16/s32).

I opened T6771 for this because this issue is done.

In T6766#177137, @ikloecker wrote:

I haven't added the possibility to start a group certification directly from the confirmation message.

In T6767#177126, @werner wrote:

Should we have a gpg_error_from_w32() as companion to gpg_error_from_syserror() ?

According to Werner this should work.

In high contrast mode the background should always be white or black.

Well, see my very first comment.

That output was also misleading,. that was from before I added the ignore-crl-extension in there. I was confused because I still got the error:

So dirmngr already has that option.

Well, this bug is fixed by using a decent libgpg-error or configure it correctly.

At the moment we have a green background for the results of a decryption and/or verification, if it was successful.
This does not work with high contrast mode.

and it is also confusing that you can choose the key for signing in Kleopatra, it is displayed with a green check mark but then you run into an error:

yes, fixed

I think this was fixed with the fix for https://dev.gnupg.org/T6534

I have added the confirmation to the following commands:

• Export Certificate(s)
• Publish on Server
• Export Group