Open Bug 1642614 Opened 2 months ago Updated 8 days ago

Support the Qubes OS feature "Split GPG" feature

Categories

(MailNews Core :: Security: OpenPGP, enhancement)

enhancement

Tracking

(Not tracked)

REOPENED

People

(Reporter: KaiE, Assigned: KaiE)

References

Details

(Keywords: leave-open)

Attachments

(2 files)

Thunderbird uses RNP by default. As an optional mechanism to support smartcards, we consider to allow the use of secret keys managed by GnuPG. The current intention is to access GnuPG using the GPGME interface library.

Jon asked: Will this work with the Split GPG functionality offered by Qubes OS ?

I looked at this document:
https://www.qubes-os.org/doc/split-gpg/

It might work, but we'll need a change in Thunderbird, and we'll need to test if it indeed works.

We'd have to tell the GPGME library, that instead of using the gpg executable, it should instead use the /usr/bin/qubes-gpg-client-wrapper binary (which is apparently a tool that forwards all interaction with gpg to a different VM).

This should be possible with GPGME, by calling the gpgme_set_engine_info API:
https://www.gnupg.org/documentation/manuals/gpgme/Engine-Configuration.html

This means we need an optional Thunderbird preference to change the name of the GPG executable. If the pref was set by the user, then we call gpgme_set_engine_info at init time.

That's a simple change. We should make that change, to allow volunteers to test if it works.

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/ca7de17fb799
Support an alternative gpg executable when using GPGME. r=PatrickBrunschwig

Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED

Leaving the bug open until we confirm it's working, the patch was just a first step.

Status: RESOLVED → REOPENED
Keywords: leave-open
Resolution: FIXED → ---

Jon, maybe you know of a volunteer who could help test this?
Not urgent, but documenting the TODO now.

Here's how to:

  • use a nightly build (not today, starting with tomorrow's build)
  • use TB config editor (in preferences) to set two prefs
  • set mail.openpgp.allow_external_gnupg to true
  • set mail.openpgp.alternative_gpg_path to the correct value, probably /usr/bin/qubes-gpg-client-wrapper
  • restart TB
  • open TB error console, and verify that you get a message about gpgme being loaded. We haven't this working yet on all platforms, we might need to adjust the filenames for the gpgme library to make it work everywhere.
  • have an encrypted email message that can be decrypted using a key from the split gpg keyring
  • click the message

Does TB decrypt the message?

Flags: needinfo?(jon)

Comment on attachment 9153409 [details]
Bug 1642614 - Support an alternative gpg executable when using GPGME. r=PatrickBrunschwig [beta 78 checked in]

We should uplift to 78 beta to allow testing and using this with beta builds.

Attachment #9153409 - Flags: approval-comm-beta?

I've pinged my Qubes contacts to help test this usecase; and will continue tracking the bug.

hi there, Michael from Qubes OS team here. thank you Jon and Kai for your efforts on this!

I am waiting for today's build and then will test. I have also created a bug on our side to track.

Note that signing through the external gnupg approach is not yet implemented.
Only decryption is support currently.
At this point, we're simply interested to understand if the planned approach can work with Qubes.

hey folks I gave it a try (focused only on decryption as you emphasize Kai) and it doesn't work. can you let me know how to get more informative logs?

using Error Console, upon booting TB states:

Successfully loaded OpenPGP library librnp.so from /home/user/Downloads/thunderbird-79.0a1.en-US.linux-x86_64/thunderbird/librnp.so
public keys: 0, secret keys: 0 (which means it is not reading the external gpg even though it is configured in the Config Editor as you describe)

upon attempting to open encrypted email, TB Error Console states:

CryptoAPI.sync() starting
CryptoAPI.sync() leaving

No email content shown in the email window.

You need to have the GPGME library installed. It must be available with filename libgpgme.so on Linux in the library search path. If TB is able to load it, it will mention gpgme on the error console.

okay for debian 10 template I needed to install libgpgme-dev. fedora 31 template seems to come with gpgme.

now I also get in error console:
gpgme version: 1.12.0
configuring GPGME to use an external OpenPGP engine /usr/bin/qubes-gpg-client-wrapper - success

so as mentioned previously I am getting no other errors, however the test message I sent was PGP/MIME.

I now tried with a test inline PGP message, and I get the following error in the error console:

enigmailMessengerOverlay.js: messageDecryptCb: caught exception: Error
Message: 'EnigmailData.getUnicodeData invalid parameter'
File:    chrome://openpgp/content/modules/data.jsm
Line:    27
Stack:   getUnicodeData@chrome://openpgp/content/modules/data.jsm:27:13
decryptMessage@chrome://openpgp/content/modules/decryption.jsm:330:34
messageParseCallback@chrome://openpgp/content/ui/enigmailMessengerOverlay.js:1426:36
messageParse@chrome://openpgp/content/ui/enigmailMessengerOverlay.js:1274:18
messageDecryptCb@chrome://openpgp/content/ui/enigmailMessengerOverlay.js:1015:14
messageDecrypt/<@chrome://openpgp/content/ui/enigmailMessengerOverlay.js:682:24
onData@chrome://openpgp/content/modules/mime.jsm:459:19
newStringStreamListener/onStopRequest/<@chrome://openpgp/content/modules/streams.jsm:78:17
callbackWrapper@chrome://openpgp/content/modules/timer.jsm:30:7
notify@resource://gre/modules/Timer.jsm:62:17

this email opens fine in TB 68 + Enigmail that sent it.

let me know if you need any other information.

in a non-split-gpg thunderbird 78, this inline PGP email decrypts fine however it is not recognized in the UI as an encrypted email (tbird does not put the lock UI symbol next to the signed UI symbol). so there may be additional issues going on.

Thanks for testing. So obviously it doesn't work yet, you're running into a failure. Needs to be debugged.

(In reply to Michael from comment #13)

let me know if you need any other information.

in a non-split-gpg thunderbird 78, this inline PGP email decrypts fine however it is not recognized in the UI as an encrypted email (tbird does not put the lock UI symbol next to the signed UI symbol). so there may be additional issues going on.

I created a new ticket related to this UI bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1644411

(In reply to Kai Engert (:KaiE:) from comment #14)

Thanks for testing. So obviously it doesn't work yet, you're running into a failure. Needs to be debugged.

okay thanks for letting me know, happy to test further any fixes in the future.

(In reply to Michael from comment #15)

(In reply to Michael from comment #13)

let me know if you need any other information.

in a non-split-gpg thunderbird 78, this inline PGP email decrypts fine however it is not recognized in the UI as an encrypted email (tbird does not put the lock UI symbol next to the signed UI symbol). so there may be additional issues going on.

I created a new ticket related to this UI bug:

I don't think that's a separate bug. Most likely because the failure you saw prevents the further processing of the message including the related UI update.

qubes-gpg-client-wrapper and qubes-gpg-client must be changed to also forward gpg parameter "--unwrap".

That parameter is used by the GPGME API gpgme_op_decrypt_ext when flag GPGME_DECRYPT_UNWRAP is given. It isn't documented in the manual page, but it is documented in the changelog for version 2.1.10
https://lists.gnupg.org/pipermail/gnupg-announce/2015q4/000381.html

FYI I am doing all this testing in Debian 10.

For Fedora 31, even though gpgme is installed:

$ sudo dnf install gpgme
Package gpgme-1.13.1-7.fc31.x86_64 is already installed.

tbird is not finding it: not showing in error console, not registering external gpg agent.

Are you using a x86-64 version of Thunderbird?

yes. you can see in the file path from error console output in Comment 9.

I have tested https://archive.mozilla.org/pub/thunderbird/nightly/latest-comm-central/thunderbird-79.0a1.en-US.linux-x86_64.tar.bz2 (78.0a1 looks to be older than discussion here) on Fedora 31.
Thunderbird looks for libgpgme.so library, instead of libgpgme.so.11. The former one is provided only with development headers, which are unlikely to be installed on users systems.

But then, I have not managed to get it use or even list secret keys with split-gpg. I have confirmed TB calls /usr/bin/qubes-gpg-client-wrapper --version, so the setting works.

On error console I see just:

Successfully loaded OpenPGP library librnp.so from /home/user/Downloads/thunderbird/librnp.so RNPLib.jsm:46:13
public keys: 0, secret keys: 0 RNPLib.jsm:189:15
Successfully loaded OpenPGP library libgpgme.so from system's standard library locations GPGMELib.jsm:58:13
gpgme version: 1.13.1 GPGMELib.jsm:220:15
configuring GPGME to use an external OpenPGP engine /usr/bin/qubes-gpg-client-wrapper - success GPGMELib.jsm:236:15

This is a fresh setup - no previous account was configured. Specific steps I've done:

  1. Downloaded TB (link above)
  2. Installed gpgme-devel
  3. Started TB, cancelled account setup wizard
  4. Set mail.openpgp.allow_external_gnupg and mail.openpgp.alternative_gpg_path
  5. Restarted TB. Confirmed qubes-gpg-client-wrapper --version was called
  6. Configured test account (manually, not through wizard), Entered account settings -> End-To-End Encryption,
  7. Dialog "Set Personal Key" doesn't list anything, and also doesn't trigger any call to qubes-gpg-client-wrapper.
  8. Dialog "Manage OpenPGP Keys" also doesn't list anything (neither public keys from key-holding VM through qubes-gpg-client-wrapper, nor those imported locally in the same VM). qubes-gpg-client-wrapper wasn't called either.

I have tried to import public key in "Manage OpenPGP Keys", but it failed with "rnp_import_keys failed with rv: 268435458 RNP.jsm:1177:15" (I believe it is unrelated to this thread).

Please note by design secret keys are available only through qubes-gpg-client-wrapper, local gpg keyring don't have them at all. I don't think I got far enough to verify if this works.

Extra info:

$ qubes-gpg-client-wrapper --version
gpg (GnuPG) 2.2.20
libgcrypt 1.8.5
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/user/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

Kai, do you still want this for beta?

Flags: needinfo?(kaie)

(In reply to Wayne Mery (:wsmwk) from comment #23)

Kai, do you still want this for beta?

Yes, please, while we're working towards the stable OpenPGP feature, I would like to have all changes to mail/extensions/openpgp on the 78 branch, even if they are still incomplete, so we don't have to worry about merging.

Flags: needinfo?(kaie)

Marek, thanks for testing. Your comment 22 suggests that you aren't aware that Thunderbird's optional access to GnuPG is intended to be limited to secret key operations, only decrypting and signing. And at this time, only decrypting is implemented. No key management using GnuPG.

Right now, the only code path that might potentially run through GnuPG is decrypting a received email. Later, we want to allow it to be used for signing. Potentially, we might also fetch the public key from GnuPG that is associated to the secret key in used.

I have a partial success to report, which is still confusing and suggests that more research/analysis is needed.

Using Qubes stable, with two test VMs based on Debian 10, with qubes-gpg-split 2.0.46 from qubes testing, with my own local Thunderbird 78 branch build, with the prefs set, with environment variable QUBES_GPG_DOMAIN set in the frontend domain, I get the following result:

(1) running Thunderbird directly

I'm prompted to enter the backend domain once, on startup, triggered by GPGME library init.
Then I click an encrypted message, which needs the remote GnuPG secret key to decrypt.

Decryption fails.
No additional prompts are shown

(2) running "strace -f ./thunderbird |& grep -i qubes"

I'm prompted to enter the backend domain once, on startup, triggered by GPGME library init.
Then I click an encrypted message, which needs the remote GnuPG secret key to decrypt.

I'm again prompted to enter the backend domain.

Decryption works!

Why might it only work through strace?
Timing?

Attached file qubes-trace.txt

the log in comment 27 is from the working decryption, running thunderbird through strace

(In reply to Kai Engert (:KaiE:) from comment #26)

I'm prompted to enter the backend domain once, on startup, triggered by GPGME library init.

You can also avoid the prompt each time with policy config (https://www.qubes-os.org/doc/split-gpg/#advanced-configuration). In short, add to /etc/qubes-rpc/policy/qubes.Gpg a line like this:

work-email  work-gpg  allow

(where work-email is where you run TB and work-gpg is where you store the key)

As for debugging, I would try less intrusive method than strace. Try adding echo "$@" >> /tmp/gpg-wrapper.log at the beginning of /usr/bin/qubes-gpg-client-wrapper.

Thunderbird's optional access to GnuPG is intended to be limited to secret key operations, only decrypting and signing

Yes, I understand this intention. But is is unclear to me how to configure it. I definitely do not want to import my secret key to thunderbird just to be able to select it in account configuration. This would defeat the whole purpose of split-gpg.

Thanks for clarifying and for the idea! I'll try that.

I used some additional logging inside TB and found that gpgme_op_decrypt_ext returns with error code 0x700003a / 117440570.
I haven't yet found what this code means.

Comment on attachment 9153409 [details]
Bug 1642614 - Support an alternative gpg executable when using GPGME. r=PatrickBrunschwig [beta 78 checked in]

Approved for beta

Attachment #9153409 - Flags: approval-comm-beta? → approval-comm-beta+

(In reply to Marek Marczykowski-Górecki from comment #29)

But is is unclear to me how to configure it.

Currently, you don't need to configure a key ID. We'll add that later, once we support signing.

Currently, for the initial testing and for the attempted decryption, we simply call the GPGME decryption API, without specifying a key ID, but simply hope that GPGME will find a matching key.

(In reply to Marek Marczykowski-Górecki from comment #29)

In short, add to /etc/qubes-rpc/policy/qubes.Gpg a line like this:

Ok, with that I confirm I no longer get prompts.

Try adding echo "$@" >> /tmp/gpg-wrapper.log at the beginning of /usr/bin/qubes-gpg-client-wrapper.

With this, I was able to find a difference between my working and non-working scenarios.
It isn't about "strace", but rather it was about the fact that I'm redirecting the output using |&

In the failing scenario (running Thunderbird directly, WITHOUT output redirection), then the command arriving at the qubes-gpg-client-wrapper INCLUDES "--ttyname /dev/pts/1 --ttytype xterm-256color".

Full command when running TB directly:

--enable-special-filenames --batch --no-sk-comments --status-fd 105 --no-tty --charset utf8 --enable-progress-filter --exit-on-status-write-error --display :0 --ttyname /dev/pts/1 --ttytype xterm-256color --logger-fd 107 --decrypt --unwrap --output - -- -&110

In the working scenario, WITH output redirection (eg: ./thunderbird | grep -vi bla), then the command arriving at the wrapper does not have any tty detail configuration. Full command seen:

--enable-special-filenames --batch --no-sk-comments --status-fd 105 --no-tty --charset utf8 --enable-progress-filter --exit-on-status-write-error --display :0 --logger-fd 107 --decrypt --unwrap --output - -- -&110

In other words: When starting Thunderbird from the terminal prompt (gnome terminal) then the command sent by GPGME includes TTY configuration and that apparently breaks qubes-gpg-client-wrapper. Redirecting output fixes the problem.

Since those TTY-related options are meaningless in another VM, I think the wrapper can simply ignore them (do not pass them to the backend). I don't expect any change in behaviour (interaction with other options), but I can't be sure since those are not documented (again...).

Can you try this patch applied manually to qubes-gpg-client-wrapper?

Yes that works for me! (With and without output redirection.)

Comment on attachment 9153409 [details]
Bug 1642614 - Support an alternative gpg executable when using GPGME. r=PatrickBrunschwig [beta 78 checked in]

https://hg.mozilla.org/releases/comm-beta/rev/385e98c56c20d53f56f00e13eacf948f33f2bc31

Attachment #9153409 - Attachment description: Bug 1642614 - Support an alternative gpg executable when using GPGME. r=PatrickBrunschwig → Bug 1642614 - Support an alternative gpg executable when using GPGME. r=PatrickBrunschwig [beta 78 checked in]

The changes that are specifically required for Qubes should be done.
The remaining work to support digital signing using GnuPG smartcards via GPGME should also handle the Qubes scenario.
That remaining backend work will be tracked in bug 1627911. We don't yet have a bug to track the related UI changes.

See Also: → 1627911
Flags: needinfo?(jon)

With the Thunderbird 78.1.0 release, support for OpenPGP is still disabled by default.

However, with 78.1.0 the implementation for the optional use of GnuPG for secret keys should be complete.

Here is a wiki page that describes how to configure the key ID for a Thunderbird account, so you can use signing, too. (In addition to decryption
that was already working previously.)
https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards

Could you please try it and give feedback if you run into problems?

Flags: needinfo?(github)

I can confirm it works for me! both reading inline PGP and PGP/MIME and sending PGP/MIME.

feedback:

all in all it works! thanks so much for your work on this :)

Flags: needinfo?(github)
You need to log in before you can comment on or make changes to this bug.