Tails

#1 Updated by emmapeel 2019-03-16 05:53:18

@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’.

#4 Updated by s7r 2019-03-17 00:49:16

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:

https://blog.thestever.net/2019/02/26/upgrading-electrum-on-tails-to-3-3-4/

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).

#5 Updated by emmapeel 2019-03-17 09:54:12

I am sorry, I may have mislead you. I didn’t meant to post it as an official Tails recommendation, as we haven’t assessed the software and neither has Debian.

#6 Updated by s7r 2019-03-17 19:54:18

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.

#8 Updated by intrigeri 2019-03-23 15:10:23

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

Trust

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.

#9 Updated by s7r 2019-03-24 21:09:01

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.

#10 Updated by s7r 2019-03-24 21:14:37

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.