Won't be done because the expectations of users are different on whether they use ssh-agent or gpg-agent. And it breaks scripts

I would not all this an accident.

The now used /var/run thingy solves all these problems nicely. In fact we may eventually remove the use fallback of using sockets in the GNUPGHOMEDIR.

We have the --unwrap option which already does this. The problem here is that an addition compression layer is not removed. Therefore I will rename this report to add a feature strip things down to a signature or literal data packet..

Eventually we will move to keyboxd which is already an experimental option in 2.3. Thus we won't do anything here.

The gpg-card is more flexible than the old gpg stuff. If there is something missing we will add it over time but it does not make sense to keep this request open.

Due to better working timeouts we have mostly soolved these problems,. Further keyservers are not anymore of great use these days.

The other patches don't make sense because of future plans for dirmngr.

Critical attributes are well known from CMS and X.509 and some have a history which can only be described as cargo cult. We should not allow them in the OpenPGP ecosystem without giving them a specific semantic aside from "we do something with it".

Done. FWIW. in 2.3 symcryptrun will be removed entirely.

RFC 4880 says:

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.