Project

General

Profile

Feature #8173

Make Ricochet usable in Tails

Added by tocard about 5 years ago. Updated 4 months ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
10/25/2014
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:

Description

ricochet.diff View (1.57 KB) cacahuatl, 07/01/2017 12:48 AM

persistence-setup-ricochet.diff View (959 Bytes) cacahuatl, 07/29/2017 11:01 PM

ricochet.jpeg View (85.7 KB) cacahuatl, 07/29/2017 11:02 PM

ricochet-apt-config.patch View (863 Bytes) cacahuatl, 01/25/2018 02:33 AM

ricochet-default-config.patch View (498 Bytes) cacahuatl, 01/25/2018 02:33 AM

ricochet-onion-grater.patch View (701 Bytes) cacahuatl, 01/25/2018 02:33 AM

ricochet-tmp-persistence-patch.patch View (1.28 KB) cacahuatl, 01/25/2018 02:34 AM


Related issues

Related to Tails - Feature #11826: Evaluate using Whonix' control-port-filter-python as Tor control port filter Resolved 09/22/2016
Related to Tails - Bug #8573: Hopefully replace Pidgin some day In Progress 01/07/2015
Blocked by Tails - Bug #10289: Tails based on Debian Stretch Resolved 09/27/2015
Blocked by Tails - Feature #7870: Include OnionShare Resolved 12/07/2016

History

#1 Updated by BitingBird about 5 years ago

  • Status changed from New to Rejected

See https://tails.boum.org/support/faq/index.en.html#index21h2

ricochet is not in Debian, you can ask again for inclusion in Tails if you get it in Debian.

#2 Updated by DansTorConnard almost 4 years ago

I think it's most your job because ricochet include an individual tor service witch can create conflict with own installation in tails.

  • On debian, install ricochet isn't a problem: just git clone and run executable...
  • But in tails, it's doesn't work ! So i think it's your job to adapte ricochet on Tails.

Thanks to read it.

#3 Updated by intrigeri almost 4 years ago

  • Status changed from Rejected to Confirmed
  • Assignee set to intrigeri

I have notes from my discussion with the Ricochet author at the Tor dev meeting, that I should report back about here.

#4 Updated by intrigeri almost 4 years ago

Quickly tested the package from sid: setup is astonishingly trivial, UX seems to have been well-thought. But it starts its own Tor (via a Tor Launcher -like UI), so next step for integration into Tails (after I retrieve and publish my notes) is probably to check how to make it use the system Tor instance, somehow.

The 1.1.1-2 package can trivially be backported to Jessie (built, not tested).

#5 Updated by sycamoreone almost 4 years ago

  • Subject changed from add ricochet ? to Add Ricochet ?

Might be a good idea to also add some notes about discussions at 32c3:

  • Ricochet controls the onion sevices through the control port, which is currently impossible in Tails due to the control-port-filter. Adding this is non-trivial, because wildcards would need to be allowed in the control port filter. (OnionShare is also needing this.)
  • It would be cool to have the AppArmour profile installed.

#7 Updated by intrigeri almost 4 years ago

  • Description updated (diff)

#8 Updated by intrigeri over 3 years ago

  • Related to Feature #6742: Make tor-controlport-filter reusable added

#9 Updated by intrigeri over 3 years ago

  • Subject changed from Add Ricochet ? to Add Ricochet?

See #6742 for pointers wrt. control port filter implementations.

#10 Updated by intrigeri over 3 years ago

  • Assignee deleted (intrigeri)
  • Type of work changed from Communicate to Research

Dropping that from my radar for now. We'll see once there has been progress on the control port filter situation.

#11 Updated by intrigeri about 3 years ago

  • Related to Feature #11826: Evaluate using Whonix' control-port-filter-python as Tor control port filter added

#12 Updated by special almost 3 years ago

I still get asked about this very often. It looks like there's great progress with OnionShare in #7870 -- what still needs to be done to get Ricochet on tails?

In case it's useful:

Ricochet packages are in Debian, and the latest (1.1.4) uses ADD_ONION and will respect TOR_CONTROL_PORT in the environment (like Tor Browser does). If that is set, Ricochet will not launch another tor. The hidden service listener is bound to localhost:0, and that can't currently be modified through the environment.

Ricochet doesn't currently use unix sockets, but the code exists and we will be preferring them once the remaining issues are solved. Is TCP or unix better for the service listener from the tails perspective?

On the control port, Ricochet needs:

SETEVENTS STATUS_CLIENT
# also the asynchronous CIRCUIT_ESTABLISHED, CIRCUIT_NOT_ESTABLISHED, and BOOTSTRAP event replies
GETINFO status/circuit-established status/bootstrap-phase net/listeners/socks
ADD_ONION

Let me know if there's anything we can do to help.

#13 Updated by intrigeri almost 3 years ago

  • Blocked by Bug #10289: Tails based on Debian Stretch added

#14 Updated by intrigeri almost 3 years ago

#15 Updated by intrigeri almost 3 years ago

  • Related to deleted (Feature #6742: Make tor-controlport-filter reusable)

#16 Updated by intrigeri almost 3 years ago

  • Assignee set to segfault
  • QA Check set to Info Needed

Hi!

I still get asked about this very often. It looks like there's great progress with OnionShare in #7870 -- what still needs to be done to get Ricochet on tails?

Thanks for the heads up! Indeed, once #7870 is done the main blocker for adding Ricochet (fine-grained filtering of the communication with the control port) will be removed :)

Ricochet packages are in Debian,

(Stretch) ⇒ marked as blocked by #10289. Tails 3.0, based on Stretch, is tentatively scheduled for 2017-06-13. Now, if someone maintains a backport for Jessie, we can do it earlier; personally, given we'll be moving to Stretch soonish, I'm not going to commit to maintaining such a backport for the next 3.5 years.

and the latest (1.1.4) uses ADD_ONION and will respect TOR_CONTROL_PORT in the environment (like Tor Browser does). If that is set, Ricochet will not launch another tor. The hidden service listener is bound to localhost:0, and that can't currently be modified through the environment.

Excellent. That was the other major blocker!

Ricochet doesn't currently use unix sockets, but the code exists and we will be preferring them once the remaining issues are solved. Is TCP or unix better for the service listener from the tails perspective?

At first glance I would say "Unix socket" since that's easier to mediate with AppArmor, but really I am not sure ⇒ I'm adding segfault (who's been working on such topics as part of the Tails Server project) into the loop. segfault, what do you think?

On the control port, Ricochet needs:

> SETEVENTS STATUS_CLIENT
> # also the asynchronous CIRCUIT_ESTABLISHED, CIRCUIT_NOT_ESTABLISHED, and BOOTSTRAP event replies
> GETINFO status/circuit-established status/bootstrap-phase net/listeners/socks
> ADD_ONION
> 

anonym, would our upcoming new Tor control port filter support this?

#17 Updated by anonym almost 3 years ago

intrigeri wrote:

Ricochet doesn't currently use unix sockets, but the code exists and we will be preferring them once the remaining issues are solved. Is TCP or unix better for the service listener from the tails perspective?

At first glance I would say "Unix socket" since that's easier to mediate with AppArmor, but really I am not sure ⇒ I'm adding segfault (who's been working on such topics as part of the Tails Server project) into the loop. segfault, what do you think?

Note that the filter only serves clients using TCP, so that's what we'll want to use, actually. Of course, having it also serve over a filtered unix socket should be pretty easy to implement, but AFAICT AppArmor won't add anything on top of the access rights that the filter manages. Any way, I think we should be consistent and just stick with TCP -- all applications controlling Tor can do it over TCP, but not all supports unix sockets.

On the control port, Ricochet needs:

[...]

anonym, would our upcoming new Tor control port filter support this?

Yes. There shouldn't be anything expressible in the Tor control language that the filter cannot handle.

#18 Updated by intrigeri almost 3 years ago

Note that the filter only serves clients using TCP, so that's what we'll want to use, actually. Of course, having it also serve over a filtered unix socket should be pretty easy to implement, but AFAICT AppArmor won't add anything on top of the access rights that the filter manages. Any way, I think we should be consistent and just stick with TCP -- all applications controlling Tor can do it over TCP, but not all supports unix sockets.

I think that special's question was not about the connection to the control port, but about the listener service, i.e. Ricochet listening to connections to its hidden service, relayed to it by Tor.

Yes. There shouldn't be anything expressible in the Tor control language that the filter cannot handle.

\o/

#19 Updated by segfault almost 3 years ago

  • Assignee deleted (segfault)
  • QA Check deleted (Info Needed)

Ricochet doesn't currently use unix sockets, but the code exists and we will be preferring them once the remaining issues are solved. Is TCP or unix better for the service listener from the tails perspective?

At first glance I would say "Unix socket" since that's easier to mediate with AppArmor, but really I am not sure ⇒ I'm adding segfault (who's been working on such topics as part of the Tails Server project) into the loop. segfault, what do you think?

I must admit, I did not look much into using unix sockets instead of TCP sockets in Tails Server. Unix sockets are not supported by all applications, so I'm currently only using TCP. But if the application supports it, it seems to have only benefits. I created #12024 to look more into this re Tails Server.

#20 Updated by cacahuatl over 2 years ago

Tentative patch for Tails on Tor.

It "works" but it needs:
  • AppArmor Profile (it's in the github repo but not shipped with it in debian?)
  • Persistence Config

#21 Updated by cacahuatl over 2 years ago

cacahuatl wrote:

Tails on Tor.

jfc i need sleep, ricochet on tails.

#22 Updated by intrigeri over 2 years ago

  • Status changed from Confirmed to In Progress

Tentative patch for Tails on Tor.

Great to see progress on this front.

It "works" but it needs:
  • AppArmor Profile (it's in the github repo but not shipped with it in debian?)

If it's part of an upstream release yet, then please ask the ricochet-im maintainer(s) to ship the profile. I'll give them a hand.

I guess we need an onion-grater config too (and I assume, no time to look right now, that it's in your patch). IMO it would be nicer to ship it in the package itself as well (we want to upload onion-grater to Debian at some point and in the meantime it doesn't hurt).

#23 Updated by cacahuatl over 2 years ago

I've spoken to the ricochet-im debian maintainer, I wrote a patch for their build process to include the apparmor profile as the standard build but they asked that I pushed it upstream, which I have done.

There is now a pull request0 open on the ricochet github to make some changes to the apparmor profile and to include it in the build process when building a non-portable build.

Once/If the PR is accepted, this should clear the way for the debian package to come with the apparmor profile.

There is an onion-grater profile in the patch I submitted.

[0] - https://github.com/ricochet-im/ricochet/pull/549

#24 Updated by intrigeri over 2 years ago

Amazing!

What about assigning this ticket to yourself? :)

#25 Updated by cacahuatl over 2 years ago

I'll definitely need help with ther persistence setup changes, to allow users to keep a ricochet identity between reboots.

I had a look at it, but it's in perl and I have absolutely no experience with perl.

For that, the only file that would need to be kept is:

${HOME}/.local/share/Ricochet/ricochet/ricochet.json

This stores the onion private key, contact lists and other configuration options.

#26 Updated by intrigeri over 2 years ago

I'll definitely need help with ther persistence setup changes, to allow users to keep a ricochet identity between reboots.

Sure.

I had a look at it, but it's in perl and I have absolutely no experience with perl.

For that, the only file that would need to be kept is:

> ${HOME}/.local/share/Ricochet/ricochet/ricochet.json
> 

I think the Electrum preset should be a good source of inspiration:
https://git-tails.immerda.ch/persistence-setup/tree/lib/Tails/Persistence/Configuration/Presets.pm#n137

You already said what destination should be, IMO source=ricochet will be fine, we'll need:

  • an icon_name that can be found in one of the paths referenced by append_search_path in lib/Tails/Persistence/Configuration/Button.pm; perhaps we'll need to ship it in Tails even though we don't ship Ricochet though;
  • a name and description validated by our UX folks.

I'm happy to write the code once you've gathered all this info :)

#27 Updated by cacahuatl over 2 years ago

This should do the trick.

I tested it on an ISO that I built and was able to successfully persist my Ricochet identity and keys.

#28 Updated by cacahuatl over 2 years ago

Upstream pull request to include apparmor in the build process for ricochet has been merged, now I'm back to talking to the Debian maintainer to get the new functionality included in the debian package itself.

#29 Updated by tailsuser about 2 years ago

Hello guys,

tried installing Ricochet-IM in Tails via 'sudo apt-get update && sudo apt-get install ricochet-im', which did work, Ricochet-IM starts, but if I click on 'connect', then nothing happens. Same goes for after the network configuration.

Any hints on what to you?

Would really love to get this going :)

Best wishes to all of you!

#30 Updated by cacahuatl about 2 years ago

My apparmor patch has made it into Debian unstable

https://tracker.debian.org/news/880280

However, the maintainer has come across some audit complaints from apparmor. They don't seem to break functionality (although maybe some functionality like screenreaders and such would be broken by restricted access to the desktop environment?).

I've proposed an improvement, to allow the abstractions for gnome, xdg-desktop and wayland from debians existing apparmor profiles.

They're quire permissive apparmor profiles, on the whole, I've proposed the improvement to the maintainer and you can see the proposed apparmor profile here:

https://github.com/epidemics-scepticism/ricochet/commit/3cfb09fbae632c13eb792928355766e3e2820cc3#diff-8390fd29b96c4bff2662f03106569f2f

Any feedback would be welcomed.

Thanks.

#31 Updated by intrigeri about 2 years ago

I suggest asking for feedback on the AppArmor mailing list: .

#32 Updated by u almost 2 years ago

  • Related to Bug #8573: Hopefully replace Pidgin some day added

#33 Updated by u almost 2 years ago

  • Assignee set to cacahuatl

@cacahuatl, thanks for your work on this! Did you manage to get feedback on the apparmor profile? It looks like this would be the only remaining blocker?

#34 Updated by cacahuatl almost 2 years ago

The apparmor profile is already included in sid, so it might require pinning to get it included from the debian package. I'm not sure about getting it into stretch.

Other than that, there's:

- adding a couple of lines to the Persistence Setup to keep keys, configs, contacts (patch already included, maybe needs rephrasing)
- the onion-grater profile (patch included)
- A ricochet.json to be added to chroot includes under /etc/skel to it's pre-configured to use the existing Tor instance (also included)

So it unfortunately still does require some changes from simply installing the stock debian package.

#35 Updated by cacahuatl almost 2 years ago

Scratch that, every attempt I make to build it with ricochet-im from sid results in a dependency hellscape with libqt5* libraries...more work needed i guess.

These are my current patches:

  • ricochet-apt-config.patch: my (currently failed) attempt to configure apt pinning for ricochet-im to include the version with the apparmor profile included.
  • ricochet-default-config.patch: default ricochet config from /etc/skel to get it to use the existing Tor's control port and listen on a port (currently using one of the ones which is earmarked for onion-share) which is reachable by debian-tor to amnesia.
  • ricochet-onion-grater.patch: adds the onion-grater profile.
  • ricochet-tmp-persistence-patch.patch: a patch to add a patch to persistence setup so it will handle ricochet, simplest hack to get a test build working, not intended to exist if it makes it to production.

#36 Updated by Kurtis over 1 year ago

Any updates on this front? I just tried installing Ricochet using the Additional Software feature and I'm getting the same result as this Tails user. https://labs.riseup.net/code/issues/8173#note-29

#37 Updated by sajolida over 1 year ago

Disclaimer: I haven't full read or understood the technical details involved here.

With my UX hat on, I'm thinking about whether Ricochet would be worth adding to Tails by default, instead of for example, leaving it up to users to install it using Additional Software.

Seeing the popcon of Ricochet (https://qa.debian.org/popcon.php?package=ricochet), I would say that we shouldn't add Ricochet to Tails as a way of communicating between Tails and the rest of the world. If we want to do that we should focus on #14567 instead.

Now, if Ricochet allows for an easy way to communicate between Tails installations (for example between different people from a group who operates only from Tails) and without the need for a phone number or an XMPP account for example, then it might become more interesting. If we think that in-between Tails messaging is a worthy goal in and off itself...

And if we don't want to add Tails by default in Tails, maybe the work to integrate it with how Tor works in Tails should be done in a way that can be included in the upstream Debian package directly. But this is the part that I haven't read or fully understood.

#38 Updated by intrigeri over 1 year ago

Seeing the popcon of Ricochet (https://qa.debian.org/popcon.php?package=ricochet), I would say that we shouldn't add Ricochet to Tails as a way of communicating between Tails and the rest of the world. If we want to do that we should focus on #14567 instead.

Fully agreed.

Now, if Ricochet allows for an easy way to communicate between Tails installations (for example between different people from a group who operates only from Tails) and without the need for a phone number or an XMPP account for example, then it might become more interesting.

Indeed.

If we think that in-between Tails messaging is a worthy goal in and off itself...

I have no strong opinion on that. This question relates to our strategic planning process. At first glance, my hunch is that while this use case definitely exists (there are groups who decided to use Tails, and only Tails, for their internal communications), the number of users who would benefit from it is waaaay smaller than the number of users who want to use Tails to communicate with people who don't use Tails, and thus I'm inclined to treat #14567 with much bigger priority than adding Ricochet support.

And if we don't want to add Tails by default in Tails, maybe the work to integrate it with how Tor works in Tails should be done in a way that can be included in the upstream Debian package directly.

Absolutely. My understanding is that this boils down to adding the onion-grater config snippet to the upstream tarball or Debian packaging (even though onion-grater is not in Debian yet).

#39 Updated by sajolida over 1 year ago

At first glance, [...] the number of users who would benefit from it is waaaay smaller than the number of users who want to use Tails to communicate with people who don't use Tails, and thus I'm inclined to treat #14567 with much bigger priority than adding Ricochet support.

Of course :)

#40 Updated by cypherpunks over 1 year ago

sajolida wrote:

Now, if Ricochet allows for an easy way to communicate between Tails installations (for example between different people from a group who operates only from Tails) and without the need for a phone number or an XMPP account for example, then it might become more interesting. If we think that in-between Tails messaging is a worthy goal in and off itself...

That is exactly what it does. All it requires is an internet connection. It fundamentally works the same as TorChat, but is actively maintained and more feature-rich.

#41 Updated by u over 1 year ago

  • Subject changed from Add Ricochet? to Make Ricochet usable in Tails

I propose to turn this ticket into a request to the Debian maintainers:

  • And if we don't want to add Ricochet by default in Tails, maybe the work to integrate it with how Tor works in Tails should be done in a way that can be included in the upstream Debian package directly. This boils down to adding the onion-grater config snippet to the upstream tarball or Debian packaging (even though onion-grater is not in Debian yet).

#42 Updated by sajolida about 1 year ago

Upstream has seen no commit in a year: https://github.com/ricochet-im/ricochet/commits/master.

#43 Updated by Kurtis about 1 year ago

The upstream ticket about integrating Ricochet in Tails that is listed in the description in this issue has been closed [1] in favor of this new ticket [2]. Can someone update the description to reflect this?

People are saying in the new upstream issue thread that there's a way to get Ricochet working in Tails, but you have to apply a patch and build Tails yourself.

[1] https://github.com/ricochet-im/ricochet/issues/31#issuecomment-258307285
[2] https://github.com/ricochet-im/ricochet/issues/452

#44 Updated by sajolida 4 months ago

  • Status changed from In Progress to Rejected
  • Assignee deleted (cacahuatl)

Ricochet has seen no release since November 2016:

I think it's a dead project and we shouldn't add it to Tails.

Also available in: Atom PDF