Consider shipping Electrum as an AppImage
Several things happened lately that affected Electrum tool and lead to some open tickets on our bug tracker as well as annoyance to our users using this tool that get an "out of date" warning every time they send a transaction using Electrum:
- A "bug" was present in versions previous Electrum 3.3.3 that allowed to display to users arbitrary error messages sent by the server (servers are to be untrusted as per Electrum's design, anybody can run one) - this particular rich text error message was suggesting to the users that the transaction was not broadcasted, and upgrade is needed and indicated a link with a malware Electrum that would steal all coins in the wallet. Losses were reported.
- Due to the policy we have in Tails, we need something to be in Debian `stable-backports` in order to ship it by default. The policies in Debian, until something makes it to `stable-backports` are not so perfect with these type of applications (that handle money / finances / value) which are constantly attacked and need ways for fast upgrades.
- The package maintainer of Electrum in Debian could not work on Debian due to some circumstances in the last period, and Electrum 3.2.3 was removed from `testing`, so no chance for `stable-backports`. Currently we have bug #912042 marked as blocker for Electrum in Debian BT, that one seams trivial to fix, but even so it does not help us. There are many other dependencies as well, some are not even in Debian at all, and with the Buster freeze, it is very tight to have Electrum 3.3.4 in Buster.
- As of yesterday, server ops decided to exploit a DoS bug in the client code previous of Electrum 3.3 which kills the network thread of the client, this disabling any client running something previous Electrum 3.3 to talk with a server. This was decided because even with all the warnings, social media / other channel notifications and highlights of urgency of update, blacklists of malicious servers implemented at server side, users did not upgrade to a non vulnerable version according to server statistics. The majority were running versions vulnerable to the rich text phishing attack and were getting robbed of coins. So, it was decided, in order to protect more users from getting robbed, better permanently cut them off from the network.
Given this just happened, there are many servers our there that did not upgrade yet and are talking just fine with clients running Electrum 3.1.3 (what we have in Tails now), with the only annoyance that they get that warning about "out of date" version every time they send a transaction.
However, very soon, the Electrum 3.1.3 that we have in Tails and `stable-backports` at the moment this text is being written will NOT be able to communicate with servers thus making this tool totally useless and unusuable.
There is an AppImage for Electrum 3.3.4 on the official website. Can we use it like this in Tails? As much as I read about AppImage, I find it quite good to be used with Tails in the sense as I see no overhead nor open doors to any fishy stuff. If there's something more needed to make it work with Tails upstream, I can arrange for that. Then we just update the Electrum AppImage we ship from time to time. I am not sure if this is possible in our current system architecture, which is why I am bringing this up for discussion and looking forward to hear more opinions from devs.
Otherwise, we might be forced to take the unfortunate decision to stop including it, which would be of course make the users that got used to it not so happy, but it becomes harder and harder to keep up everything as Debian packages, not only Debian packages but also `stable-backports` Debian packages.
@s7r : I think it would be great if you can publish documentation onto how to upgrade Tails' Electrum on the Electrum website, so I can point the users to that documentation. But I will forward them with a warning of the kind 'this is not been audited or tested by the Tails team in any way'.
Here is something. It involves however some amount of steps, it's not really a two or three lines easy tutorial but hopefully easy to understand:
If we decide to use it for our users we should copy and serve under Tails official page to avoid confusions and to maintain the only official Tails domain. Of course, with a warning that this is a temporary solution that was not tested by the team -- I did however go through the steps and there's nothing wrong, it's safe to use (checked all steps).
Ok, no problem. I understood that you'd like to include it in Tails documentation / webpage. In this case I think that link is enough, for users willing to do those extra steps. For those who don't understand and can't make it work, there is no solution but to ship it as an AppImage with the udev rules set for hardware wallets.
Even if we make Electrum 3.3.4 in Debian Buster / `stable` and `stable-backports` (which is already problematic due to dependencies not in Debian at all), and we get over this, such problems might reappear. Software that handles finances / money is usually much more targeted than anything else, and while this looks fixed who knows what will reappear, and then we'd have to wait for Debian packaging -> NEW -> testing -> stable-backports ... while in the wild, things happen much faster.
For these reasons I am hoping we can make an exception and ship this tool as an AppImage, it looks much more cleaner and simpler. If not, we might remove it entirely in the next release as it will become useless without being able to connect to any server out there.
There is an AppImage for Electrum 3.3.4 on the official website. Can we use it like this in Tails?
Meta: I haven't had time to think this through yet. As said on the tails-dev list, the Foundations Team (FT) should manage to provide guidance early April. Still, in the meantime, I figured that sharing my top concerns might be useful: it could help you provide answers to these concerns before the FT discusses it in a week or so, and it could perhaps avoid folks spending too much time on what might be a dead-end. Keep in mind that I don't know much about AppImage (and while I'm somewhat curious and happy to learn, I am not motivated at all to become an advanced user, let alone an expert).
I have three main concerns:
Bundled dependencies vs. security upgrades and bugfixing¶
As far as I understood, AppImage aims at relying on the host system as little as possible, and every AppImage bundles all its dependencies. So the Electrum AppImage needs to be updated every time one of these dependencies has a security update or an important bugfix. I don't know where the components assembled in that AppImage come from but it does not matter much, as long as they come from a trusted and reliable source, such as a major Linux distribution. But it's up to the maintainer of that AppImage to update it the best they can.
So I wonder what's the trigger to update the Electrum AppImage. I assume new Electrum releases trigger an update, that's kinda obvious. But is there any process in place, be it manual or automated, to monitor security/bug fixes in the bundled dependencies, and accordingly update the AppImage?
(As a side note, Flatpak has runtimes, which are an intermediary, shared layer, with plenty of common dependencies; common runtimes are well maintained and have a good update process & policy, which makes this problem less critical: there are way less bundles deps in the apps themselves so even if their author don't have a good update policy, it's not such a huge deal.)
I understand the proposal is to ship the Electrum AppImage in the Tails images and upgrade it only when there's a new Tails release. So there's the matter of timing of AppImage updates vs. the Tails release schedule. More specifically, to ensure we won't ship a second, vulnerable copy of a dependency in the Electrum AppImage included Tails version X, while the first copy of said dependency was fixed in a Debian security update that version X will include, we would need the Electrum AppImage to be updated at a suitable time, i.e. sufficiently in advance before our freeze so we can include it, but sufficiently late to include as many fixes as possible. This seems tricky but perhaps the Electrum AppImage maintainers would be ready to align their schedule on ours (I mean, asking won't harm :)
Adding this AppImage implies we trust the binaries built by the Electrum AppImage author to a great degree:
- To do the right thing wrt. unrelated user's data: as far as I understood, AppImage has no sandboxing mechanism by default. To get some sandboxing, one needs to use appimaged (not in Debian) or do hackish stuff with Firejail; and AFAICT, these sandboxes don't use Portals or similar technology to provide a good UX for accessing resources outside of the sandbox, so one can bet it's not going to be lots of fun to import/export data to/from such a sandboxed Electrum. For the curious, https://github.com/flatpak/xdg-desktop-portal/issues/1 has some more technical details.
- To do the right thing wrt. the user's Bitcoins (yep, this is about money). Sandboxing is irrelevant here.
There are a bunch of reasons why we trust packages that come from Debian and the only third-party piece of software we ship (Tor Browser). We would need to build the same kind of trust to the people, tools, processes and infrastructure used to build, maintain, sign and distribute this AppImage. There's a good chance that's not impossible but it seems to me this would require lots of work from at least two parties: Tails core devs to express their needs, Electrum folks to satisfy them, with quite some back'n'forth to ensure we're on the same page. That would be a large investment. How long it would take, compared to maintaining Electrum in Debian, for this investment to start to return positive benefits, is unclear to me, but I bet that would be a looong time.
Long term vision¶
Long term, there's a good chance we start using Flatpak to some degree. The way I see it, it would be dealt with Flatpak repos and apps in the same way as we handle APT repositories and Additional Software: if I install a Flatpak as a user, Tails would keep it up-to-date, which avoids the "conflicting release schedules" problem altogether. The Flatpak architecture is designed in a way that would allow this; AppImage is not. So I'm somewhat wary of diverting some of our limited resources now to learn more about how to handle AppImage. That's a minor concern, compared to the 2 previous ones which are likely blockers.
Good points @intrigeri . I totally understand the implications of maintaining all dependencies bundled in the AppImage and monitoring them individually, etc. + the timing of Tails / Electrum releases. Of course anything can be worked out between both communities as it seams like goals are the same, but the process to for Tails to become to trust Electrum as much as Debian will not be easy and eat many many hours and resources we can focus on other more important stuff.
For the moment, I am convinced that the better approach here is to sponsor Electrum at Debian level so everything is more actively maintained. I plan to make this happen, bundle more Debian packagers so a single one is not the single point of failure and go on from here. I am trying to think of some solutions, if anyone is interested in helping me out on this, I can sponsor this.
My goals are to have a good, non vulnerable Electrum version in Tails that work, so all Tails/Electrum users are happy about it and can continue their projects but at the same time maintain principles used by Tails in terms of third party software and trusted upstreams, etc.
also, until we fix this, we can keep it as it is for now, as it continues to work even with annoying messages that "your version is vulnerable, please upgrade" -- I run old high capacity legacy electrum servers (that DO NOT cut off clients older than 3.3) and will continue to do so until we are good in Tails.
The user experience in this context might be worse, as probably in some cases users that are on auto connect will randomly try few servers that cut them off until they land on my servers which will allow their connection, but this shouldn't be observable too much. I have tried myself, and it's okay.