Project

General

Profile

Bug #15483

Update Electrum configuration file

Added by mjenglish over 1 year ago. Updated about 1 month ago.

Status:
Resolved
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

config (165 Bytes) s7r, 10/02/2019 08:31 AM


Related issues

Blocked by Tails - Bug #15484: Upgrade Electrum to 3.1.1+ Resolved 03/31/2018
Blocked by Tails - Bug #16421: Electrum Phishing Attack - Upstream Fix Committed Resolved 02/05/2019

Associated revisions

Revision 549a28fc (diff)
Added by segfault about 2 months ago

Update Electrum config (refs: #15483)

  • Remove the obsolete "coin_chooser: Privacy" option
  • Disable the update check. Users won't be able to easily update Electrum if
    there is no new Debian package.

Revision a75ef27d (diff)
Added by segfault about 2 months ago

Disable Electrum's update check for all users (refs: #15483)

This disables the update check before starting Electrum, so even users
with an old persistent config will have this option disabled.

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

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

Any update?

#15 Updated by intrigeri 12 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 12 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 12 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 11 months ago

Relatedly: please see #16204 for the buster preparations.

#19 Updated by anonym 10 months ago

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

#20 Updated by CyrilBrulebois 8 months ago

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

#21 Updated by CyrilBrulebois 6 months ago

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

#22 Updated by intrigeri 6 months ago

  • Status changed from In Progress to Needs Validation

#23 Updated by CyrilBrulebois 4 months ago

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

#24 Updated by intrigeri 3 months 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!

#25 Updated by s7r about 2 months ago

  • Status changed from Needs Validation to Fix committed

We can finally close this issue with the next release that includes Electrum 3.3.8 as per #16421

I recommend we ship the following default new config file along with Electrum 3.3.8 and I am bringing arguments for each parameter.

coin_chooser is removed because it is deprecated anyway. Now Electrum has just one coin selection policy which aims to offer best privacy against lowest fees.
We can leave it there if we want to, but it's useless as it is simply ignored. It made sense back when Electrum had multiple coin choosing policies.

Version 1:

{
"auto_connect": true,
"check_updates": false,
"decimal_point": 8,
"num_zeros": 8,
"proxy": "socks5:localhost:9050::",
"server": ""
}

auto_connect = true -> because this is the default setting of Electrum and we want users to auto-connect to a server after they generate / restore a wallet, otherwise it might be confusing for them if they are to manually pick a server (they maybe would not know which one to choose, they maybe would think they need to trust a certain server or some irrelevant questions might raise to them if they don't know how it works under the hood, so it should stay like this).

check_updates = false -> after the phishing attack where bad actors were running malicious Electrum servers that sent rich text to users pushing them to upgrade from an untrusted source, we think the attack was particularly effective because a lot of Electrum users do not upgrade. They don't even check if newer versions are available, they mostly upgrade when the version they run doesn't work any more.

This check for new version function is simply querying electrum.org website if there is a newer version available that what is currently running. The message from electrum.org is signed using ECDSA and a Bitcoin address (private key) that is hard coded in Electrum. This way, Electrum can check itself the authenticity of the message as it already has code to sign / verify / encrypt / decrypt plain text using Bitcoin addresses / private keys and there was no need for extra code that does cryptographic operations.

The main argument for turning this off by default is because Electrum releases versions much more often than our Tails / Debian package policies. As you see, Electrum 3.3.8 took quite a long time until it was finally available in Debian/testing, and it was done because the previous version was useless and not working at all. So, I think for the forseeable future things will remain the same, in the sense that Debian/testing Electrum version will not change unless a critical bug or security flaw is found that demands upgrade.

So, it's annoying and useless for the users to be notified there is a new version of Electrum if it's not in Debian/testing so it can be easily installed into Tails. The update checker only checks that an update is available on the electrum.org website, and if users want it they should download the appimage or build from source themselves -- we know in Tails this is not trivial to do, so it might be confusing. Users that know how to do this by themselves for sure will know how to check for updates themselves or enable this feature in the config file, but for the general masses I think it should be disabled for an environment like Tails. If installing third party software would have been trivial in Tails, this could be very well enabled but it's not the case.

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.

proxy set to socks5:localhost:9050 -> so Electrum goes via Tor. the trailing :: are added automatically in config_version 3 for Electrum which is why I added them also.

server set to "" (blank) -> we do not hardcode any Electrum server because this will make all Tails Electrum users connect to that server. This might have negative effects like enumeration of number of users, seeing the addresses and balances of users, potentially overloading the server if users are too many for that server's resources and make a bad experience for everyone, plus the fact that we do not run any servers, all are run by volunteers so we do not endorse or otherwise prefer any server.

Version 2: {
"auto_connect": true,
"check_updates": false,
"proxy": "socks5:localhost:9050::",
"server": ""
}

#26 Updated by intrigeri about 2 months ago

  • Blocked by Bug #16421: Electrum Phishing Attack - Upstream Fix Committed added

#27 Updated by intrigeri about 2 months ago

  • Status changed from Fix committed to In Progress

We can finally close this issue with the next release that includes Electrum 3.3.8 as per #16421

Thank you! I've accordingly marked this ticket as blocked by #16421, then.

I recommend we ship the following default new config file along with Electrum 3.3.8 and I am bringing arguments for each parameter.

OK thanks. So we now need to implement this ⇒ setting the appropriate Status.

@segfault, would you be up to doing this on your branch for #16421?

#28 Updated by s7r about 2 months ago

I am attaching the version 1 config file as attachment with the right formatting and structure.
The last parameter intentionally does not contain trailing coma.

The file can be fetched and uploaded as it is. Its location in tails is ~/.electrum/config (or /home/amnesia/.electrum/config).

#29 Updated by s7r about 2 months ago

@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 about 2 months ago

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

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

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

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

@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 about 1 month ago

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

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.

#37 Updated by segfault about 1 month ago

  • Status changed from In Progress to Resolved

intrigeri wrote:

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.

OK, I'm closing it then, because

  • This ticket was originally about updating the config file, which was done in 549a28fce38c810dcb8f1d47b4a904d36a2c1c58.
  • We have a solution for disabling the update check (running electrum setconfig check_updates false in the electrum wrapper), see a75ef27dec474483a8c6bfaea74b178cb17a57b9

#38 Updated by intrigeri about 1 month ago

OK, I'm closing it the, because

Great, thanks!

Also available in: Atom PDF