There is a new announcement of a drop-in replacement library for rnp in Thunderbird, that is based on code at the Sequoia project: https://sequoia-pgp.org/blog/2021/04/08/202103-a-new-backend-for-thunderbird... This would look very promising as a way to recover so much functionality that was dropped in the current Thunderbird builds for OpenPGP support. It would seem that building sequoia/octopus and using the resulting library would allow a version of Thunderbird to be built that has significantly enhanced support for integration with openPGP keyrings, and also support autcrypt. It might be really nice if a version of Thunderbird was built for the arch repos with this library supporting encryption and signing instead of the current rnp implementation. Does anyone else think this would be a good project to work on? -- mike c

On 4/9/21 4:46 AM, NicoHood via arch-general wrote:

On 4/8/21 9:17 PM, Mike Cloaked via arch-general wrote:

...

There is a new announcement of a drop-in replacement library for rnp in Thunderbird, that is based on code at the Sequoia project:

https://sequoia-pgp.org/blog/2021/04/08/202103-a-new-backend-for-thunderbird...

This would look very promising as a way to recover so much functionality that was dropped in the current Thunderbird builds for OpenPGP support. It would seem that building sequoia/octopus and using the resulting library would allow a version of Thunderbird to be built that has significantly enhanced support for integration with openPGP keyrings, and also support autcrypt.

It might be really nice if a version of Thunderbird was built for the arch repos with this library supporting encryption and signing instead of the current rnp implementation. Does anyone else think this would be a good project to work on?

I like the idea! I have not (re)enabled GPG support since the update because of varios reasons. A local keyring integration is just super important!

I also think the same. I do actually use GPG keyring for my private keys, but I believe that's not enough, and I'd like to use GPG instead, but TB made that impossible, or so I believed, until reading this, :) Unfortunately, I'd guess Arch maintainers don't like patching upstream SW, and I understand since I like as much vanilla SW as possible, this would be one good exception for me, :) Thanks ! -- Javier

On 4/18/21 1:52 AM, NicoHood via arch-general wrote:

I am not sure if that is what you (Javier) are actually doing, but I found a (simple but hidden) way to still use the GPG keyring without any thunderbird modifications.

I was not aware of that before, so I'd like to share: https://blog.nicohood.de/use-thunderbird-78-with-system-gnupg-keyring

Cheers, Nico

Yes, that's precisely what I meant with using GPG to manage the private key, that's what I use. I first read about this on: https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards https://wiki.mozilla.org/Thunderbird:OpenPGP:Migration-From-Enigmail https://support.mozilla.org/en-US/kb/openpgp-thunderbird-howto-and-faq https://blog.thunderbird.net/2020/09/openpgp-in-thunderbird-78 The master key is said not to be required, because by having gpg and the gpg-agent handle the private key, then the only thing TB keeps in its DB are the public keys, which, are public, hehe... However I don't like keeping a gpg keyring and a separate TB DB for public keys. Besides, in those readings, it's sort of unclear whether the support for gpg is a long term thing, rather it looks allowed just to work around the lack of support for certain private keys, like having them in an USB key, or a yubikey, or similar... So, I'd go with a native gpg approach, if that's available... -- Javier

On Sun, Apr 18, 2021 at 1:56 PM Genes Lists via arch-general < arch-general@lists.archlinux.org> wrote:

I've been using octopus now for a while testing it - and its working really well. I much prefer using gpg and the implementation is in rust, and seems clean.

The manual installation of octopus library is dead trivial - easy to try out for anyone interested. Simply rename librnp.so and put a soft link to the octopus version.

I don't think changing the thunderbird base install is the right approach.

While I'm not sure the best way to achieve this but here's one suggestion. Package thunderbird in 2 parts :

(1) thunderbird (2) thunderbird-librnp.

Now an separate package of sequoia octopus librnp (sequoia-octopus-librnp) can be provided as an alternative package supplying librnp. Thunderbird would now depend on one of these packages 'providing' librnp.

That way the regular install would remain the same, and for those of us that really like the alternative, its just a separate package to install. This might also be a good candidate for pacman alternatives when available.

I have been using the sequoia-octopus-librnp package as a replacement for the internal librnp in Thunderbird beta 88.0b3 and it works well. Of course at the present time it is necessary to build your own copy of sequoia-octopus-librnp as a package to install, and the replace the existing librnp.so in the standard Thunderbird package with the octopus version, either replacing the file, or softlinking it. The development is very active and up to date, and it provides excellent additional capability for Thunderbird concerning signing and encryption for the gnupg keyring. However if as the previous post suggests that the new library is provided as an additional arch package as an optional dependency for Thunderbird, that would be really excellent as a way forward. -- mike c