Reagarding the OpenPGP specs: there is a new draft with LOTS of changes to already agreed upon formats and conducted interop tests. Almost everything we implemented in GnuPG and RNP has had rough consensus in the WG. Minor things like AEAD chunk size were the contested pieces. However, now they want to change everything with the possible outcome of discretization the long established trust in the stability and durability of the PGP data and key format.

Thanks for notifying. Will be fixed in the next release (mid Apri).

Please see T5834 which is fixed in 1.17.1

Fixed in 1.17.1

Note the ABI bug the Qt version of 1.17.0 which is fixed with 1.17.1 (T5872)

Please describe your problem in more detail. Also: Which version of GpgOl and Outlook are you using, SMTP/IMAP or Exchange?

I don't think it is justified to tag this as "unbreak now" - which we use for severe bugs inhibiting the use of a deployed version.

I tend to agree

Cool. I did some quick tests with 2.2 on my pretty old X220 and it really makes sense to apply the patch there as well.:

aheinecke: Good idea

Do you mean revoking the entire key or a user-id, or a subkey? Having a way to revoke a user-id is probably the most interesting use-case. BTW, there is no "revoke a self-signature" - this is actually a revocation of the user-id or subkey.

Works for me in the current Kleopatra.

Sorry.

Actually all changes Kleopatra does go through gpgconf. Thus is is normal that gpgconf overwrites things.

Feel free to ask me by PM if you run into problems (wk at gnupg.org). Two of my colleagues are Vim users and thus have an interest in a well working plugin :-). Thanks.

Try with hkp:// - I assume that you are missing the new Lets Encrypt CA certificates

Why are you using the log output for scripting? This is not its intended use. You need to use --status-fd. Log output is purely for human consumption it not a stable API. BTW, --fixed-list-mode has gone ages ago but it does not harm.

There is another hacker working on finishing it. I only provided the framework.

What is the problem here? Some compiler warning about fully legal code?

It seems you have replaced the scdaemon module from GnuPG by a 3rd party module (which exhibits a version number 0.10.0) - this is not supported and you will of course run into errors.

What you uploaded are files with a length of zero bytes. That is not valid data. The hang should not happen of course.

Setting the management key has been implemented only for Yubikeys. So for Gemalto this won't work.

I wonder why a platform has no cmp but comes with printf, which is a modern POSIX extension to Unix.

Why can't we hide internal symbols in c++ as we are doing in other libs for ages? Were the internal symbols only accidentally exposed?

Folks, you are opening a can of worms. The only secure why to sign a file is to have a detached signature. That is often non-practical and thus putting the signature/MAC at one certain position and exempt just this one position from hashing is the next best alternative. Any more complicated rules will inevitably introduce security flaws. If a binary is stripped, it is a different binary than a non-stripped one, if it is linked with another linker, it is a different one. And that binary will even be able to figure this out and change behavior. Please keep it simple.

Guess why GnuPG has its own Tor aware resolver ;-) To debug this kind of stuff you need to debug dirmngr, by adding for example

As well as GnuPG VS-Desktop. 3.1.21. We should also do a new gpg4win release.

Actually is was/is a chain of bugs due to changing some URLs in confirmation mails from http to https.

GpgOL 2.5.2 has been released

Let's try this for 2.3

Breaking the flawless decryption of existing old data is unfortunately a highly controversy topic. Recall the no-more-v3 packet support or the required MDC. It was technically okay and 99.99% of the users didn't even notice it. But some were very vocational.