Works for me.

dirmngr needs to be killed for this. gpgconf --kill dirmngr.

Meanwhile we introduced the keyboxd which should solve such problems. It will be marked experimental in 2.3 but I expect that it will soon be used as the default way to store keys - at least under Windows.

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.

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.

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.

Thanks for the fix.

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.

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

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.

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..

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.

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.

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.

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.

I think that a backport to 1.8. also makes sense

Stick to your channels and get back after you have learned basic some basic developer workflows.

@hanno, this is a bug tracker and not yet another media for your rants.

Fix has been released. Keeping this in testing state for easier visibility of this task.

Release done.