The slugs can be removed because the The first layer of HS descriptor encryption

2.5.1. First layer of encryption [HS-DESC-FIRST-LAYER] The first layer of HS descriptor encryption is designed to protect descriptor confidentiality against entities who don't know the blinded public key of the hidden service.

Here is the design document for Tor's next generation onion service. https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt

This implements many of the amazing UX suggestions thanks to @glenn-sorrentino. Here are a few screenshots of the work-in-progress:

I'm making a PR but it's not quite ready for review. Here are the known issues:

• ~~Make sure auto-stop timer still works like it's supposed to, and stops the share when the timeout expires~~
• ~~Include re-design of client-side HTML so that it looks more like the OnionShare website that @glenn-sorrentino also designed~~
• ~~While the server is starting or started, you can still interface with the file list~~
• ~~After the server is started, there's a text wrapping issue with the "Anyone with this link" and URL labels~~

Feel free to test it and comment.

Just while using OnionShare (built from the develop branch) to send a file to myself, I'm running into a weird issue. When I try sharing a 899kb jpg to myself, the server stops and the client thinks it's complete, but it only downloaded 250kb. I was able to reproduce this.

This PR introduces v3 onion support. I'm deliberately basing this on the receiver-mode-gui branch because it has so many other breaking changes that it's not worth branching off of develop branch anymore.

This PR:

1. favours v3 onions if the Tor version is new enough

2. Requires the (testing) user to pip install pysha3 if they don't have it already (I encountered an issue on Debian 9 whereby, if the version of Python is too low, the logic that uses hashlib doesn't quite work (hashlib.sha3_256) , but pysha3 does. However, there's no deb or rpm for it, so it introduces the need to pip install at least one package on those platforms (for the first time) if building/testing from source. Or, more generally, introduces that dependency. Not sure how that will fly for Debian/Ubuntu .debs....

3. Deliberately hides the 'persistent URL' and 'stealth' features in the settings dialog (since we know those don't work properly with v3 onions)

4. even if somehow persistent or stealth mode is enabled (think: previously-saved .json file, or command line flags), they are silently ignored (resulting in a non-persistent onion with no stealth)

Otherwise it contains the logic from my previous prop224 branch. Note the onionkey.py, which pre-generates private keys for both v3 and v2 now. This is necessary to interact with Stem with v3 keys, but even more significantly, it paves the way for saving that v3 private key to json once persistence is possible, and it paves the way for a 'dead man's switch' feature (reverse shutdown-timer: a start-up timer that allows the user to communicate a future onionshare URL yet to be published), which I will send a PR for later down the track.

I'm assuming it's not quite ready yet.

the v3 onion works for both share and receiver mode.

Welcome testing.

Once the persistence feature is released in Tor stable (expected in December), we can remove the logic that ignores-or-hides persistence mode. Likewise for stealth (Client Auth)

@Baccount

I think we should use a web-based localization framework such as Weblate or Transifex, so we can upload English-language locales and have people translate them into other languages, and others review their translations. We can then import the translations into OnionShare as a step in the release process.

Weblate is free software. and I know SecureDrop just set up their own server. I'd rather not run our own servers of course.

Transifex is a centralized localization platform, and Tor Project uses it to localize Tor Browser, Tails, and other similar software. I think it might be a good idea to include OnionShare in Tor Project's account because they already have a dedicated army of translators that would be excellent to use as a resource. I'm at the Tor meeting now so I'll talk to people about this while I'm here.

It's possible that once this is implemented we'll have to refactor how OnionShare does translations to use a standard format that Weblate or Transifex supports.

Intro

Flatpak is a framework for distributing desktop applications on Linux. It has been created by developers who have a long history of working on the Linux desktop, and is run as an independent open source project.

Introduction: Reasons to use Flatpak

Reason

In short, this: https://repology.org/metapackage/onionshare/versions

A good 80% of all Linux versions out there is running an older, possibly insecure version of Onionshare. As such, it would be preferable to move current deployment effort over to Flatpak. This would initially take a bit more effort, but in the long run it would ensure that all distributions always have the latest version of your application.

Version: 2.4, installed via snap OS: Ubuntu 20.04.3

Typical Behavior: OnionShare launches normally (as of previous recent version, uncertain of exactly which. Last used OnionShare successfully around 2 or 3 months ago).

Current Behavior (as of v2.4): When lauching OnionShare from GUI, process launches, hangs, then shuts down without displaying a window. When attempting to launch from CLI, the following error message is displayed:

qt.qpa.xcb: could not connect to display :0
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, webgl, xcb.

Aborted (core dumped)

Attempting to uninstall/reinstall, did not affect issue. Attempted system reboot to shake things loose, but also did not affect issue. OnionShare currently does not function.

I know of one other person who had a similar issue (which led me to try reproducing it). I was unable to find out which OS they were using at the time, but I believe it to be Windows based on screenshots. Their issue was similar to mine (unable to launch program) but the content of their error message was slightly different:

pythonw

This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem

When this is done, it will resolve #780, based on @glenn-sorrentino's work (it doesn't copy it exactly because that was difficult, but I think it gets all of the important stuff).

I think it's nearly there, but there are a few UX things to workout. I decided to tackle the window resizing problem head-on and I think it's nearly solved!

Here's what share mode looks like when you first open it:

And when you click the toggle downloads button:

Now let's hide the history and share some files.

Now I download these files in Tor Browser. (Note, stop sharing after first download is disabled.) See the history indicator?

When I click it, the indicator disappears and the count goes back down to zero.

One change I made here is that, in order to always allow the the user to toggle the history on and off, the info widget is always showing now. But in share mode, it just hides the label from it when it isn't useful.

If the share mode history is visible but receive mode history is hidden, when you flip between the two modes the window now automatically resizes to a reasonable size. In order to make this possible, OnionShareGui now has a adjust_size slot, that can get triggered by the modes emitting their adjust_size signals. This will recursively run .adjustSize() on every widget, while running self.qtapp.processEvents() at specific times, which seems to give Qt enough information to actually resize properly.

This took some figuring out, and it's still not perfect. Basically, without the processEvents() calls, the final window didn't get resized to be smaller, even though it's sizeHint said it was supposed to be smaller. But there are still a few situations where things get their size adjusted to be way too small. I actually think carefully placing a processEvents() call in the right places might fix this, but it would be helpful to be able to consistently reproduce the sizing issues, which I haven't spent time on yet.

Finally, all of the tests pass, including Tor tests. I did a little bit of refactoring of tests, too. I made it so tests_gui_tor.CommonTests inherits from tests_gui_local.CommonTests, so now we can avoid a swath of duplicated code. (However, there is still a lot of duplicated code in the tests, and I have some ideas for house to reduce that duplication, but I'm going to do that in a separate PR.) I only actually test the new history indicator in local tests right now, not in Tor tests.

@mig5 this is ready to review. I expect to have to fix a few problems before merging, but I think it's ready to have a second set of eyes on it.

Also, here's what it looks like with several downloads:

Here's a receive mode screenshot with the history indicator:

And here it is again with the history showing:

This is an initial stab at #295

When a share has been started, there is an option to 'Save private key'.

When clicked, this writes the private key to the settings json.

All subsequent shares use this key and hence the Onion URL stays the same.

If the user wishes to cancel this behavior, they can uncheck the setting in the Settings Dialog, which unsets the private_key from the json.

Subsequent shares then use a new, self-generated Onion keypair as normal.

UX: The option to uncheck the 'Save private key' only is present in the Settings Dialog if the private key is actually already saved in the json. This prevents anyone wanting to 'check' (enable) the saving of private key directly in the Settings Dialog (the only way to 'save' the private key is when the server is already running, since that's the only time we can obtain the private key from the running hidden service).

I wanted to get your feedback on this before working on the Hidservauth (which might be a bit trickier: you might want to be able to unset saved hidservauth but keep the saved private key? Not sure..)

This implements tabs, which resolves #1064!

This is a major PR that refactors a lot of stuff. There's still some more work to be done on tabs, but I'd like to merge this sooner rather than later so it's not holder up other work.

This includes reworking the design (#1073), which is being discussed in #design in the keybase team, with some great UX work thanks to @glenn-sorrentino. Also deciding if we should make Tor GUI tests work or not (#1074).

There's a lot to cover in explaining this PR, but the main different is this: Before, the main window had the option of choosing between three different modes (share, receive, website) by selecting big purple buttons at the top. Now the main window has a tabs widget. You can create new tabs, close tabs, and re-order them. And each tab is basically like the old main window: you can select a mode. But once you've selected a mode, you can't chose the mode of that tab -- you just have to use a different tab if you want a new mode.

I refactored the code so and moved most of what was in the MainWindow class into a Tab class. So we still have only one MainWindow, but we have as many Tabs as we want.

Another big change is how persistence works. When you turn on persistence in a tab (by checking "Save this tab, and automatically open it when I open OnionShare") then it saves that tab to a file in the ~/.config/onionshare/persistent dir. If you close OnionShare and then re-open it, all persistent tabs automatically open.

Now that there are tabs, and in particular persistent tabs, it doesn't make sense to have two separate OnionShare windows anymore -- you don't want them both to open full of the same persistent tabs. So now, when onionshare-gui runs it tries to detect if there's another onionshare-gui process already open, and if there is it opens a new tab in that process and then quits itself. (Process detection is done using psutil, so it introduces a new python dependency.)

The way this interprocess communication is implemented using a concept called "events". There's a folder (~/.config/onionshare/events) that OnionShare watches for changes (using watchdog, another new python dependency). Specifically, it watches the file ~/.config/onionshare/events/events for incoming events (one JSON string per line). So, when a second onionshare-gui process wants to open a tab in the first process, it does this by writing JSON to that file. (Note that testing this only works if you install OnionShare system-wide.)

Now that we know there will only ever be one onionshare-gui open at a time, this means we can rely on only one Tor process being run at a time, which means finally we can have the Tor data directory stay persistent -- in this case, ~/.config/onionshare/tor_data/. This stores the Tor cache and makes it so it's quicker and more reliable to connect to Tor, especially if you're using bridges. However, it's still possible that a user could have one GUI open but multiple onionshare CLIs going in different terminals, so the CLI version still creates its own Tor data dir in a temporary folder.

Another major refactor is the tests. I've reimplemented all of the logic from the old CLI and GUI tests, but in a way that supports tabs, and I've also written new tests that test the tab functionality itself (test_gui_tabs.py). I didn't reimplement Tor tests. The tests are much nicer now in that writing a new test involves writing a function in one of the test classes, rather than making a copy of a whole file and modifying it.

I haven't done thorough testing in Windows and Mac yet...

I took a stab at #435

It works, but I need some help with the widgets in the SettingsDialog. When choosing 'custom' bridges, the textbox doesn't expand the parent widgets, so is hard to read. (If you are able to paste in some contents and hit Save, then next time you open the SettingsDialog, it is much better because the settings were detected and so displayed by default).

Additionally it's possible to mess up the other Tor connection widgets above (control port, socket file) when they show the hidden extra options. I couldn't work out how to make them all place nicely :( but otherwise the feature should work.

I think it's the Buttons HBox that refuses to budge when child widgets in the VBoxes above it, show or hide hidden widgets....

I copied the obfs4 transports that seem to come hardcoded into Tor Browser.

Maybe you can fork what I've done and fix the widget issues if it's something trivial that I'm missing.

Hi ! I'm using OnionShare 2.5 on Windows 10. Everytime I launch the software, I have a pop-up notifying a 2.6 new version update available. But I dare not update because I have two sharing tabs opened for my running shares. As I needed to share public permanent links, I know that If a close the tabs, the shared links will be deleted. That's why I never close them.

I have 2 questions then.

1. How can I update OnionShare without losing or deleting the links of my running shares?
2. Can the editors of OnionShare add a new feature that prevent from closing the opened tabs without a confirmation question such as "Do you really want to close this tab? If you do so, you'll lose your shared link. Yes or No ?"
   

Hello, how could I add a maximum of persons in the chat ( max 2 ) or a script for everyone ( anti-scroll ) so we can spam the chat to erase the old convo in real time

the flatpak just doesn't work on mint 21? the stated reason is that it can't find markupsafe, and apparently this has happened to other people with other projects, but the solution for them (using a different version than 2.0.1) doesn't work for me the flatpak continues to insist that markupsafe doesn't exist what do i do?

akira~:$flatpak run  org.onionshare.OnionShare
Traceback (most recent call last):
  File "/app/bin/onionshare", line 33, in <module>
    sys.exit(load_entry_point('onionshare==2.6', 'console_scripts', 'onionshare')())
  File "/app/bin/onionshare", line 25, in importlib_load_entry_point
    return next(matches).load()
  File "/usr/lib/python3.9/importlib/metadata.py", line 77, in load
    module = import_module(match.group('module'))
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 664, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 627, in _load_backward_compatible
  File "<frozen zipimport>", line 259, in load_module
  File "/app/lib/python3.9/site-packages/onionshare-2.6-py3.9.egg/onionshare/__init__.py", line 34, in <module>
  File "/app/lib/python3.9/site-packages/shiboken2/files.dir/shibokensupport/__feature__.py", line 142, in _import
    return original_import(name, *args, **kwargs)
  File "<frozen zipimport>", line 259, in load_module
  File "/app/lib/python3.9/site-packages/onionshare_cli-2.6-py3.9.egg/onionshare_cli/__init__.py", line 30, in <module>
  File "/app/lib/python3.9/site-packages/shiboken2/files.dir/shibokensupport/__feature__.py", line 142, in _import
    return original_import(name, *args, **kwargs)
  File "<frozen zipimport>", line 259, in load_module
  File "/app/lib/python3.9/site-packages/onionshare_cli-2.6-py3.9.egg/onionshare_cli/web/__init__.py", line 21, in <module>
  File "/app/lib/python3.9/site-packages/shiboken2/files.dir/shibokensupport/__feature__.py", line 142, in _import
    return original_import(name, *args, **kwargs)
  File "<frozen zipimport>", line 259, in load_module
  File "/app/lib/python3.9/site-packages/onionshare_cli-2.6-py3.9.egg/onionshare_cli/web/web.py", line 28, in <module>
  File "/app/lib/python3.9/site-packages/shiboken2/files.dir/shibokensupport/__feature__.py", line 142, in _import
    return original_import(name, *args, **kwargs)
  File "/app/lib/python3.9/site-packages/flask/__init__.py", line 1, in <module>
    from markupsafe import escape
  File "/app/lib/python3.9/site-packages/shiboken2/files.dir/shibokensupport/__feature__.py", line 142, in _import
    return original_import(name, *args, **kwargs)
ModuleNotFoundError: No module named 'markupsafe'

You can probably see where I'm going here. According to the Andronix folks, using flat or snap will not work in this instance. They recommended I compile a .deb version myself, but I'm not finding a ./setup.py in the cloned directory.

End goal?

A hidden service someone can host on an android device...

I'm doing this just to see if I can.

Features

• Upgraded from PySide2 to PySide6 to make OnionShare run natively on Apple Silicon
• Passes all tests on macos-aarch64, macos-x86_64 and linux64 (with pyside-unrelated warnings)
• MacOS bundle build scripts adapted to PySide6 and working on both Intel and Apple Silicon (though I did not try codesigning via the scripts)
• The meek, obfs4proxy and snowflake scripts build universal binaries on MacOS (Tor Browser's tor is universal since v12.0)

To check/to be modified

• Universal binary builds should be disabled for hosts which cannot build the arm64 binaries (currently they are not, which will lead to errors if the build is attempted, say, by a developer working on an Intel MacOS with outdated tools)
• If the Python installation used to build OnionShare on MacOS is universal, then a universal OnionShare should result from the build process. Currently I do not have a universal installation, so I cannot check that this is indeed the case. However, I can see that all but a couple of inessential setuptools binaries and the entry binary built by cx_Freeze are not universal in the MacOS bundle (I added a script in desktop/scripts to check this). It looks like the entry binary will be universal as well if cx_Freeze is installed as a universal package, which should be the case for universal Python installations

Missing

• Package build system not tested on Linux (nor Windows)
• Nothing tested on Windows (the win build scripts still contain the PySide2 code)