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:

Unfortunately, building without "--disable-asm" does not work if building a universal package under MacPorts (e.g. 32bit and 64bit x86 or 64bit x86 and arm64).

In T5268#142714, @gniibe wrote:

To do that, I'd like to know, when the symbol getentropy was added.

to explain a bit more: This report was opened after the reported defect was already fixed.
As we are getting many reports and technical suggestions, please keep the reports focused on one point only if possible
and open general discussion points about development improvements on gnupg-devel@.

Anyhow. Let us unrelate this from personal issues and just to be clean respect the content of the issue. Git links should not be promoted and cbiedl asked me today why we disagree because plain text protocols are really not state of the art. Cbiedl: You should be able to fix this it would be in the gnupg-doc branch afaik. If you have permission problems please let me know. I'll assign this to you.

Git repos are development only and developers need to find a way to establish some trust in the source before building it. All kind of mischief can happen with arbitrary sources. https does not help at all. You need to find a way to establish trust - how you do that is up to you. For example looking at signed commits and try to figure out whether you can trust this key.

For what it is worth we have also just tasked someone from our team to reinstate our buildbot / CI but this would likely not have helped in the current case of the libgcrypt buffer error as only ASAN with large hashtests would have found this. Still we have the general infrastructure for such tests we are just lacking resources. That is why we publish everything and encourage the community to at least help us with testing.

the issue regarding this self test was immediately found after release. Our development is completely open and everyone is free to run tests with our software on any platform at any time. We would respect and fix all those bug reports. None about this reached us during the development phase.
As this is not happening as it should during development we release and test on our platforms and build systems. When after the release others test, too we immediately fix the issues as happened with 1.9.1 in libgcrypt.

@werner, I cannot follow you. What exactly do you mean?

A public keyblock without a user id packet is non-compliant. I see no reason to provide a feature to created crippled data. We had all this discussions back in the early 90s regarding to self-signatures. OpenPGP spoke a final word on this in 1998 by making user ids and corresponding self-signatures mandatory.

Not exactly the answer I was hoping for..

Oops, that was an experimental feature never intended for a released version. Will be removed in a way that it does not leas to compile problems - just to be extra cautiousness.