You could verify this with another email address containing a +.

How can I check this, @ikloecker ?

Can you check whether the + character in the email addresses is causing this?

I can't replicate this symptom (gpg1 generated key, no problem after migration).
Could you share the *.key file under private-keys-v1.d?

I think that this commit rG8fd150b05b74: gpg: Remove all support for v3 keys and always create v4-signatures. matters.

Thanks for you patches. Most of them applied cleanly despite that I delayed processing them for half a year.

@mieth sorry for the delay. meanwhile I adjusted the ciphersuite of the WKD gateway to include an AES-CBC suite. would be interested if it works now on the setup you tested before.

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.

Great, thank you very much!

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

Sorry. While v5 things in the specification is still in flux, from the viewpoint of the implementation, this patch is 100% valid and it makes sense.

Thank you for the report.

The mails from these days still contain the following header:

List-Post: <mailto:gnupg-devel@lists.gnupg.org>

which is probably causing the mail client directing the mails to this address. Is there a way to change or or make it an alias so it is easier for people to use the mailing list without finding this issue?

Should be fixed.

The patch for T5834 (https://dev.gnupg.org/rMad3aabdd8a64156c7e3a75d695ae1ab2c4bec841) was already applied to the build of GPGME 1.17.0 for Focal, as I did browse the list of latest GPGME bugs first before reporting this bug. Attempting to build with the latest GPGME 1.17.1 (with the included ABI patch) results in exactly the same FTBFS for i386 only, so this does appear to be a distinct issue not related to that of ABI backwards compatibility.

Please see T5834 which is fixed in 1.17.1

Fixed in 1.17.1

Fixed.

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

I'm not sure. In KeyResolverCore::Private::resolve() line 668 reads

const bool pgpOnly = (!mEncrypt || !hasUnresolvedRecipients(mEncKeys, OpenPGP)) && (!mSign || mSigKeys.contains(OpenPGP));

I'd say this is supposed to check if there is an OpenPGP signing key, but I guess mSigKeys[OpenPGP] is an empty list. This may be a regression introduced by the resultion of key groups because in KeyResolverCore::Private::resolveSigningGroups() the entry mSigKeys[OpenPGP] is always set (unless we are in CMS-only mode).

Yes, unit tests still pass. So its ok with you to commit this?

Sounds familiar, that the signing keys are not considered. I think when I worked on this, I thought that is was a bad idea to mix resolving signing and encryption keys. Do the unit tests still pass with your change?

@ikloecker
If I test the resolver code from libkleo with gpg4win-tools keyresolver binary:

pinentry-qt with new icon:

I will add a suitable icon from the Breeze style.

Closing this task since the original feature request is still in the QA queue.

I tend to agree

(note: -O2 is added only for compiling powerpc vector implementation files)

I added check to configure.ac for missing -O flag and tests with -O2. If adding -O2 does not help, then powerpc vector implementations wont be build at all.

Thanks. All my tests work now.

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

It was the bug of generating AEAD packet, which does:

Sorry for pushing immature fix. I located the cause, but I didn't have enough concentration for fix.

Just more background what I'm doing with these tests. I started testing with set of different sized test files (generated from urandom) to detect any bugs in my changes, which try to reduce amount of memory copies in iobuf_read/iobuf_write. Size ranges for these test-files are 0...17408, 32256...66560 and 130560...132096 bytes. These files are encrypted with different settings (public key/symmetric/cfb/ocb/different algos) and then decrypted and decrypted file compared to original.

I tested the fix. It appears to break OCB encrypting files shorter than 65515 bytes:

$ gpg --batch --symmetric --passphrase=bug --output=enc_065514.gpg --rfc4880bis --force-aead --cipher-algo AES128 --compress-algo none plain_065514
$ ls -laF *065514*
-rw-rw-r-- 1 jussi jussi   100 Feb  22 18:51 enc_065514.gpg
-rw-rw-r-- 1 jussi jussi 65514 Feb  22 18:42 plain_065514
$ sha256sum plain_065514
5711955703f4d96f510ad5a660c3ccd0d01f0b2dd2561ba6586159ad941cbcde  plain_065514
$ gpg --batch --decrypt --passphrase=bug --output=- enc_065514.gpg | sha256sum
gpg: AES.OCB encrypted session key
gpg: encrypted with 1 passphrase
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  -

@ikloecker thanks for the hint (At first it looked like a different defect.)

This has already been fixed: T5711: Kleopatra: Keyserver config does not fallback to default.

In T5848#155277, @bernhard wrote:

@hakan-int :

As soon as I change the value and check the "dirmngr"file, it is overwriten with the "keyserver hkps://" value again.

(I hope only if you completely delete it, as it should keep any other value and write it to file.)

As soon as I change the value and check the "dirmngr"file, it is overwriten with the "keyserver hkps://" value again.

@bernhard when I close Kleopatra and stop the its task by the task manager, then the value remains. But as long as I do not change the default value to an other value in "Settings" -> "Configure Kleopatra". As soon as I change the value and check the "dirmngr"file, it is overwriten with the "keyserver hkps://" value again. I think, this is not the expected default value, is it?

@werner the main issue here, that Hakan has found a usability problem:

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

When I overwrite the default value "hkps://keyserver.ubuntu.com" with another value in "Settings" -> "Configure Kleopatra" once and click "Apply or OK" and delete this new value again, then Kleopatra does not insert the default value to the necessary place again.

Thanks! This plugin has been around for a long time, and this is one aspect I inherited from the original code. I'll look into reworking it to use the status output.

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.

The user who made the first report about this issue, it could help: Forum Wald

We (@hakan-int and myself) saw the problematic behaviour in one setting. It was a VM where Gpg4win had been installed, deinstalled and reinstalled again. We still try to find out how to reliably recreate the situation and what is the difference between a working and a non-working case.

I suspected that it would be listed by gpg --dump-options, but I didn't think about autocompletion cleverly using it. I apologize.

How does the user know about the feature in the first place, other than reading the source code or searching the executable for "hidden" command-line flags?

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

@werner will have to answer why he added the unfinished code. My guess is that he wanted to prevent it from being lost on his computer. I would probably have deactivated the code as long as it's unfinished.

Yes. Sorry about that. We had multiple issues where attachments were hidden and not shown as attachments because they had a content-id but that content-id was not referenced in a way that outlook shows.

Ah! Sorry! Is there any reason the command-line flag made it to a release? How should the user know that the feature does not work, other than reading the bugtracker and source code?

You are trying to use unfinished code. See https://dev.gnupg.org/rGafe5fcda52e88438c7a7278117b2e03f510a9c1c. It's not really surprising that unfinished code doesn't work.