OnionShare

[ha...@sigaint.org]

Does OnionShare work safely in Qubes?

Gave it a try with an AppVm based on a qubes-debian template but wasn't
able to get it working.

Haven't been able to find any posts in the qubes users or devel forums
about this. Did see some discussion on the whonix forum but that looks to
still be in the development stage.

Would it be possible using a non-qubes debian or fedora hvm?

[Unman]

You don't say why you weren't able to get it working, or what steps you
took to troubleshoot the problem.
I can confirm that it works fine on a standard Debian appVM.

From your reference to whonix, I suspect that that is your problem. I
don't use whonix so cant check this but I believe that onionshare relies
on access to a tor control port opened with Tor Browser. I think that
the whonix design would preclude this.

You can try with a normal qube connected to sys-firewall. You can't use
the normal qubes torVM because that doesn't have the control port open,
but with some minor modifications you can fix this, and then try to run
onionshare there.

I don't believe there are any "safety" issues.

unman

[haxy]

@ unman: Thanks and you are right. I should have included the steps
taken to troubleshoot.

Steps taken:

1. Using a cloned qubes-debian template created an AppVM.
2. Installed onionshare via debian apt-get.
3. Was able to open onionshare but not able to connect using sys-firewall
as the Net-VM.
4. Deleted the AppVM, created new AppVM and reinstalled via debian
apt-get. Although onionshare appeared to install properly, onionshare was
not accessable via konsole nor visible in file manager.
5. Installed in the cloned template with the same results.

unman quote: I can confirm that it works fine on a standard Debian appVM.

As I'm unsure, are you referring to an AppVM based on the included qubes
debian template?

Maybe a problem with the debian repo? Did you install via debian repo or
do a build?

[haxy]

Another thought not related to the inability to access onionshare the
second time...
Could using TBB hardened vice stable version make the connection fail?

[Unman]

I used a qube based on the standard Debian template.
Cloned with git and installed the dependencies, and the TBB.
Started the TorBrowser.
Ran the onionshare-gui script.
Tested the connection to TorBrowser from File-Settings.
Shared a file.

I'll check using the Debian package.

[Unman]

OK, well apart from the huge dependencies pulled in, everything seemed
to work.
Created qube based on standard Debian template.
Installed the onionshare package with apt-get.
Started onionshare-gui from xterm.
I had to start TBB - why? The install pulled in tor and started it.
Once TBB running and checked, I could share files.

In view of your later email I'd suggest testing with a standard TBB.
You can follow progress from the term where you started onionshare, and
you should see the connection established to the control port and then
the HS being set up.
Obviously you will need to test the TBB is working.

unman

[haxy]

@ unman: Thanks for your help! Onionshare working now.
Found that "searching" for onionshare after install would only work as root.

Also, you were right about testing with standared TBB version.
Using the hardened version results in:

"Can't connect to Tor control port on port [9051, 9151]. OnionShare
requires Tor Browser to be running in the background to work. If you don't
have it you can get it from https://www.torproject.org/."

Works with standard TBB.

[haxy]

Update.
Works as stated above but the debian repos have old 0.6 version.

Cloned the latest version, 0.9.2, with git to a new cloned TemplateVM and
installed per instructions at
"https://github.com/micahflee/onionshare/blob/master/BUILD.md#gnulinux".

Created new AppVm based on the TemplateVM with new build but Onionshare
does not function and there are no onionshare files in the AppVm.

It does however run fine in the TemplateVM.

I'm at a loss as to why the AppVM based upon the template built with git
clone doesn't work while the AppVM based upon the debian repo onionshare
installed template does.

What have I missed?

[Unman]

I would bet that you cloned in to /home/user on the template.
Once you have created a template based qube, it wont be affected
by changes made there.
You can git clone in ~ in the qube and then run onionshare from there.
You can do the same with the TBB

(Apologies if my bet is out.)

[haxy]

Makes sense but wouldn't any changes in the qube be overwritten by the
template after restart? Even if not due to installing in /home/user, I
think would be better to install in the correct template folder so an
associated AppVM would function as designed.
How did you clone in the template to make it function correctly?

[Unman]

In a template based qube /home is bind mounted from /rw/home, so it is
persistent and wont be overwritten by anu changes in the template.
Changes in other parts of the qube file system will be overwritten from
the template unless you are using the bind-dirs function.

If you want to install in a template you can do so and it will then be
available in any qube based on that template. BUT there's no need to do
this.
If you want to you can install applications in /home/user - e.g java
runtime, TBB, - this means that other qubes sharing that template wont
have the libraries or apps - its your call.

[Unman]

I should have said that /usr/local is also persistent (linked to
/rw/usrlocal), so you have bin|etc|lib there if you wish.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

BTW/FWIW, this is all documented here:

https://www.qubes-os.org/doc/templates/#important-notes

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYcxOwAAoJENtN07w5UDAwSioP/jGvPR4hVoBAG/RzeE5ZyJqs
6pQHLMTL9wf/wmnsauc2DV0VNMmPsQk9ELjb2loLu/o/3qNDLSGbAniY6HhuZhoU
d5/1myY7t9ipeqMhJ4K+mRK7LoCpjY8DR5YZR5HC071sj7oYyFhsuQJfRwMiFXoF
yBB1ZOK9sYCGf4WGZbmJg3iz558YVGxTVqNZerpZ3jU3CKmkXTMGzfcI9bAQ8ZdQ
dRDmfPdb52RLFJ8Wxxn4E4Zf0+WEPp9y1Qy7Gi4rceGyNY9SlIf/5QhPBtZTkvFK
APlYxyf6MnqneEV9fQCL2XLO7MI3/XDuucso+g2Nvbxrz1vLasGMya48qaYsttvL
bwrfMc0eSBVZV6d9UDiYdMWe0wNjuc9wdqWxKVo1tzdRTgSzFGVvFTNY9bhGb8C1
h/Kg6d9KloAI+Z/xkL5d1sOTt+IrM2QLMq8oZJbqlgkL0sBQ3XXZoROQr1ZjUhTu
E/BqBVAXyiiZPRrh7YtbCt3vZRHTdBNLjDPSlOBPhnvNJ8MqhxZTkQjm7zZUqIZ6
y2MpDjYqiXvHkEUdcEp14/6YYwSLpn+jqmgbl2sEsQWBrYCkxRvo1c01poxy4mMS
EpLq41gRtN3ilW3I0JbRRep7aNKzP1W2zD10RuS8dBpkC1QooE83IJ8YqokXDVoc
7KymzhsRKy/w8rqacGzN
=gFhx
-----END PGP SIGNATURE-----

[haxy]

> Thanks to both for your replies.
>
> I have the concept of this but how would one install the dependencies in a
> template based AppVM so they wouldn't be overwritten?
> To get this functioning I installed dependencies via apt in the template
> and cloned onionshare to the AppVM.
>
> Also, vice versa, how would I clone into the template so the AppVM would
> inherit it? CD to a new root directory before cloning?
>
> Another question I have is how to verify a git clone download,
> specifically the onionshare clone?
> Have searched but all I've been able to find are mentions of verifying
> tags and commits.
> Am unsure how to go about this.
>
>
>

[Unman]

If you install in the Template then they wont be overwritten. Change to
the root filesystem in Template based qubes aren't kept. That's what the
template is for. So you can clne in to anywhere excpet /usr/local and
/home and ot will appear in qubes.

If you git clone in to a template you can do this wherever you like. If
you put it in /home/user then it wont appear in qubes based on the
template BUT if you create a NEW qube based on that template it WILL
inherit the cloned repository.

I'm not sure what more you want other than verifying tags and
commits.Assuming you are at least somewhat famiiliar with using gpg and
have it correctly configured then 'gpg log --show-signature' will
output the commit log , and you could grep to ensure all signatures are
good. Or you could verify-commit on each commit.
If you dont know how to do this there are plenty of decent guides to
using gpg a search away.

[haxy]

Unman,
Thanks for the in depth clarification on installs in template and template
based VMs.

As far as verifying tags and commits go, I had searched for info on this
before asking here but didn't find much useful info.
I tried gpg log --show-signature but that didn't return anything.

After more searching... did come across some info that worked well.
Links:
http://kkkkkkkkkk63ava6.onion/wiki/Dev/Build_Documentation/13_full#OpenPGP_Verify_the_Source_Code

or

https://www.whonix.org/wiki/Dev/Build_Documentation/13_full#OpenPGP_Verify_the_Source_Code

An example of what worked for me in case someone else is interested.

clone desired build:
git clone https://github.com/example

go to source folder:
cd example

get signing keys if you don't already have them:
gpg --keyserver pool.sks-keyservers.net --recv-keys *************

Get list of available git tags.
git tag

Verify tag: (Replace with desired tag)
git verify-tag example

git verify-commit example^{commit}

[Valko]

I can confirm it works on whonix appvm and whonix templatevm also without any modifications.

[haxy]

> Valko quote:

> I can confirm it works on whonix appvm and whonix templatevm also without
> any modifications.

I was under the impression that it wasn't usable in whonix yet, at least
not safely.
A search in whonix forums for onionshare shows progress being made but not
ready yet.
Do you have other info?

http://kkkkkkkkkk63ava6.onion/wiki/Onionshare

"Using onionshare in Whonix will most likely be possible with the next
release, Whonix 14. By then, the documentation here will be updated."