Sep 6 2019
This seems to be closely related to T4319 and due to to some, ahem, interesting configuration.
Jun 25 2019
I see. Thanks for your explanation.
Jun 24 2019
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.
Jun 4 2019
May 31 2019
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/
May 30 2019
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).
May 22 2019
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.
May 17 2019
I can't see any bug here so I will close this bug now.
May 16 2019
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.
Mar 6 2019
Thank you very much for the analysis. I'll forward the info.
Mar 5 2019
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:
Jan 15 2019
So the output of this was
Jan 11 2019
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
Jan 10 2019
Nov 20 2018
I'm closing this issues as "Invalid" because it is not an issue of Gpg4win. You can still comment and discuss here.
Nov 9 2018
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.
Nov 8 2018
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.
Nov 2 2018
Oct 30 2018
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.
Oct 29 2018
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?
Apr 17 2018
Aug 3 2017
The platform is illumos, a fork of OpenSolaris.
Jul 18 2017
Jul 17 2017
No. But as of 3.0 GpgOL for Outlook 2003 and 2007 is no longer maintained and the support for this will be removed in some future version. This bug only affects new installations of GpgOL on the unmaintained (by Microsoft) Outlook 2003 and Outlook 2007 Versions. So -> Wontfix.
@aheinecke did you change the default?
werner says it's not a bug.
Jul 13 2017
I am closing this, because this particular change was rejected. Eventually libtool might get updated on its own merits, so no need to track this here.
Jul 7 2017
--with-fingerprint is an option to modify the output of --list-keys and not a command. There are other --with-xxxx options for other purposes. There is no command to list a keyring. This is why gpg meanwhile prints a warning when used without a command.
I don't think anyone is suggesting the use of gpg without a command. However, use WITH the --with-fingerprint command seems to be broken. Thank you for providing a correct way of doing what we want, but please either explain why the use of the --with-fingerprint command isn't working, or put this back as a bug.
The use of gpg without a command is simply wrong. This has never been specified and could actually lead to surprises.
You need to import the key first and then look at it with -k (--list-keys) or --fingerprint.