A number of users want PGP/GPG/Keybase support to Mailspring.
There used to be a Keybase plugin for Nylas mail, but it’s difficult (or impossible) to find now.
This is a priority, but we really need someone familiar with this to help us implement it.
Hi,
So I assume the difficult part is to implement the encryption/decryption and signing/verification.
I’m not an expert but I’d assume once the mail is parsed these operations are applied to the corresponding parts.
For all the crypto operations we should use an external library like OpenPGPjs. So we just need to make sure that the email is parsed correctly, s.t. the right string goes into the right openPGP function.
Here an example for a signed email:
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256;
boundary="----=_Part_99187222_6352000067.2891734681264"
------=_Part_99187222_6352000067.2891734681264
Content-Type: multipart/alternative;
boundary="----=_Part_12371878_129837423.1610754987387"
------=_Part_12371878_129837423.1610754987387
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
EMAIL IN PLAIN TEXT
------=_Part_12371878_129837423.1610754987387
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
EMAIL IN HTML
------=_Part_12371878_129837423.1610754987387--
------=_Part_99187222_6352000067.2891734681264
Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
SMIME CERTIFICATE
------=_Part_99187222_6352000067.2891734681264--
Autocrypt: addr=...@...; prefer-encrypt=mutual;
keydata=...
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="tasydia7BASYD6KDBUASIGfkaug7askjaba"
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--tasydia7BASYD6KDBUASIGfkaug7askjaba
Content-Type: multipart/mixed; boundary="uiIUBLASCNUasibfu7asulbfyasv23bkasus"
--uiIUBLASCNUasibfu7asulbfyasv23bkasus
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
EMAIL CONTENT
--uiIUBLASCNUasibfu7asulbfyasv23bkasus--
--tasydia7BASYD6KDBUASIGfkaug7askjaba
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
....
-----END PGP SIGNATURE-----
--tasydia7BASYD6KDBUASIGfkaug7askjaba--
The Content-Type determines the protocol and boundary which separates the different parts. For S/MIME, we have the email content and then the signature as an smime.p7s file attachment. And for PGP it is a signature.asc file.
I think Enigma mail can be of great help here and a few of their routines can be copied, e.g.:
Enigma mail also uses OpenPGP as their default crypto api: package/cryptoAPI.jsm · master · enigmail / enigmail · GitLab
So looking at this, it seems more doable. But I am not an expert and it seems like the ecosystem is a bit fragmented, with different mime-types for the same thing. Aside from the crypto part there also needs to be an interface to store/search/generate keys or add certificates + changes in the composer to sign/encrypt and in the UI.
Hope that is helpful for anyone who wants to work on this…
There also seems to be a keybase plugin, that could be used as a basis: GitHub - NgoHuy/mailspring-keybase: keybase plugin for mailspring
Hi. Andi summed things up quite nicely, but I will try to add to it.
There are two wanted features: encryption/decryption and signing/verification for (1) PGP/GPG and (2) S/MIME. While there are many similarities, they are not the same.
S/MIME is CMS/CAdES format built into the email text format, and there are multiple versions. The latest version seems to be 4.0 (see RFC 8551). The first task you want to cross-out is having a library capable of producing and parsing CMS/CAdES in binary format (which is essentially an ASN.1 structure). When you have such a library, the next step is correctly handling email structure. Standards define two different email formats with an S/MIME signature. AFAIR, they are multipart/signed and application/x-pkcs7-signature, and they differ in signature inclusion. The first format attaches the signature next to the message (the email is a multipart) and the latter envelopes the message within the signature so the message is not visible in the raw email dump. So, in the context of verification, message extraction and verification will differ a bit. In the context of signing, both formats are probably good to use - multipart/signed for signed-only email and the other for signed and encrypted email. Next, for producing signed and encrypted emails, a decision needs to be made whether to first encrypt the message and then sign it, or vice versa. I recommend to consult the Security Considerations in RFCs with this (and make sure that the CMS/CAdES library can handle both because in general, you never really know what you’re going to receive from other email clients). If we come back to correctly handling email structure, the next big thing is correctly handling different Content-Type values. For example, you may not always receive one of the two mentioned Content-Types (email transport layer is generally unreliable to support newest technologies), and in the worst case, the signed message could be buried somewhere deeper in the email structure, or there could be multiple such messages, or there could be nested messages. In these cases, extracting the messages and signatures takes a bit of work, but support for them will likely be postponed until a significant number of users request it - a priority is, of course, to support the most prevalent inputs. The same can also be said about many things concerning the CMS/CAdES structure, signing certificates and their verification, but this is a security-sensitive context, so attention should be paid to properly implement the generation/verification routines. The key is having someone who knows the difference between critical and non-critical things. When it comes to producing signatures, the key thing is support for various private key storages. People may use (e.g.) their operating systems’ key stores, their browser’s key store (FireFox) or an external storage device, usually with a USB connector. I think all three options have something in common: you need to be able to extract the signing certificate from them and use their PKCS#11 interface to produce the signature value for you without getting access to the private key. For PKCS#11 capability, I recommend to include another library into the project. Especially support for USB devices will take a bit of work and tinkering. Signature verification also requires a list of trusted root/intermediate certificates. Again, they may come from (e.g.) operating systems’ trust stores, browser’s trust store (FireFox) or an external trust store (one shipped with the application or explicitly provided by the user). Occasionally, people will want to add a root/intermediate certificate into the trust store. AFAIR, there is potentially a conflict during signature verification in that which email address to verify against which. AFAIR, the “From” header may not always contain the address of the person who actually sent the message and attached the signature. Also, the certified email address may be specified in several places within the certificate, or there may be multiple addresses within. Extracting a list of possible sender addresses and a list of possible certified addresses, and doing an intersection may not be a secure way of verification. What many people could appreciate is a nice and round verification summary, especially when the feature is still young and not fully tested, or when verifications fails. If it were me, I would add an option to display two things somewhere beside the signed message’s viewing canvas: the Common Name or Distinguished Name of the certified subject and the issuer. This would serve as a quick visual check for the user. Ok, I think that sums up the key issues to solve when bringing support for S/MIME. I would have loved to work on this if I had the time but unfortunately, I don’t.
Personally, I have no experience with PGP/GPG on a technical level but I presume it is something quite similar. One of the key differences is that, in this case, some users may prefer not to trust public keyrings and build their own trust stores of public keys. The hard part though is making the trust stores secure because they will likely contain the private keys as well. On some operating systems, perhaps the provided facilities could be used (e.g. KeyChain on macOS), but I’m not completely sure.
In any way, both these endeavours will not be easy, and will require commitment, time and effort if the goal is to support the needs of many people and do it properly. Especially testing may be difficult.
+1 over here…
Looking forward to PGP Support in Mailspring
Done! Thx for the reminder.
+1 Need Yubikey support too.
I would love mail spring to support gpg, but honestly I’ve given up on the idea of the majority of my contacts being able correspond this way and I doubt they will change to differ mail clients.
What I have found useful is emacs’ ability to encrypt/decrypt a region of text. This lets you paste a message into the body of a normal message.
What options are there to allow mail spring to open an external editor or perhaps parse the body or selected region of text to an external program?
I work in information security and PGP protection for emails containing vulnerability disclosure is not just a nice-to-have, it’s critical and the norm in my field. Just wanted to drop my 0.02 cents to say mailspring is a gorgeous piece of software that I will not be using until this is added. I’ll keep scrubbing along with Evolution until then.
It would be great to have the PGP Encryption support. Would like to see it implemented in near future.
Kudos +1.
Hi!
I think this is more important than ever given that we know that there is no MAIL hosting company will protect your mail (talking about ProtonMail that gave data to the authorities).
I’d like this client to have GPG Keys built into it.
Cheers!
About that particular case,
You seem to have been miss-informed, as Protonmail only complied with Law, per their already existing terms.
And they weren’t able to give encrypted mail contents to the authorities, only the IP address.
Either if you’ve encrypted your mail content via their system, or encrypted it outside of it, nothing would have protected you from law. Including if you try to refuse to them.
I really like mailspring, but project partners require digitally signed and encrypted mails with s/mime, which is very common in the industry. This missing feature is the only factor that blocks me from using mailspring, please seriously consider this feature, even in the form of a plugin is acceptable!
I would looove to see this feature come to mailspring, it’s a great client and I don’t want to use evolution no more…
This would be great. Should be high priority.
I am just a new user, that switched to Mailspring and so far I do really like it 
I don’t often use PGP, but I do need it for work. Would be even ok if this is a pro feature.
just my2cents
thx Fil
Ayyy please tell me there are new updates or hope about this feature
PS: yes voted
Just signed up to comment this – I’d give it a go moving from Evolution to Mailspring if GPG were implemented, for sure.
Edit: I noticed the GitHub issue where @CodeMouse92 reached out for any devs willing to help implement it. I work in JS/Node but have rudimentary C experience and would be happy to learn a new skillset to help in any way to implement this.