Project

General

Profile

Bug #14649

Ship OnionShare 2.0 in Tails

Added by u over 1 year ago. Updated 22 days ago.

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
09/13/2017
Due date:
% Done:

0%

QA Check:
Feature Branch:
Type of work:
Debian
Blueprint:
Starter:
Affected tool:

Description

- We need to test the package in Tails, I am specifically wondering if the receiver mode works as expected.

TODO In Debian:

- I did not enable the AppArmor profiles in the package. I would like to tackle that in a future upload.


Related issues

Related to Tails - Bug #15549: Defunct onionshare-gui process Rejected 04/20/2018
Related to Tails - Feature #11929: Upstream AppArmor profiles for Onionshare Resolved 11/16/2016
Duplicated by Tails - Feature #15326: Onionshare Duplicate 02/18/2018 03/25/2018
Blocks Tails - Bug #15396: Core work Debian 2019Q1-2019Q2 Confirmed 02/08/2019

Associated revisions

Revision 6a21e653 (diff)
Added by intrigeri 11 months ago

Install OnionShare from our custom APT repo instead of from sid (refs: #14649)

We have no strong reason to track sid and upgrading Tails to the version that's
currently in sid requires quite some work. Let's do this for Tails 4.0

History

#1 Updated by u over 1 year ago

  • Subject changed from Onionshare to Package, test and upload new upstream version of Onionshare

#2 Updated by u over 1 year ago

  • Target version set to Tails_3.3

#3 Updated by intrigeri over 1 year ago

  • Parent task deleted (#14646)

#4 Updated by intrigeri over 1 year ago

  • Blocks Bug #14646: Core work 2018Q1 → 2018Q2: Debian added

#5 Updated by u over 1 year ago

  • Target version changed from Tails_3.3 to Tails_3.5

I want to clear my view and focus on the donation campaign.

#6 Updated by u over 1 year ago

  • Target version changed from Tails_3.5 to Tails_3.6

#7 Updated by emmapeel about 1 year ago

#8 Updated by bertagaz about 1 year ago

  • Target version changed from Tails_3.6 to Tails_3.7

#9 Updated by u about 1 year ago

Uploaded version 1.3 to Debian unstable today: https://tracker.debian.org/pkg/onionshare Tested it only in Debian and it works great. We should test this in Tails. Next week I'll prepare a backport.

#10 Updated by emmapeel about 1 year ago

Not sure if OnionSHare is supposed to work on it, but while testing the ISO for the Additional Software I tried to use Onionshare and I could not use it.

There was a configuration to do with Tor, I configured it to use SocksPort 9050, but when saving the config, Onionshare crashes.

The ISO I was using was https://nightly.tails.boum.org/build_Tails_ISO_feature-14594-asp-gui/lastSuccessful/archive/

#11 Updated by u about 1 year ago

I've not yet tested that myself. I plan to work on this next week. Note that the problem you report might be due to Onionshare's apparmor profile not allowing to save a tor configuration file. It might even be that this is work to be done by the foundations team.

#12 Updated by u about 1 year ago

  • Related to Bug #15549: Defunct onionshare-gui process added

#13 Updated by u about 1 year ago

Testing on Debian first:

- user needs to be in debian-tor group to use system tor instead of bundled tor
- torrc needs to have control port open / or we could use a socket file
- Config is written here: /home/user/.config/onionshare/onionshare.json

Also see https://github.com/micahflee/onionshare/wiki/Connecting-to-Tor

#14 Updated by u about 1 year ago

  • Assignee changed from u to intrigeri
  • QA Check set to Info Needed

Testing in Tails 3.6.2:

  1. Onionshare attempts to use built-in tor to connect.
  2. I tell it to use system tor, but it cannot write ~/.config/onionshare/onionshare.json. This is indeed due to an AppArmor problem:
    Apr 24 18:42:43 amnesia audit[29787]: AVC apparmor="DENIED" operation="open" profile="/usr/bin/onionshare-gui" name="/home/amnesia/.config/onionshare/onionshare.json" pid=29787 comm="onionshare-gui" requested_mask="r" denied_mask="r" fsuid=1000 ouid=10
    Apr 24 18:42:43 amnesia audit[29787]: AVC apparmor="DENIED" operation="open" profile="/usr/bin/onionshare-gui" name="/home/amnesia/.config/onionshare/onionshare.json" pid=29787 comm="onionshare-gui" requested_mask="wc" denied_mask="wc" fsuid=1000 ouid=
    

So, I've modified /etc/apparmor.d/usr.bin/onionshare in order to allow reading and writing @{HOME}/.config/onionshare/onionshare.json and I've manually created this file to contain what Onionshare generated on a usual Debian:

{"tor_bridges_use_meek_lite_azure": false, "control_port_address": "127.0.0.1", "hidservauth_string": "", "use_autoupdate": true, "systray_notifications": true, "tor_bridges_use_meek_lite_amazon": true, "shutdown_timeout": false, "close_after_first_download": true, "connection_type": "control_port", "control_port_port": 9051, "socks_address": "127.0.0.1", "save_private_key": false, "socket_file_path": "/var/run/tor/control", "auth_type": "no_auth", "version": "1.3", "slug": "", "no_bridges": false, "auth_password": "", "tor_bridges_use_custom_bridges": "", "private_key": "", "autoupdate_timestamp": null, "socks_port": 9050, "tor_bridges_use_obfs4": false, "use_stealth": false}

Then I can run Onionshare 1.3 from within Tails. (Downloadable .deb available here: https://packages.debian.org/sid/all/onionshare/download)

Now it seems we have to do quite some things here:

- In the settings users can choose to run Onionshare using the built-in tor. * Do we want to hide this option? If yes, how would we do that? * If no, there is another apparmor rule disallowing to run this tor daemon:

Apr 24 18:49:00 amnesia audit[30019]: AVC apparmor="DENIED" operation="exec" profile="/usr/bin/onionshare-gui" name="/usr/bin/tor" pid=30019 comm="onionshare-gui" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
Apr 24 18:49:00 amnesia kernel: audit: type=1400 audit(1524595740.764:197): apparmor="DENIED" operation="exec" profile="/usr/bin/onionshare-gui" name="/usr/bin/tor" pid=30019 comm="onionshare-gui" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
Apr 24 18:49:00 amnesia onion-grater[2558]: /usr/bin/onionshare-gui (pid: 29998, user: amnesia, port: 35224, filter: onionshare) disconnected: client quit

Similarly the options to
- run using socket file
- automatic configuration
- stealth service
- use system tor with a password

should either be hidden or made functional IMO.

What does the foundations team think about it?

#15 Updated by u about 1 year ago

I have some more infos:

- I opened an issue upstream to update the AppArmor profiles https://github.com/micahflee/onionshare/issues/686

- I saw that in the Debian packaging they are not automatically installed. I made a commit to change this but I want to wait until we have working profiles before I upload a new version of Onionshare. See https://salsa.debian.org/pkg-privacy-team/onionshare/commit/db02265185dba5f80dcd42071f2fdf89c44ebdde

- In Tails, on top of permission problems/AppArmor, there are some problems talking to the control port:

Apr 24 20:06:32 amnesia onion-grater[2558]: /usr/bin/onionshare-gui (pid: 31235, user: amnesia, port: 35246, filter: onionshare): command filtered: GETCONF hiddenservicesinglehopmode
Apr 24 20:06:32 amnesia onion-grater[2558]: /usr/bin/onionshare-gui (pid: 31235, user: amnesia, port: 35246, filter: onionshare): command filtered: ADD_ONION NEW:RSA1024 Port=80,17623
Apr 24 20:06:35 amnesia onion-grater[2558]: /usr/bin/onionshare-gui (pid: 31235, user: amnesia, port: 35246, filter: onionshare): command filtered: DEL_ONION

I don't know how to fix those. To reproduce: try sharing a file and click "Start server".

#16 Updated by intrigeri about 1 year ago

  • Assignee changed from intrigeri to u
  • QA Check changed from Info Needed to Dev Needed
- In the settings users can choose to run Onionshare using the built-in tor.
  • Do we want to hide this option? If yes, how would we do that?

Similarly the options to
- run using socket file
- automatic configuration
- stealth service
- use system tor with a password

should either be hidden or made functional IMO.

I would:

  1. submit a wishlist issue upstream: ideally we would want an opt-in config file setting that hides all the bits we don't want to display in the GUI
  2. patch onionshare_gui/settings_dialog.py in Tails (config/chroot_local-patches/) to hide the settings we don't want to display (I'll need a complete list)
  3. point the upstream issue to that patch so it's clearer what exactly we need that new setting to do

You could do the former and I do the 2 latter items, both in time for Tails 3.9 (I doubt we'll upgrade OnionShare in a bugfix release). What do you think?

About "stealth service" I don't know what it is about so I can't have an informed opinion.

#17 Updated by intrigeri about 1 year ago

- I opened an issue upstream to update the AppArmor profiles
- I saw that in the Debian packaging they are not automatically installed. I made
a commit to change this but I want to wait until we have working profiles before
I upload a new version of Onionshare.

I'm not sure it's worth installing these profiles on Debian:

  • On Debian we need all OnionShare usage modes (system and bundled Tor) to work so the corresponding AppArmor profile would need to be more permissive than what we want on Tails.
  • The only reason why we added AppArmor confinement was for Onion Grater, which is not in Debian.

OTOH having these profiles included in the Debian package would simplify maintenance on our side (currently we ship them via tails.git). So I think we should ship them in the Debian package, but disabled by default (really disabled, not in complain mode).

- In Tails, on top of permission problems/AppArmor, there are some problems talking to the control port:
I don't know how to fix those. To reproduce: try sharing a file and click "Start server".

Probably we'll need to edit config/chroot_local-includes/etc/onion-grater.d/onionshare.yml. We (Foundations Team) will do that in time for Tails 3.9 once the other blockers are gone. But no emergency, if we don't manage to port our stuff in time, we could actually stick to OnionShare 0.9.x in Tails 3.x and upgrade to 1.3+ only in Tails 4.x :)

#18 Updated by intrigeri about 1 year ago

  • Subject changed from Package, test and upload new upstream version of Onionshare to Package, test and upload OnionShare 1.3

Actually I think we're mixing up two things on this ticket:

  • having the latest upstream version of OnionShare in Debian (+ backports): this is what this ticket is primarily about and I think the only remaining tasks are
    • ship the AppArmor profiles (disabled) and upload
    • upload to stretch-backports once the new upload has made it into testing
  • upgrading to OnionShare 1.3 in Tails: that's another matter, another team and another timeline, so IMO we should move this part of the discussion to another ticket

#19 Updated by bertagaz about 1 year ago

  • Target version changed from Tails_3.7 to Tails_3.8

#20 Updated by intrigeri 11 months ago

  • Target version changed from Tails_3.8 to Tails_3.9

#21 Updated by intrigeri 11 months ago

  • Status changed from Confirmed to In Progress

#22 Updated by u 9 months ago

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

#23 Updated by u 9 months ago

  • Blocks deleted (Bug #14646: Core work 2018Q1 → 2018Q2: Debian)

#24 Updated by u 9 months ago

  • Blocks Bug #15396: Core work Debian 2019Q1-2019Q2 added

#25 Updated by intrigeri 7 months ago

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

#26 Updated by u 5 months ago

  • Subject changed from Package, test and upload OnionShare 1.3 to Package, test and upload OnionShare 1.3.2

I've uploaded this today to fix a pending CVE. I did not (yet) include the apparmor profiles. I've scheduled more time for this later this month.

#27 Updated by CyrilBrulebois 5 months ago

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

#28 Updated by anonym 4 months ago

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

#29 Updated by intrigeri 3 months ago

  • Related to Feature #11929: Upstream AppArmor profiles for Onionshare added

#30 Updated by u 3 months ago

  • Subject changed from Package, test and upload OnionShare 1.3.2 to Package, test and upload OnionShare 2.0

#31 Updated by CyrilBrulebois 2 months ago

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

#32 Updated by u 2 months ago

  • QA Check deleted (Dev Needed)

Uploaded 2.0 to sid.
It works great. But

- I opened a bug upstream with my concern about shipping a built-in Tor version https://github.com/micahflee/onionshare/issues/949 (how to update in case of security issues?) → I hope to tackle this in a future upload of OnionShare → that was solved.

- We need to test the package in Tails, I am specifically wondering if the receiver mode works as expected.

- I did not enable the AppArmor profiles in the package. I would like to tackle that in a future upload.

- There is #15731.

#33 Updated by u 2 months ago

  • Subject changed from Package, test and upload OnionShare 2.0 to Test OnionShare 2.0 in Tails
  • Status changed from In Progress to Confirmed

I'm repurposing this ticket for the time being.

#34 Updated by u 2 months ago

  • Description updated (diff)

#35 Updated by u about 2 months ago

  • Description updated (diff)

#36 Updated by u about 1 month ago

Quick tests

- Apparmor:
- @{HOME}/.config/onionshare folder cannot be created. This folder will hold onionshare.json config file.
( this seems to have been addressed in 85d3f210804b69d675125b7d9e74753662009065. @intrigeri: was this change upstreamed?)
- A non existing folder $HOME/OnionShare is the default location to store received files. This folder needs to be created, which is problematic WRT Apparmor. → @sajolida: This is also an issue for UX: do we want to have another top level folder in the home directory, that some people might not use? Or is this actually good, so people know about onionshare?
- Default Tor used is "built-in", and needs to be manually changed to "connect using control port" which works.
This can be mitigated by shipping a working onionshare.json config file. I think this is work for FT. (And maybe 6cd5d82da30d4b7ce752d476eb054321cd3f63f8 / #16306 addresses this, but I could not test it as I would need a nightly build for this.)
- version of tor does not support ephemeral onion services yet.
- there is an issue with /etc/machine-id (This was addressed by #16306 but I could not test this modification.)

I tested this only with Tails 3.11 (because this was the only version I have available and I'm currently on a mobile network, so no way to download a more recent image).

I'll do more testing once the network is back for me.

#37 Updated by intrigeri about 1 month ago

- @{HOME}/.config/onionshare folder cannot be created. This folder will hold onionshare.json config file.
( this seems to have been addressed in 85d3f210804b69d675125b7d9e74753662009065. intrigeri: was this change upstreamed?)

No, it was not upstreamed: these changes were tested with the version that's in Buster (1.3.2-1) and I had no idea if they would work with 2.0.

#38 Updated by u about 1 month ago

intrigeri wrote:

- @{HOME}/.config/onionshare folder cannot be created. This folder will hold onionshare.json config file.
( this seems to have been addressed in 85d3f210804b69d675125b7d9e74753662009065. intrigeri: was this change upstreamed?)

No, it was not upstreamed: these changes were tested with the version that's in Buster (1.3.2-1) and I had no idea if they would work with 2.0.

I'll look into it this week and will upstream the corresponding changes if necessary.

#39 Updated by u 29 days ago

I'm now retesting in feature/buster using Onionshare 2.0-3 from Debian.

- Apparmor:
- @{HOME}/.config/onionshare folder cannot be created. This folder will hold onionshare.json config file.
( this seems to have been addressed in 85d3f210804b69d675125b7d9e74753662009065. @intrigeri: was this change upstreamed?)

Looks good in Tails feature/buster.

TODO: upstream this part of the code.

- A non existing folder $HOME/OnionShare is the default location to store received files. This folder needs to be created, which is problematic WRT Apparmor. → @sajolida: This is also an issue for UX: do we want to have another top level folder in the home directory, that some people might not use? Or is this actually good, so people know about onionshare?

TODO: Enable reading and writing to this folder in Apparmor files for Onionshare.
TODO: Ship this folder by default in Tails? → input needed from @intrigeri and @sajolida

- Default Tor used is "built-in", and needs to be manually changed to "connect using control port" which works.
This can be mitigated by shipping a working onionshare.json config file. I think this is work for FT. (And maybe 6cd5d82da30d4b7ce752d476eb054321cd3f63f8 / #16306 addresses this, but I could not test it as I would need a nightly build for this.)

Works fine in the nightly build.

- version of tor does not support ephemeral onion services yet.

feature/buster comes with Tor 3.5.8.

- there is an issue with /etc/machine-id (This was addressed by #16306 but I could not test this modification.)

This is fixed in feature/buster.

However, Onionshare 2.0-3 does not work in Tails Buster. Whenever I want to share a file or receive a file I get the following error : ""ADD_ONION response didn't have an OK status: command filtered". This error comes from stem (https://stem.torproject.org/_modules/stem/response/add_onion.html). Any idea what this is about? I think it happens when an OnionService needs to be set up. (OnionCircuits also had an issue with stem recently: #16626.)

So if we want to provide OnionShare > 2.0 in Tails we need to fix this.

#40 Updated by intrigeri 25 days ago

Meta: I'm happy to provide occasional guidance when needed here, but given this is about new features, not a blocker for 4.0 (Buster will ship with OnionShare 1.3), and thus not core work for now, I'll take it easy.

TODO: Ship this folder by default in Tails? → input needed from intrigeri and sajolida

I see no technical reason against shipping it. UX might be a different matter. I guess it's somewhat related to the Tor Browser downloads directory ongoing discussion.

However, Onionshare 2.0-3 does not work in Tails Buster. Whenever I want to share a file or receive a file I get the following error : ""ADD_ONION response didn't have an OK status: command filtered". This error comes from stem (https://stem.torproject.org/_modules/stem/response/add_onion.html). Any idea what this is about? I think it happens when an OnionService needs to be set up. (OnionCircuits also had an issue with stem recently: #16626.)

Likely config/chroot_local-includes/etc/onion-grater.d/onionshare.yml needs an update: either to allow the newly needed control verb/arguments, or to send back a dummy answer, or something.

#41 Updated by sajolida 24 days ago

@sajolida: This is also an issue for UX: do we want to have another top level folder in the home directory, that some people might not use? Or is this actually good, so people know about onionshare?

Do you know if there's any reason why OnionShare decided to use a custom
"OnionShare" folder instead of using the generic "Downloads" folder?

If you don't know I'll have a quick look at the OnionShare tracker and
code. If there's no good reason, I would propose to use "Downloads" in
Tails (and propose this upstream as well).

You said it's the default location, but do I understand correctly and
people are prompted anyway about where to save the file before it is saved?

#42 Updated by u 24 days ago

@sajolida: I don't know why this folder is used. Users are not prompted, no, but when they open the settings they can choose a folder, or we can ship a config file that specifies a different folder (which is what we should probably do - and allow this folder in the AppArmor rules).

#43 Updated by sajolida 22 days ago

The change is not explained in e980bc1 nor in the changelog and before it was using "Downloads". I propose to use "Downloads" by default. In #15463, I'm also suggesting to use "Downloads" for Tor Browser.

#44 Updated by u 22 days ago

@sajolida:

The change is not explained in e980bc1 nor in the changelog and before it was using "Downloads". I propose to use "Downloads" by default. In #15463, I'm also suggesting to use "Downloads" for Tor Browser.

I fully agree with this for Tails, and we can / should add this to the OnionShare config file that we ship as well as to the AppArmor profile.

#45 Updated by u 22 days ago

  • Subject changed from Test OnionShare 2.0 in Tails to Ship OnionShare 2.0 in Tails
  • Target version changed from Tails_3.14 to Tails_4.0

Likely this will not be shipped in Tails Buster, but eventually in a later version, after 4.0. Trying to set a target version closer to reality (even if it's the wrong one right now).

Also available in: Atom PDF