On Mon, Jan 09, 2017 at 01:16:01AM +0000, Unman wrote: > On Mon, Jan 09, 2017 at 12:48:58AM -0000, haxy wrote: > > > On Sun, Jan 08, 2017 at 11:50:37PM -0000, haxy wrote: > > >> >> On Wed, Jan 04, 2017 at 03:02:48AM +0000, Unman wrote: > > >> >>> On Wed, Jan 04, 2017 at 12:39:39AM -0000, haxy wrote: > > >> >>> > > On Mon, Jan 02, 2017 at 11:35:22PM -0000, haxy wrote: > > >> >>> > >> 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? > > >> >>> > >> > > >> >>> > >> > > >> >>> > > > > >> >>> > > 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 > > >> >>> > > > >> >>> > @ 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? > > >> >>> > > > >> >>> > > >> >>> 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. > > >> >>> > > >> >> > > >> >> 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 > > >> >> > > >> >> > > >> >> > > >> > @ 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. > > >> > > > >> > > > >> > > >> 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? > > > > > > 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.) > > > > > > > > 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? > > > > > > 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.
I should have said that /usr/local is also persistent (linked to /rw/usrlocal), so you have bin|etc|lib there if you wish. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20170109014443.GA2539%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
