split-gpg: Evolution sometimes fails to decrypt a message that is both signed and encrypted

[marmarek]

Observation

openQA test in scenario qubesos-4.1-pull-requests-x86_64-system_tests_splitgpg@64bit fails in TC_20_Evolution_fedora-35

# test_000_send_receive_signed_encrypted
# failure: 

# timestamp 2022-05-09T09:30:48.208828
Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/splitgpg/tests.py", line 657, in test_000_send_receive_signed_encrypted
    self.assertEquals(p.returncode, 0,
AssertionError: 1 != 0 : Evolution send/receive failed: 
(test_evolution.py:1275): Gdk-CRITICAL **: 05:32:43.695: gdk_atom_intern: assertion 'atom_name != NULL' failed

(test_evolution.py:1275): Gdk-CRITICAL **: 05:32:43.696: gdk_atom_intern: assertion 'atom_name != NULL' failed
click on [push button | New]
Clicking on [document web | ]
Mouse button 1 click at (516.0,527.5)
Typing text into [document web | ]: 'This is test message'
click on [check menu item | PGP Encrypt]
click on [check menu item | PGP Sign]
click on [push button | Send]
click on [push button | Send / Receive]
edit on [table cell | Inbox (1)]
Message body: "
"
Traceback (most recent call last):
  File "/usr/lib/qubes-gpg-split/test_evolution.py", line 259, in <module>
    main()
  File "/usr/lib/qubes-gpg-split/test_evolution.py", line 254, in main
    receive_message(app, signed=args.signed, encrypted=args.encrypted,
  File "/usr/lib/qubes-gpg-split/test_evolution.py", line 171, in receive_message
    assert msg_body.strip() == 'This is test message'
AssertionError

Video review: The message preview really has empty message body, and gpg info at the top says just "Encrypted" without any information about the signature.

Evolution first signs message and only then encrypts (separate gpg calls, separate MIME wrappings), so it might be the signature verification step failing.

The same test passes on debian-11, but then fails on whonix-ws-16 (which is based on debian-11), so it looks to be not deterministic.

Test suite description

Sends a text message that is both signed and encrypted.

Reproducible

Fails since (at least) Build 2022050602-4.1

Expected result

Last good: 2022050404-4.1 (or more recent)

Further details

Always latest result in this scenario: latest

[marmarek]

When interacting with Evolution manually, the same message sometimes opens fine, and sometimes not. In fact, most of the time does not:

I haven't found (yet) any error messages suggesting what is wrong.

[marmarek]

The same is happening with split-gpg2; it could be not related to split gpg at all (but then, I'd expect to find some upstream bug report, as the issue makes GnuPG+Evolution barely usable - yet, I can't see any in gnome's gitlab).

[rapenne-s]

When interacting with Evolution manually, the same message sometimes opens fine, and sometimes not. In fact, most of the time does not:

I haven't found (yet) any error messages suggesting what is wrong.

On Evolution 3.48.4 with Qubes OS 4.2 and split-GPG, sometimes it succeed decrypting the mail.

In addition, it says the message is signed but the key not in the keyring, while thunderbird is happy with the signature in the same qube with the same keyring.

in case this helps... I would really like to get Evolution working with split-gpg :sweat_smile:

[y-pinky]

I had the same issue in evolution on debian bookworm and still have it on debian trixie (testing), so this issue is still there.

But I also have some new information.

From my experience it is worsening, which might indicate that the issue is related to processing time / growing size of mail folders.

In case the message is shown to be "Encrypted" but the message text itself is not shown in the usual box: If I click on the icon in front of the "Encrypted" notice, there is the information that the message was/was't signed, and that the message is encrypted.

There is a little '>' triangle in front of "Details". If I click on this triangle, the decrpyted message content is contained in those details, and can be selected and copied from there into a response message.

So obviously, the meessage has been correctly decrypted, still fails to be correctly shown in the box actually intended for message display. Thus, this seems not to be a decryption error, but some later-on processing issue.