"A reply from a related thread: "I am disappointed that the Thunderbird project would choose to inflict so much pain on itself and on its users for no other reason than to
avoid the GPL. Speaking as a longtime user (and donor [to Thunderbird]), I don't really care which specific copyleft license applies to Thunderbird. I *do* care about the quality and stability of the OpenPGP implementation." https://thunderbird.topicbox.com/groups/e2ee/T90e254e13eec027d-M0ab78f1147c176fe003d799c

From my email: "As I understand it, there is a Thunderbird policy to not link to GPL libraries. I'd like the community to reevaluate this decision in particular in the context of Thunderbird's OpenPGP support."

@dsfgs Thunderbird is FOSS in a similar way to FreeBSD: they both use free software licenses, they both do most development in the open, but neither uses the GPL, because the GPL prevents a proprietary fork, which they want to allow.

RNP "requires the developer to opt-in to these safety-critical checks, not opt-out, as they would if they were using Sequoia. Since safety checks are non-functional, they are easy to forget: the code appears to work even if the safety check is forgotten."

@mpjgregoire I don't want to get your hopes up too high, but the Octopus only addresses half of the issue. It replaces rnp with Sequoia, restores the gpg integration, and adds back web of trust support, but it does not address user facing UX issues.

Thunderbird recently issued two CVEs related to unencrypted secret key material. In CVE-2021-29956, TB forgot to encrypt the secret key material for newly imported keys. In CVE-2021-29950, which introduced the previous CVE, they forgot to reprotect secret key material in memory. In this blog post, I discuss what we can learn. https://sequoia-pgp.org/blog/2021/05/22/202105-a-look-at-two-recent-cves-in-thunderbirds-openpgp-support/

Sequoia PGP is now licensed under the LGPL 2.0+. Read more about why here: https://sequoia-pgp.org/blog/2021/10/18/202110-sequoia-pgp-is-now-lgpl-2.0/ #pgp #sequoia