Project

General

Profile

Bug #15483

Update Electrum configuration file

Added by mjenglish over 1 year ago. Updated 20 days ago.

Status:
Needs Validation
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
03/31/2018
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Electrum

Description

Regarding the current configuration file, auto connect should not be enabled by default. Users should have the option to select a server manually. There are privacy and security benefits to choosing a trusted server. The "Privacy" coin chooser option is depreciated in Electrum 3.1.0. Apparently it had a bug. Also, the blank server field is unnecessary. I believe that it was added to workaround a bug that has been fixed.

Regarding the new configuration file, the proxy option is the same except I formatted it according to Electrum's "Use Tor proxy at port 9050" option. It seems to prefer onion servers this way which is a benefit because connections will be encrypted and authenticated. I also added the field for the updated configuration version 2.

Please look at the attached config file and use a diff tool to compare it to the old version. Based on my limited testing, it should work better than the outdated configuration file.

config (69 Bytes) mjenglish, 03/30/2018 08:47 PM


Related issues

Blocked by Tails - Bug #15484: Upgrade Electrum to 3.1.1+ Resolved 03/31/2018

History

#1 Updated by intrigeri over 1 year ago

  • Status changed from New to In Progress
  • Assignee changed from anonym to s7r
  • % Done changed from 0 to 10
  • QA Check set to Ready for QA

s7r, please review this and if/once happy reassign to anonym for another round of QA.

Notes:

  • If we don't autoconnect by default our automated test suite may need to be updated.
  • We'll need instructions for users to update their persistent Electrum config.

#2 Updated by s7r over 1 year ago

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 over 1 year ago

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.

#4 Updated by mjenglish over 1 year ago

  • Target version deleted (Tails_3.7)

#5 Updated by intrigeri over 1 year ago

  • Target version set to Tails_3.9

#6 Updated by intrigeri about 1 year ago

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

#7 Updated by s7r about 1 year ago

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 about 1 year ago

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:

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 #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 about 1 year ago

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 #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 about 1 year ago

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.

#11 Updated by intrigeri about 1 year ago

  • Blocked by Bug #15484: Upgrade Electrum to 3.1.1+ added

#12 Updated by intrigeri about 1 year ago

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 #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 :)

#13 Updated by intrigeri about 1 year ago

  • Target version changed from Tails_3.9 to Tails_3.10.1

#14 Updated by intrigeri 11 months ago

  • Target version changed from Tails_3.10.1 to Tails_3.11

Any update?

#15 Updated by intrigeri 10 months ago

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 10 months ago

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.

#17 Updated by intrigeri 10 months ago

  • Target version changed from Tails_3.11 to Tails_3.12

Hi!

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

Great, thanks for the update! :)

I can see on the tracker that it was removed from testing because of a minor bug,

FYI in Debian lingua, this "minor bug" is the highest possible severity; it's RC which means it will block the package from being released in Debian Buster if not fixed in time.

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

OK. So I guess this will happen for Tails 3.12.

Until then I guess we are ok in Tails? All going smooth for our users and there is no security risk or usage penalty.

Well, I have no idea if we're OK in Tails: at least the part of #15483#note-12 about upgrading pre-existing persistent config was not answered.

#18 Updated by CyrilBrulebois 10 months ago

Relatedly: please see #16204 for the buster preparations.

#19 Updated by anonym 8 months ago

  • Target version changed from Tails_3.12 to Tails_3.13

#20 Updated by CyrilBrulebois 6 months ago

  • Target version changed from Tails_3.13 to Tails_3.14

#21 Updated by CyrilBrulebois 4 months ago

  • Target version changed from Tails_3.14 to Tails_3.15

#22 Updated by intrigeri 4 months ago

  • Status changed from In Progress to Needs Validation

#23 Updated by CyrilBrulebois 2 months ago

  • Target version changed from Tails_3.15 to Tails_3.16

#24 Updated by intrigeri 20 days ago

  • Target version deleted (Tails_3.16)

Hi!

We've set up an automated process to ask our fellow contributors to update some tickets of theirs, in order to:

  • better reflect your plans;
  • bring down your amount of work-in-progress to a sustainable level;
  • encourage team work and increase the chances that someone finishes the work;
  • avoid a human doing ticket triaging and asking you the same questions on each such ticket.

In particular, this process identifies:

  • Stalled work-in-progress
  • Reviews waiting for a long time

However, in the current state of things, this process is not able to notice those tickets when their Target version has been repeatedly postponed by our Release Managers. Therefore, the ticket triaging team decided on #16545 to remove the Target version whenever in such cases, when it does not feel realistic. This is what I'm doing on this ticket.

You now have a few options, such as:

  • Deassign yourself. That's fine. If it really matters, someone else, possibly you, may pick it up later. Then, if this ticket is relevant for a Tails team, bring it to their attention; else, forget it and take care of yourself :)
  • If you think you can realistically come back to it and finish the work in the next 6 months, say so on this ticket, for example by setting a suitable "Target version". This will communicate your plans to the rest of the project and ensure the task pops up on your radar at a suitable time. Of course, you can still realize later that it is not going to work as planned, and revisit today's choice.

Cheers!

Also available in: Atom PDF