Where should groups be listed? Should groups be listed in the main key/certificates view?

Added a first version of the UI. Key list still needs to be changed from a simple list view to the usual multi-column tree view.

We need more information on the why and when of this change. We don't want to maintain different versions of the same algorithm. The I-D expired more than 6 years ago and thus it should not be used as a reference.

POSIX says so (use printf instead).
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html

Without any defined semantic it is not proper to ignore a critical bit. The software which created this keyblock seems to aim for incompatibility.

iirc the advise from the GNU coding standards is to use printf(1) instead of trying to figure out how echo(1) works.

Thank you. I'll fix. Perhaps, I'll ignore old UNIXen like AIX 6.1, which has no way to echo with no newlines.

Thanks. Applied in rG4ca8ca5f7f58: po: Update Simplified Chinese Translation..

Thanks for the fix.

The problem ist not an "ugly error message" but it does not recognize that the e-mail IS encyrpted by Symantec-PGP! But the plugin always says:

Done all comments.

So 'out of core' actually means:

• run out of the memory resource, in other words, insufficient memory resources ?

Partly understand, so 'core' means 'core-memory', and for nowadays just 'memory'.

Here are my comments.

Problem with clang and these files was resolved by replacement of assembler macros with C preprocessor macros.

Actually I would be in favor of removing this portable thingy. It is and will always be the worst and most insecure way of using crypto.

Looks like this has been addressed in af23ab5c5482d625ff52e60606cf044e2b0106c8. A quick test building the current version in master with --disable-asm worked for me.

https://tools.ietf.org/html/draft-shen-sm2-ecdsa-02
Section 5.1.4.4

pubkey_cmp should be symmetric (pubkey_cmp(A,B) == - pubkey_cmp(B,A)), but it was not.

Oh well, a bit surprising but I agree that it works :-)

The 'what != NULL' case is handled by the "Strip trailing LF" part at the end of function. These data strings always end with '\n', so null-termination gets done there.

Actually I can't see why this is only a problem in the NULL case. if you select a specific config item the string might also not be 0 terminated - it depends a bit on the size of the used buffers. In 1.8 I applied this with the the if (!what) condidion.

I have to leave this as open as this describes a clear issue users expirience in our software. I assign it to me to keep an eye on the issue. Werner and me discussed this issue at length verbally and there won't be a quick fix for the stable branch but we will address this some time in the future, but then not only for 8bit but for full unicode.

The problem persists when using keyboxd which returns keys in a different order.

I mentioned it several times: It is not sufficient to use some wmain as long as we don't rework the entire spawn machinery in gnupg. libassuan and gpgme. Reading Unicode from the command line would be easy the other things are the real work.

And in fact it was never possible to use 8bit filenames on the command line. The result was not stable and led to non-compatible messages due to the use of native character set instead of proper utf-8. It depended on just too much things.
gpgme-tool or gpgme-json might be useful workaround.

You can use --multifile for this. This reads the filenames from a descriptor or a file. One on the reasons to implement Unicode handling at most places was a request to allow using --multifile as a workaound for the command line limitation..

Dear aheinecke, where can we find this file src/main.cpp in the install folder to correct it? I'm stuck as an admin on my computer enable to use Kleopatra

Please do not repeat you question, this won't give you anymore attention. Read my comment above and please ask on a mailing list etc.

Good morning,

Hi,
the accounts are Exchange Accounts in Outlook 2016, getting Data from an Exchange Server 2016.

So, the change against libgcrypt 1.9.1 will be:

I got hit of search by "$ld$weak$os10.11$_getentropy".
So, I guess that it's 10.11 which has _getentropy as weak symbol, and 10.12 or later has implementation.

There is some (partly) good news: The function getentropy() is available in the packet manager MacPorts. It has a legacy support: