Tails

#2 Updated by DansTorConnard 2015-12-10 01:21:25

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.

#4 Updated by intrigeri 2016-01-02 22:54:43

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

#6 Updated by intrigeri 2016-01-10 21:20:43

Whonix are working to add wildcard support to their control port filter implementation (https://github.com/Whonix/control-port-filter-python, https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy):

• https://phabricator.whonix.org/T446
• https://phabricator.whonix.org/T445
• https://www.whonix.org/wiki/Next#onionshare
• https://phabricator.whonix.org/T448

#12 Updated by special 2016-12-08 05:49:32

I still get asked about this very often. It looks like there’s great progress with OnionShare in Feature #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.

#17 Updated by anonym 2016-12-08 10:59:51

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 2016-12-08 12:24:40

> 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/

#21 Updated by cacahuatl 2017-07-01 00:53:37

cacahuatl wrote:
> Tails on Tor.
jfc i need sleep, ricochet on tails.

#23 Updated by cacahuatl 2017-07-23 19:51:51

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 request[0] 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 2017-07-24 05:38:49

Amazing!

What about assigning this ticket to yourself? :)

#25 Updated by cacahuatl 2017-07-26 23:00:57

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 2017-07-27 05:53:57

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

#28 Updated by cacahuatl 2017-08-16 23:08:41

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 2017-09-09 20:18:52

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 2017-10-23 21:54:46

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 2017-10-29 09:17:53

I suggest asking for feedback on the AppArmor mailing list: apparmor@lists.ubuntu.com.

#34 Updated by cacahuatl 2018-01-20 19:10:42

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.

#36 Updated by Kurtis 2018-05-30 22:51:34

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 2018-06-01 19:00:45

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 Feature #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 2018-06-02 10:02:34

> 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 Feature #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 Feature #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 2018-06-03 10:40:16

> 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 Feature #14567 with much bigger priority than adding Ricochet support.

Of course :)

#40 Updated by cypherpunks 2018-06-04 05:01:21

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.

#42 Updated by sajolida 2018-08-21 14:49:25

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

#43 Updated by Kurtis 2018-11-16 22:44:41

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