Just adding this note because a next step I'm also evaluating in my current T5593 configuration status it to temporarily create a new Gpg4win 3.1.16 hybrid configuration by also adding latest GnuPG v2.2.31 to see if all issues I reported here are still present (which is also quite probable).
Also because of T5593 it would just be quite interesting to see if GnuPG v2.2.31 too might experience same T5593 path related error.

Hi Werner,

Sure they don't get created - they are optional.

Just tracking my own additional investigation still about past Werner statement "percent escaping is correct and required" when this bug was closed for 1st time.
Also found interesting past references into rG055f8854d3f4 and rGe064c75b08a5 but only this last seems indeed much more specifically directly involved since it really contains related part of code (common/stringhelp.c) directly involved with this bug report for 'percent escaping' ':' (colon) character with '%3a' string even if sometimes, when possibly un-needlingly done, may even provide users unexpected on-screen displayed results like those I documented in this bug.
Problem now is that to really fully understand why on-screen displayed strings by 'gpgconf --list-dirs' correctly show a ':' (colon) correctly expected character near an unexpected (by end users) '%3a' (percent escaped) string that should just have corresponded with another simple (& user correctly expected) ':' colon character I can only really see to 2 options:
A) reopening this bug once again :-S ;
B) simply opening a new separate one asking for some additional explanations and maybe even to consider some future slight code changes to (at least for Windows OSes) ensure 'gpgconf --list-dirs' directory displayed paths results are more UI consistent with 'gpgconf --list-dirs homedir' or 'gpgconf --list-dirs sysconfdir' displayed ones where displayed C:\... paths always correctly display ':' (colon) instead of '%3a'.
So far this last seems me best viable option also because in same rGe064c75b08a5 I also saw another piece of code (tools/gpgconf-comp.c) with some similar code lines, that apparently (it seems me) if directly referenced (at least only for Windows OSes only, so maybe when a system variable %OS%==Windows_NT exists) instead of current one (common/stringhelp.c) also providing '%3a' 'percent escaping' results, might then have probably also easily avoided '%3a' user unexpected on-screen displayed results only depending by 'percent escaping'.

Just adding this note for any future reference needs only (or even message localization reference, since involved text characters strings are also expected to be among Italian language localized messages even if involved strings are not specifically being localized).

Hello Werner,

That's correct - The output needs to be percent escaped.

wk at gnupg dot org but better avoid any HTML parts etc.

Thank you, this is my great honor!
If it is convenient, can you provide an email address? So that I can elaborate to you.

Thanks. I added it to the list. If you have not yet done this I would suggest to write a note to gnupg-users.

The surprising thing is that it works at all. I wouldn't be surprised if certain would simply reject it as "not a pdf" given that the "%PDF-1.x" marker isn't at the beginning.

--clearsign may only be used for plain text documents due to line ending conversion etc.

See the release notes for GnuPG 2.2.17 (T4606 first item). You need to import your peer's signature from a different source; e.g. ask them to send you your signed key by mail.

The log file specified in .gnupg/dirmngr.conf is created at the start of dirmngr.
dirmngr is invokded by the first call of gpg, and it keeps running and handle next request from second invocation of gpg.
So, nothing is problem.

You used custom options which did not pick up the proper libksba. Install libksba correctly then try again. Please direct further questions to the mailing list and please build the latest version 2.2.23 and not an arbitrary old version.

The CRL states how long it is valid and we cache it for about that time.
OCSP responses are by definition not cachable but we allow for a clock skew of 10 minutes.

OpenPGP (RFC-4880) requires support for 3DES and SHA-1 thus you can't disable them. However, they are not used in practice because the key preference guarantee the use of more modern algorithms,

Iyou look at the key on the command line (or with Kleopatra's certificate manager), for example by using "gpg --list-key foo@bar.com" or by applying the command "gpg --show-keys" on the pasted keyblock you get this:

I don't see any error here. There is a trailing LF on the binary data which gpg rightfully complains about.

Thanks for the patch, applied!
You are correct the NEWS file states that this was added in 1.9.0

Taking a look at other GNU manuals, both GNU make and GNU Bison have a better phrasing,
so I suggest the Bison way (https://www.gnu.org/software/bison/manual/html_node/index.html):

This manual (7 December 2019) is for GNU Bison (version 3.5), the GNU parser generator.

Ah, okay, then the phrasing is missleading, the sentence looks like libgcrypt was released on this date and not the manual.

Nope, that is correct, the last update of the manual was

@sarman: Your question is actually a support question and not a bug report. Please read the documentation, use the public help channels (so that other can also learn from the issue), or get in touch with a commercial support provider.

In T4883#133467, @werner wrote:

That option does the same as --disable-dirmngr which in trun has the same effect as disable-crl-checks

@werner wrote:

Sample how GpgOL handles this: https://dev.gnupg.org/source/gpgol/browse/master/src/keycache.cpp;6f5f48c3d60e0af52f1a9f0e51f60ee653eeeb31$269

I think what you're saying that there is *no way* to use GPGME in offline mode to validate x.509 certificates, and this is by design. Am I understanding that right?

After disabling the CRL check again in gpgsm.conf

I see no difference between the last two example stanzas that show you running ../run-verify. Are they supposed to have different output?

I'm aware of the metadata leakage risks of OCSP, and i share your concerns about them.

OCSP can't be the default because it enables a web bug. The responder immediately sees when a signature is verified or a data is encrypted to a certificate.

If CRLs or OCSP are a MUST in a given profile, and the cert chain has OCSP but no CRL, it seems like that profile should then try OCSP, rather than failing.

That option does the same as --disable-dirmngr which in trun has the same effect as disable-crl-checks; see gnupg/sm/server.c#option_handler. If you want to check the validity of the cert you check the TRUST status lines. This is what gpgme does for you. An example is gpgme.tests/gpgsm/t-verify. You can run the tests also manually, I do this as follows:

I think what you're saying that there is *no way* to use GPGME in offline mode to validate x.509 certificates, and this is by design. Am I understanding that right?

I can see no bug here. See my comment over at T4881.

It is a feature not a bug. For symmetric encryption the gpg-agent remembers the passphrase used for the encryption and thus for some time or until /gpgconf --reload gpg-agent/ it tries that passphrase for decryption.

This seems to be closely related to T4319 and due to to some, ahem, interesting configuration.

I see. Thanks for your explanation.

I see. Thus the problem is that IPWorksOpenPGP does not create proper OpenPGP private keys. I guess they use OpenSSL with their different CRT parameter style and do not convert them correctly. RFC-4880 says this in 5.5.3:

The secret key is this series of multiprecision integers:
o  MPI of RSA secret exponent d;
o  MPI of RSA secret prime value p;
o  MPI of RSA secret prime value q (p < q);
o  MPI of u, the multiplicative inverse of p, mod q.

FYI, pEp annoyance was addressed and handled here: https://bugs.debian.org/891882
By this patch: https://sources.debian.org/src/enigmail/2:2.0.11+ds1-1/debian/patches/0002-Avoid-auto-download-of-pEpEngine-Closes-891882.patch/

Thank you for your response.

For GnuPG, the error is: you don't have run-able libntbtls.so in your environment (because of your wrong configuration, perhaps) but you have it to link.
For GPGME, the error is: your linked libgpg-error.so.0 and the one which runs are different (because of your wrong configuration, perhaps).

You need to update the public key and convey it to the sender. This will solve the problems. You should also ask the sender to update their software so that an MDC is always used regardless of the flag.

I can't see any bug here so I will close this bug now.

Hi Werner,

Please use one of the mailing lists to solve your problem. 2.3 is a development version, so I wonder from where you got this version of GnuPG.

Thank you very much for the analysis. I'll forward the info.

The creating software is broken in regard to non-ASCII characters in the UID:

ssh does nut support brainpool curves and thus GnuPG does not know how to map its internal name of the curve to the name as specified by ssh. GnuPG supports these curves:

So the output of this was

Thanks @werner I will do tonight when connecting to my team mates PC.
Btw meanwhile I actually felt like I need to open next issue where I explain all my details

Your home is under /dev/ - really? Please run

Okay I think I got the root of the issue

When I did

brew reinstall gpg2

I saw this today

In T2203#88661, @nuimk wrote:

/usr/local/bin/gpg-agent -v --daemon

I'm closing this issues as "Invalid" because it is not an issue of Gpg4win. You can still comment and discuss here.

First let me say that it is never a good Idea to use outdated / unmaintained security software. PGP Messages are external input and you pass that to unmaintained software.

Fair enough. Let's wait and see what others think.

Also consider that it is possible to change the key usage flags. Thus it will never be clear whether one has a fixed or unfixed public key. I'd like to close this bug because it is currently also discussed in the IETF WG.

There is another argument for respecting the usage flags: it trims the admissible key space, if key ID in the PKESK packet is zero ('wild card') and thus all private keys have to be considered for decryption.

I disagree, and you don't have to try to convince me, the decision is with werner. I just want to give my opinion:
Bug compatibility is nothing esoteric or bad especially for a general purpose backend tool like gnupg. Being open to accepting broken input is a good thing because it will mean that we can get people out of a "broken tool vendor lock in".

i agree with @Valodim that it would be better to not have a warning at all for an attempt to decrypt from secret key whose public key has never been marked as valid for encryption. A strict failure there (as with a strict failure for lack of mdc) is a better scenario than a warning. If the user controls the secret key and they decide they want to be able to decrypt with it, they should be able to mark it as decryption-capable (if that's really what they want) and retry. But this is an action only for experts.

The same *cannot* be said for a subkey that is marked specifically for certification or signing, and not for decryption.

I understand the real world requirement for decrypting messages that have been encrypted to a revoked or expired key.

I don't see a problem. If you have the private key you can and will use it. I guess your concern is an oracle?

The platform is illumos, a fork of OpenSolaris.