torbirdy replacement

Development
1
2

Shit. TorBirdy is EOL :frowning:

What do we do now? Recommend a less featured alternative? Try to tighten things using custom prefs? Where does one begin?

1 Like
3

HulaHoop via Whonix Forum:

Where does one begin?

With the research paper that resulted in creation of torbirdy?

1 Like
4

To keep track:

Clearly not going to be solved anytime soon.

Better solution, rip off the Tails configuration once they have that sorted @tempest (for your eventual guide update):

(Take note of this)

AFAICT TorBirdy does only the following:

It sets safe values for certain @pref@s, in particular the proxy settings
It offers an alternative (non-automated) account setup wizard
It enforces port 563 + SSL/TLS for NNTP
It changes some hardcoded account defaults for RSS to disable automatic fetching on startup/periodically

We never used 2 since we always patched Thunderbird’s automated setup wizard so it’s safe and used it. 3 is for NNTP which we could disable it (e.g. hide via userChrome.css) if we care enough. 4 doesn’t feel so very serious – if someone profiles you via your subscribed RSS feeds automatic fetching would leak your approximately uptime (btw, did we care about this with Liferea?). We really care about the result of 1, however.

So dropping TorBirdy could be as simple as:

Convince ourselves that losing 3-4 is ok
Import the resulting pref@s from a started Thunderbird with TorBirdy from an up-to-date Tails session (i.e. just copy its @prefs.js and manicure it)

So the simple solution might be to let the Tails dev do all the hard work, focus on the prefs that need changing (users can manually do that once sorted) then just copy whatever other instructions are necessary as above once they are done. Thereby avoiding TorBirdy completely in the future, since it’s not a Tor Project priority.

We should also deprecate most of the content of the existing wiki page and refer to the Tor bug until that is done.

1 Like
5

great. yet another hiccup and roadblock. i’m also dealing with some server issues at the onion. the hard drives were seized by law enforcement back a few months ago and permissions have yet to be set on new server to allow for proper ftp. in the mean time, if you want the old guide, it’s up here for 30 days. it has my verification sig with it. obviously, the torbirdy problem is not addressed.

https://ufile.io/s11b0igg

6
1 Like
7

Thanks - got it.

PS don’t waste your talents on those Twitter trolls :slight_smile:

There are a host of manual fixes required - just changing a host of prefs probably won’t cut it. I see Tails devs talking about preventing having email drafts stored on the remote server and a bunch of other things.

All of this reminds me of why email is s**t. Protocol is weak, nobody uses PGP, too many security & anonymity holes, a ton of steps required, and in a world of 8 billion people we don’t have a single outfit with serious $ supporting basic development required (like TorBirdy updates) to implement necessary fixes…

1 Like
8

Dunno. Could be because Tails always did more than torbirdy. They fixed the account creation wizzard which torbirdy just disabled.

9

well, the tails devs have chosen imap as the default. so, i can see why they are spinning their wheels on drafts saved on server. obvious answer to me is to use pop3. but, for an amnesiac style system that doesn’t save to hd, i guess i can see why they may focus on imap. personally, i think leaving any messages on a server longer than necessary is an awful idea. but, perhaps i’m missing something.

as for twitter trolls, sometimes they are a fun distraction when obstacles block work progress. :wink:

1 Like
10

btw, i would also love to move away from email completely for instructions to users. unfortunately, since a number of services still require an email address for registration and recovery purposes, and using a temporary throw away account is not a great idea for securing access to such services, it appears to be an issue that is not going anywhere any time soon.

11

From Tails changelog:

  • Replace the _TorBirdy_extension with custom settings and patches in Thunderbird that provide equivalent privacy.

Is this code easily usable by us?

  • Mindless copy/paste job?
    • Unfortunately not. Needs someone look into it.
  • Difficulty?
    • Probably low-medium.
  • Re-usable?
    • Partially yes.
  • Partially re-usable sufficient?
    • Probably yes.
      • Why?
        • “Dunno. Could be because Tails always did more than torbirdy. They fixed the account creation wizard which torbirdy just disabled.”
  • Why only partially and not fully re-usable?
    • Because they patch Thunderbird as far as I understand. These patches don’t survive upgrading the Thunderbird Debian package. This is OKish for Tails since they release new ISOs while Whonix relies on APT for upgrades.

TODO:

  1. see this very post torbirdy replacement - #6 by Patrick then read all these files, try to somewhat make head or tail of it
  2. Files from /etc/thunderbird/ can probably be copied over to anon-apps-config /etc/thunderbird/.
  3. Some adjustments may be needed. Reading above files is required.

This might be good enough or even if not perfect still be a superb enhancement.

12

Quote Tails ticket: Tell other privacy distributions how we replaced TorBirdy

Updated by adrelanos 8 days ago

Quote

segfault wrote:

I don’t know of any other privacy distributions that ship / used to ship Torbirdy. Qubes and Whonix do not (I thought that Whonix does, but I checked and it does not).

Whonix used to ship torbirdy. And Whonix used to recommend torbirdy in documentation.

Was wondering too how to ship the same Thunderbird settings that Tails is now shipping to replace torbirdy.

torbirdy replacement - #6 by Patrick

But did not mange to wrap my head around the implementation and port it over to Whonix yet.

#10 Updated by segfault 4 days ago

Quote

adrelanos wrote:

segfault wrote:

I don’t know of any other privacy distributions that ship / used to ship Torbirdy. Qubes and Whonix do not (I thought that Whonix does, but I checked and it does not).

Whonix used to ship torbirdy. And Whonix used to recommend torbirdy in documentation.

Was wondering too how to ship the same Thunderbird settings that Tails is now shipping to replace torbirdy.

torbirdy replacement - #6 by Patrick

But did not mange to wrap my head around the implementation and port it over to Whonix yet.

Thanks for the link! It’s interesting to read that Whonix devs were actually following our work quite closely - even if they never got in touch with us, which probably would have been an easier way for them to find out which parts of our solution they could reuse and which parts are hard to reuse. Anyway, Patrick summarized it quite well in his latest post: Whonix could easily re-use the settings we adopted from TorBirdy in our config files:

tails.git/config/chroot_local-includes/etc/thunderbird/pref/thunderbird.js
tails.git/config/chroot_local-includes/usr/lib/thunderbird/thunderbird.cfg

But for two features of TorBirdy, we found no other way to preserve them than to patch Thunderbird, which Whonix can’t easily do, because they don’t build Thunderbird themselves. Note that we are working on upstreaming those patches, see #17283.

#11 Updated by intrigeri 4 days ago

Quote

But for two features of TorBirdy, we found no other way to preserve them than to patch Thunderbird, which Whonix can’t easily do, because they don’t build Thunderbird themselves.

Note that we do not build Thunderbird ourselves either anymore: the files affected by these patches are plaintext JavaScript so we patch them in place after having installed the Debian package.

That works for a live system such as Tails, but I guess it won’t work for Whonix, which is probably what segfault meant :slight_smile:

#12 Updated by adrelanos less than a minute ago

Quote

I guess readers of TorBirdy does not support Thunderbird 68 (#31341) · Issues · Legacy / Trac · GitLab and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945456 might be interested in your solution too.

1 Like
13
1 Like
14

All patches to Thunderbird now upstreamed. Pref settings are set independently and require inclusion in packaging.

https://lists.autistici.org/message/20200720.072442.bef79acb.en.html

1 Like
15

Commit so far. Stream Isolation needs customization.

https://github.com/Whonix/anon-apps-config/pull/14/commits/58ee2fe4567fc22db3534f5784d704e03ffbcc58

https://github.com/Whonix/anon-apps-config/pull/14/commits/81c4ee1fa179b785dfd2135cdae97803cd6d0f24

https://github.com/Whonix/anon-apps-config/pull/15/commits/48e7600d84816135e0a0fd746b4770cd560673bc

We also need to figure out what config/chroot_local-includes/usr/local/bin/thunderbird · master · tails / tails · GitLab does and how we can use it. The rest are upstreamed patches as per the dev page.

2 Likes
16

Once this is approved, let us know what needs to happen in the email wiki page to fix this issue (where the relevant section was TODO)

2 Likes
17 
configure_locale() {
    # Thunderbird will set the locale based on the environment when
    # this pref is empty, but will then save the result to this pref
    # disabling this "guess" for the next time. We want Thunderbird to
    # always match the locale of the Tails session.
    set_mozilla_pref "${PROFILE}/prefs.js"   \
                     "intl.locale.requested" \
                     '""'                    \
                     user_pref
}

We don’t do anything about locale yet. Not related to torbirdy replacement.

disable_autocrypt() {
    # Disable Autocrypt since it is not safe (#15923).
    set_mozilla_pref "${PROFILE}/prefs.js"                 \
                     "mail.server.default.enableAutocrypt" \
                     "false"                               \
                     user_pref
}

Worthwhile if we share the premise #15923. Do you?
If so, why not disable autoconfig in Thunderbird config same as other changes? Why do it dynamic with a script?

configure_default_incoming_protocol() {
    # For extensions.torbirdy.defaultprotocol, POP = 0, IMAP = 1
    local default_protocol
    if thunderbird_config_is_persistent; then
        default_protocol=0
    else
        default_protocol=1
    fi
    set_mozilla_pref "${PROFILE}/prefs.js"                 \
                     "extensions.torbirdy.defaultprotocol" \
                     "${default_protocol}"                 \
                     user_pref
}

If persistent Tails → POP
If non-persistent Tails → IMAP
I don’t see any reason to ever default to IMAP. POP was default protocol all the way.

Could you check please if POP is already default protocol? If so, no changes required.

# Suppress Enigmail's configuration wizard by pretending that the current
# version was already configured. Only do this on first run though:
# once we've done this we let Enigmail manage this setting itself
# so it can run any migration code it wants to on upgrades.

Suppress Enigmail’s configuration wizard at first start might be safe to Tails but I think we better avoid the extra complexity of this since then we would also require a shell wrapper (or another implementation) to start Thunderbird.

export GNOME_ACCESSIBILITY=1
unset SESSION_MANAGER
thunderbird

What would that be useful for?

export GNOME_ACCESSIBILITY=1 probably not important for now since we don’t have any accessibility support yet

Could you look up please SESSION_MANAGER environment variable? (generally and on Tails website)

thunderbird --class "Thunderbird" -profile ~/.thunderbird/profile.default

Why start thunderbird with that command rather than just simple, default thunderbird?

In summary: worth consideration but looks mostly like Tails specific changes unrelated to torbirdy replacement. Some details worth looking up.

1 Like
18

Debian already ships file /etc/thunderbird/pref/thunderbird.js.
Therefore we cannot easily ship file /etc/thunderbird/pref/thunderbird.js in anon-apps-config.

Dev/About Debian Packaging - Kicksecure

/etc/thunderbird/pref/ is a drop-in folder.

Do we need to get rid of /etc/thunderbird/pref/thunderbird.js?
If not required, meanwhile I renamed to /etc/thunderbird/pref/40_thunderbird.js.

19

This is now in Whonix testers repository.

1 Like
20

Yes I agree after reading the related tickets. Autocrypt causes unencrypted emails to be sent regardless of Enigmail usage:

The way it works is also vulnerable to MitM apparently:

Good point, I will add to the pref.js

Indeed. For most privacy/anonymity purposes Email should be ephemeral as much as possible. However it is still useful to ensure IMAP does not harm privacy as much as possible when it is used and saves Drafts locally. IMAP would be totally unecessary is users have an easy way to archive/backup their inbox when using POP as a VM environment is considered transient and erases any important messages they might want to keep and refer to in the future. Perhaps a script or wiki steps to do this would be enough.

OK

Alright this can be removed

Seems to be Gnome specific not applicable to Xfce so safe to ignore?

The gnome-session program starts up the GNOME desktop environment. This command is typically executed by your login manager (either gdm, xdm, or from your X startup scripts). It will load either your saved session, or it will provide a default session for the user as defined by the system administrator (or the default GNOME installation on your system).

SESSION_MANAGER

This variable is used by session-manager aware clients to contact gnome-session.

My guess is to force Thunderbord to always use the customized privacy settings in all cases even if the user creates or imports their own profile

When you install Thunderbird it creates a profile called “default”. This profile will be used automatically unless you invoke the Profile Manager and create a new profile.

1 Like