Add GPGME library bindings, and an OpenPGP decryption fallback
Categories
(MailNews Core :: Security: OpenPGP, enhancement)
Tracking
(Not tracked)
People
(Reporter: KaiE, Assigned: KaiE)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
This is an initial attempt to support optional decryption using GnuPG, in the hope it will allow decryption with a GnuPG compatible smartcard.
I have a patch that implements the following strategy:
If we fail to decrypt using RNP, we check if the GPGME library has been successfully loaded. If yes, we attempt to decrypt using GPGME in the GPGME_DECRYPT_UNWRAP mode - which is supposed to keep the signature in place. (That allows us to process the signature in a subsequent step using RNP).
I've tested this code on Linux, it's able to decrypt, if the required secret key is available in the gnupg key store, only. The inner signature is processed in both scenarios I've tested - either if the inner part is the result of unwrapping a combined signature/encryption data package, and also if the inner part is a multipart/signed message.
Assignee | ||
Comment 1•5 years ago
|
||
Assignee | ||
Comment 2•5 years ago
|
||
Once we land this code, we should find volunteers with a configured smartcard to test if decryption works - ideally on multiple platforms.
Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/07bb4c990a5e
Add GPGME library bindings, and an OpenPGP decryption fallback. r=PatrickBrunschwig
Assignee | ||
Comment 4•5 years ago
|
||
Assignee | ||
Comment 5•5 years ago
|
||
If neither RNP nor GPGME has the secret key to decrypt a message, our GPGME code tries to use a null buffer, we get an error console entry, and no decryption failure icon. I've attached a follow-up patch to fix that.
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Description
•