Feature #5663: Return to Icedove
Override Torbirdy default settings in a more maintainable way
I see that we override Torbirdy default prefs by patching
/usr/share/xul-ext/torbirdy/chrome/content/preferences.js with with
config/chroot_local-patches/torbirdy-adjust-defaults.diff. It certainly works, and was totally good enough for the initial iterations, but this is the kind of things that's a pain to maintain: patches get fuzzy, one has to rebase them, and one has to review diffs-of-diffs.
In general, when software offers ways to configure it, let's use them, instead of patching the source code. The good news is that Torbirdy offers quite some config tools meant for downstream like us :)
- We can use
- Upstream provides a way to define various Enigmail torification modes (see
setEnigmailPrefs); I think we should add the one we want, instead of patching the source code.
- For the proxy settings, we can either do the same (see e.g.
pub.setProxyWhonix), or keep using a custom one; if the latter, it looks like we might be able to set
extensions.torbirdy.custom.network.proxy.socks_portin our prefs file, instead of patching the code (untested).
Stop patching in our default into Torbirdy.
- We have a patch against upstream Torbirdy that we will upstream,
which switches from using http://127.0.0.1:8118 as the Enigmail
keyserver proxy to socks5h://127.0.0.1:9050, which is safer and will
always work if Tor is installed.
- Use Torbirdy's pref branch overrides in /etc/xul-ext/torbirdy.js to
set the socks_port and keyserver URL.
#2 Updated by anonym over 3 years ago
- Status changed from Confirmed to In Progress
- % Done changed from 0 to 30
- Feature Branch set to feature/6154-secure-autoconfig-in-icedove
Fixed in the feature branch, but that includes bumping our Torbirdy patch of stuff we want to upstream => yes, part of this will be fixed upstream, namely:
commit 89bf536f14872660815886f480cc88902904d4aa Author: anonym <email@example.com> Date: Fri Mar 18 17:42:16 2016 +0100 Use Tor's SOCKSPort for Enigmail's keyserver configuration. It's not necessarily the case that users have an HTTP proxy running on port 8118, and if they do it may be a non-torified Privoxy instance. Using the Tor SOCKSPort will always work, and be torified.
which totally makes sense to upstream to me.