Tails

#2 Updated by s7r 2018-04-02 21:27:32

I saw the simple config file, yet it is unclear for me if it gives us enough gains to worth the hassle to ship a new config. There is no added security in using a trusted server (only way to gain added security is to run a full node and validate everything - advertising to users using SPV wallets like electrum that they are more secure if they use a trusted server is false, the only way is to NOT use SPV lightweight wallets and be a full node). No added anonymity as well (you are still behind Tor that protects you), so from the server’s perspective either you connect to via .onion and server sees 127.0.0.1 as your IP either you connect via clearnet and server sees the Tor exit node as your IP.

When you first run Electrum you are asked if you’d like to connect to a server automatically or select a server manually. Why is there a need to disable auto-connect at config file level? I could be missing something here.

3.0.6 only uses encrypted connections. Non SSL servers are not even displayed. Also, the threat model is that Electrum assumes the connection NOT tot be secure (authenticated and/or encrypted), and the server NOT to be trusted without verification. Obviously having this connection encrypted and authenticated is better than not having it, but it’s not a major issue.

Privacy coin selection policy was merged in 3.1 with the Priority coin selection policy. It did not have a bug in the real sense of the word, it was only useless because it was not prioritizing confirmed coins vs unconfirmed coins.

I don’t know if the blank server field is relevant or not. It does not break anything. Maybe this is the auto-config generation format. I have checked on my non Tails OS running electrum 3.0.6 and it looks exactly the same like in Tails, so I think it’s fine.

Users that have persistence enabled need to replace their config files and do their settings again, otherwise the new config file will just disable auto-connect for them but there are so many other custom settings users might have.

How will this affect the automated test suite?

#3 Updated by mjenglish 2018-04-02 23:34:39

s7r wrote:
> I saw the simple config file, yet it is unclear for me if it gives us enough gains to worth the hassle to ship a new config.
How is shipping a new config file a hassle?

> There is no added security in using a trusted server (only way to gain added security is to run a full node and validate everything - advertising to users using SPV wallets like electrum that they are more secure if they use a trusted server is false, the only way is to NOT use SPV lightweight wallets and be a full node).
Electrum servers are full nodes and you can get more reliable answers if you select one run by yourself or someone that you trust.

#6 Updated by intrigeri 2018-08-07 07:36:59

Any status update here? The freeze for 3.9 is coming soon: https://tails.boum.org/contribute/calendar/

#7 Updated by s7r 2018-08-12 22:21:36

I didn’t get any feedback wrt how this will affect our testing suite. It is unclear to me what this aims to fix and I would like to avoid complicating things and putting users go through additional efforts if there are no significant gains. Users who don’t have a clue about electrum servers or how they work might block and not know what to do when asked to select. The other way around, users that run their own electrum servers (or know about electrum servers run by people they trust) they would certainly know they need to manually overwrite the server used by their electrum wallet, thus just connecting to a random server and than changing manually to a trusted one does not look like it present any risk to me.

As for future compatibility, the new Electrum versions update the config automatically, so in case there are deprecated / obsolete features in the old config file, misconfigurations or etc., it will not fail and auto-correct and also add new defaults if new features are shipped with the newer version.

Let’s decide what is best to do here.

#8 Updated by intrigeri 2018-08-13 11:41:28

> I didn’t get any feedback wrt how this will affect our testing suite.

Oops, sorry I missed this question at the end of your previous comment. The answer is: our test suite assumes that Electrum will auto-connect. If this changes, then some code needs to be written there to connect to the network. The corresponding files are:

• https://gitlab.com/Tails/tails/blob/master/features/electrum.feature
• https://gitlab.com/Tails/tails/blob/master/features/step_definitions/electrum.rb

> It is unclear to me what this aims to fix and I would like to avoid complicating things and putting users go through additional efforts if there are no significant gains. Users who don’t have a clue about electrum servers or how they work might block and not know what to do when asked to select. The other way around, users that run their own electrum servers (or know about electrum servers run by people they trust) they would certainly know they need to manually overwrite the server used by their electrum wallet, thus just connecting to a random server and than changing manually to a trusted one does not look like it present any risk to me.

OK, so let’s forget about the “auto connect should not be enabled by default” part.

> As for future compatibility, the new Electrum versions update the config automatically, so in case there are deprecated / obsolete features in the old config file, misconfigurations or etc., it will not fail and auto-correct and also add new defaults if new features are shipped with the newer version.

Good. Once 3.1.1+ is available in stretch-backports, someone should test how this fares in practice (enable a persistent Electrum config created with an older Tails, start the newer Electrum, verify that everything is configured as expected). I believe this is the only blocker for Bug #15484 once the updated package reaches stretch-backports.

Other remaining open questions seem to be:

• Shall we adjust the config (as proposed here) to prefer Onion servers? The only benefit mjenglish stated is invalid according to s7r. mjenglish, is there another argument in favour of this proposal?
• We currently have "coin_chooser": "Privacy" and you wrote “Privacy coin selection policy was merged in 3.1 with the Priority coin selection policy”. Does that mean that with our current config, “Priority coin selection policy” will be enabled automatically as part of migrating obsolete settings? s7r, can you please test this?

#9 Updated by s7r 2018-08-31 14:21:23

intrigeri wrote:
> OK, so let’s forget about the “auto connect should not be enabled by default” part.
>

Sounds good to me. Again, the only drawback is that it requires additional step from the users, some of them might get confused and not know what to choose thinking it has any impact on their crypto currency holdings. Those users who know that they want to select a custom (their own, or trusted parties) Electrum servers will surely know not to select auto-connect at the initial setup wizard.

> > As for future compatibility, the new Electrum versions update the config automatically, so in case there are deprecated / obsolete features in the old config file, misconfigurations or etc., it will not fail and auto-correct and also add new defaults if new features are shipped with the newer version.
>
> Good. Once 3.1.1+ is available in stretch-backports, someone should test how this fares in practice (enable a persistent Electrum config created with an older Tails, start the newer Electrum, verify that everything is configured as expected). I believe this is the only blocker for Bug #15484 once the updated package reaches stretch-backports.
>

I have tested Electrum 3.1.3 with a persistent config remained from an Electrum 3.1.1 and it worked without any problem.

> Other remaining open questions seem to be:
>
> * Shall we adjust the config (as proposed here) to prefer Onion servers? The only benefit mjenglish stated is invalid according to s7r. mjenglish, is there another argument in favour of this proposal?

I don’t think so. It already detects Tor and prefers onion servers if socks5 port is 9050 or 9150 (Tor or Tor Browser setups). My first run from scratch on auto-connect was to an .onion server. Our config file comes with setting: "proxy": "socks5:localhost:9050::", - if you go into Electrum GUI -> Network and check “Use Tor proxy” the only thing that changes in the config file is: "proxy": "socks5:127.0.0.1:9050::",. I don’t see any problem in changing this particular line in the default config file shipped by us to "proxy": "socks5:127.0.0.1:9050::", (substitute localhost to 127.0.0.1).

> * We currently have "coin_chooser": "Privacy" and you wrote “Privacy coin selection policy was merged in 3.1 with the Priority coin selection policy”. Does that mean that with our current config, “Priority coin selection policy” will be enabled automatically as part of migrating obsolete settings? s7r, can you please test this?

Yes, this setting is obsolete. We found out after that it did not work as expected and when this is seen in the config file is simply ignored. So either if we have "coin_chooser": "Privacy" or "coin_chooser": "Priority" in config file, both are ignored and Electrum uses its default coin chooser policy that gets the most privacy while choosing the optimal fee for a given transaction. They worth exactly 0.

From my tests I discovered that Eectrum 3.1.3 WILL NOT remove "coin_chooser": "Privacy" line from config file, but it won’t be bothered by it as well and simply ignore it. I think its automatic config file update does not delete lines that do not break functionality. I will check this upstream too.

So, I propose the following:
- fix upstream. I consider a bug that we have Tor proxy in the GUI as a separate checkbox yet there is no (clear difference) in the config file if / when that is checked. I will fix this upstream.

- as soon as the fix upstream is ready and the version ported to stable-backports we will do some house keeping with the config file we are shipping by default and make it as follows:
- remain on auto connect
- explicitly tell Electrum the socks5 proxy is a Tor proxy (fix upstream required)
- remove the obsolete, unnecessary and ignored "coin_chooser": "Privacy" line.
Until then we are good to go and there’s nothing we need to do.

#10 Updated by mjenglish 2018-09-01 21:39:11

intrigeri wrote:
> * Shall we adjust the config (as proposed here) to prefer Onion servers? The only benefit mjenglish stated is invalid according to s7r. mjenglish, is there another argument in favour of this proposal?

I’m too busy right now with unrelated matters to participate in this conversation in a meaningful way. I apologize for the inconvenience. I trust that s7r has the best intentions.

#12 Updated by intrigeri 2018-09-03 09:27:50

>> > As for future compatibility, the new Electrum versions update the config automatically, so in case there are deprecated / obsolete features in the old config file, misconfigurations or etc., it will not fail and auto-correct and also add new defaults if new features are shipped with the newer version.
>>
>> Good. Once 3.1.1+ is available in stretch-backports, someone should test how this fares in practice (enable a persistent Electrum config created with an older Tails, start the newer Electrum, verify that everything is configured as expected). I believe this is the only blocker for Bug #15484 once the updated package reaches stretch-backports.
>>

> I have tested Electrum 3.1.3 with a persistent config remained from an Electrum 3.1.1 and it worked without any problem.

This is great but that’s not what Tails users will experience: when upgrading from Tails 3.8 to 3.9 they’ll go from electrum 3.0.6-1~bpo9+1 to 3.1.3-1~bpo9+1. Could you please test how a persistent config created on Tails 3.8 fares after upgrading to Tails 3.9~rc1?

>> * We currently have "coin_chooser": "Privacy" and you wrote “Privacy coin selection policy was merged in 3.1 with the Priority coin selection policy”. Does that mean that with our current config, “Priority coin selection policy” will be enabled automatically as part of migrating obsolete settings? s7r, can you please test this?

> Yes, this setting is obsolete. We found out after that it did not work as expected and when this is seen in the config file is simply ignored. So either if we have "coin_chooser": "Privacy" or "coin_chooser": "Priority" in config file, both are ignored and Electrum uses its default coin chooser policy that gets the most privacy while choosing the optimal fee for a given transaction. They worth exactly 0.

> From my tests I discovered that Eectrum 3.1.3 WILL NOT remove "coin_chooser": "Privacy" line from config file, but it won’t be bothered by it as well and simply ignore it. I think its automatic config file update does not delete lines that do not break functionality. I will check this upstream too.

> So, I propose the following:
> - fix upstream. I consider a bug that we have Tor proxy in the GUI as a separate checkbox yet there is no (clear difference) in the config file if / when that is checked. I will fix this upstream.

> - as soon as the fix upstream is ready and the version ported to stable-backports we will do some house keeping with the config file we are shipping by default and make it as follows:
> - remain on auto connect
> - explicitly tell Electrum the socks5 proxy is a Tor proxy (fix upstream required)
> - remove the obsolete, unnecessary and ignored "coin_chooser": "Privacy" line.
> Until then we are good to go and there’s nothing we need to do.

OK, please go ahead :)

#15 Updated by intrigeri 2018-12-03 13:49:37

Hi s7r! Are you still interested in maintaining the integration of Electrum in Tails? If yes, there’s this ticket and also (OT) the fact the Electrum was removed from Debian testing because it’s been RC buggy for more than a month, which seems to be trivial to fix.

#16 Updated by s7r 2018-12-03 21:22:28

of course! package maintainer had an accident and was afk for some time, everything will be fixed next week hopefully.

I can see on the tracker that it was removed from testing because of a minor bug, but we use stable-backports where the previous version that is still ok to use, can connect to the network and does not prevent a security risk is available.

Electrum 3.2.3 which has been fairly stable will be in stretch-backports next. Hope the update will come along with updates for python3-trezor (recommended packages).

we will do our house-keeping stuff with the config file along with this update.

Until then I guess we are ok in Tails? All going smooth for our users and there is no security risk or usage penalty. Sorry for this, but this is expected when we are based on stable :) We will avoid this headache in buster with the neat additional software tool hopefully.

#18 Updated by CyrilBrulebois 2018-12-07 22:53:16

Relatedly: please see Bug #16204 for the buster preparations.

#29 Updated by s7r 2019-10-02 14:37:55

@intrigeri shipping the config file i attached above will do it for all users that use Tails live image, but how will the users with persistence enabled that upgrade from an older Tails feel it?

So if an user with persistence enabled, that is running an older Tails which contains the older Electrum will want to upgrade to Electrum 3.3.8, he most probably already has a lot of custom parameters in the persistent config file (such as his own preferences and settings). Is there any way to only push “check_updates”: false, without altering the rest of the settings? Or is better since it’s a totally new Electrum to just override the persistent config file of the user with the new default one? We should decide about this as well.

Otherwise the user will see a pop-up (if this is not set in config file) that asks: Do you want to be notified when there’s a newer version available? and Yes/No buttons. I have to mention that this pop-up only appears first time when Electrum is started and there is no check_updates parameter in the config file (either true or false). If the user clicks Yes the config is updated with true, if clicks No the config is updated with false. Either way at next run Electrum won’t display the pop-up any more and just check for updates and display in the bottom bar if any is available (if true) or not do any check at all (if false).

If the user clicks Yes, then he will see in Electrum bottom bar the message “Version X.X.X is available” if there’s a newer version on electrum.org than what the user is running. But, as I said, high chances that is NOT available in Tails / Debian (if it’s not something critical). So if there’s no way to push this config parameter, we should document on our page about this, why this status quo and how users can turn the message off. If we decide that this approach suits us I’ll write the text / explanation and send to whoever is responsible for our website / wiki content.

#30 Updated by segfault 2019-10-02 23:36:25

Thanks for working on this.

Regarding the "auto_connect": true and the proxy config, I see that our current config file already has these values, so we don’t have to change those.

s7r wrote:
> decimal_point and num_zeros set to 8 -> this means that the balance of the wallet will be shown in BTC (full bitcoin), and not mBTC or satoshis. All these are units for Bitcoin, so 1 satoshi = 0.00000001 BTC for example. I think users should see everything in the default plain and simple BTC, divisible to its 8th decimal as per protocol. If we think this is not a good idea and we should not care about it, I am also attaching version 2 for config file in the bottom of this comment which removes these 2 parameters.

I don’t see why we should deviate from the default upstream config regarding the displayed format. So I updated the config file to your version 2.

> shipping the config file i attached above will do it for all users that use Tails live image, but how will the users with persistence enabled that upgrade from an older Tails feel it?
>
> So if an user with persistence enabled, that is running an older Tails which contains the older Electrum will want to upgrade to Electrum 3.3.8, he most probably already has a lot of custom parameters in the persistent config file (such as his own preferences and settings). Is there any way to only push “check_updates”: false, without altering the rest of the settings? Or is better since it’s a totally new Electrum to just override the persistent config file of the user with the new default one? We should decide about this as well.

The users who made their Electrum config persistent will keep their old config files (their persistent .electrum directory is bind-mounted over the default one). So we are not overwriting their config.

Unfortunately, Electrum doesn’t seem to support multiple config files, like a system-wide config file which sets defaults that can then be overwritten by the user’s config file - that would have been a nice way to set the check_updates default value.

> Otherwise the user will see a pop-up (if this is not set in config file) that asks: Do you want to be notified when there’s a newer version available? and Yes/No buttons. I have to mention that this pop-up only appears first time when Electrum is started and there is no check_updates parameter in the config file (either true or false). If the user clicks Yes the config is updated with true, if clicks No the config is updated with false. Either way at next run Electrum won’t display the pop-up any more and just check for updates and display in the bottom bar if any is available (if true) or not do any check at all (if false).
>
> If the user clicks Yes, then he will see in Electrum bottom bar the message “Version X.X.X is available” if there’s a newer version on electrum.org than what the user is running. But, as I said, high chances that is NOT available in Tails / Debian (if it’s not something critical).

If the message is just in the bottom bar, and there are no pop-ups or something like that, it doesn’t sound that bad to me.

Anyway, it’s also easy to overwrite this option for all users, by calling electrum setconfig check_updates false from the Electrum wrapper before starting Electrum. I just pushed a commit to my branch which does that. But note that this command takes relatively long, more than a second on my system, and each setconfig command can only set one option. So we shouldn’t set many options that way.

#31 Updated by s7r 2019-10-04 17:15:30

Hello,

I’m all in for setting electrum setconfig false in the wrapper for users with persistence that upgrade.

Otherwise they will be asked if they would like to be notified of updates and most will probably click yes. That is kind of useless for our policy (we rely on Debian packages) since even if an update is available on electrum.org it does not necessarily mean it is in Debian.

Yea, only the first message is a pop-up where the user should select yes or no. Then, it’s just displayed in the bottom bar if the update is available, but it might still be annoying to users as they are notified about an update and they can do nothing about it. Lots of support emails will come towards Tails team for this the way I see it for absolutely no benefit.

If you think we should leave the update notification in the bottom bar enabled, I don’t think it’s the end of the world so I accept that solution as well, I just pointed out what setting it to false might prevent. A third opinion is welcomed here.

#32 Updated by intrigeri 2019-10-05 06:57:11

> Otherwise they will be asked if they would like to be notified of updates and most will probably click yes. That is kind of useless for our policy (we rely on Debian packages) since even if an update is available on electrum.org it does not necessarily mean it is in Debian.

Indeed. In general, Debian packages disable this sort of things, be it in the default config (which in this case seems to be hard-coded in the program) or via build-time option. When upstream is happy to help distros, it’s easy; otherwise, sometimes we have to patch stuff :/ Given you’re our bridge to upstream already, perhaps you could request from them that they make it possible to disable these updates notification, at package build time, without having to patch the code?

> Yea, only the first message is a pop-up where the user should select yes or no. Then, it’s just displayed in the bottom bar if the update is available, but it might still be annoying to users as they are notified about an update and they can do nothing about it. Lots of support emails will come towards Tails team for this the way I see it for absolutely no benefit.

I agree this is a valid concern.

#33 Updated by intrigeri 2019-10-05 06:57:47

> Anyway, it’s also easy to overwrite this option for all users, by calling electrum setconfig check_updates false from the Electrum wrapper before starting Electrum.

Great news!

#34 Updated by segfault 2019-10-05 17:05:19

@intrigeri: Wasn’t this issue solved by 549a28fce38c810dcb8f1d47b4a904d36a2c1c58 and a75ef27dec474483a8c6bfaea74b178cb17a57b9, which you merged into devel today? Or do you want to keep it open for s7r to ask upstream about making it easier to disable the update check?

#35 Updated by s7r 2019-10-05 20:55:29

I think we should go for `electrum setconfig check_updates false` in the wrapper for the time being.
I was under the impression that this is already the case.
Upstream implemented this to narrow down the users that don’t upgrade because most of them don’t upgrade (don’t even check if updates are available) unless something is not working for them. this opened the door to an effective phishing attack.

Since we ship packages from Debian, we will also upgrade the package version in Debian in case there’s something severe or critical. Otherwise, for small bug fixes that are only for UX experience and stuff, it’s not worth it to have all the users notified and get tons of emails like “Electrum tells me there’s an update available, why doesn’t Tails do anything about it?” cause most users don’t know/understand our package policies.

#36 Updated by intrigeri 2019-10-06 04:25:53

> intrigeri: Wasn’t this issue solved by 549a28fce38c810dcb8f1d47b4a904d36a2c1c58 and 549a28fce38c810dcb8f1d47b4a904d36a2c1c58, which you merged into devel today?

@segfault: I have no idea. I did not dive into this (rather long) discussion to check whether everything this ticket is about has been solved by these commits. The proverbial “someone” should do it :)

> Or do you want to keep it open for s7r to ask upstream about making it easier to disable the update check?

No, not particularly.

#38 Updated by intrigeri 2019-10-06 05:29:58

> OK, I’m closing it the, because

Great, thanks!