[qubes-users] "No such file or directory" when restoring backup

2017-07-04 Thread Jeremy Rand
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I'm trying to restore a VM backup (created with Qubes 3.0, restoring
to Qubes 3.2), and I'm getting this error:

ERROR: [Errno 2] No such file or directory:
u'/var/tmp/restore_yoGbl2/vm11'

(I transcribed the message from dom0 by hand, hopefully I didn't make
any typos.)

Any idea what this might indicate?

Cheers,
- -- 
- -Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJZW3dBAAoJELPy0WV4bWVwFrkQAJlSoPk94j6yXdIT51+poWtt
iL3kTLX48s3n0PQOw80mBJUPy3l2wESvFhjz7/xAmXZAGLVzTcNTAPOC3RuLLxhb
WKKNuWJiIY5my38PY97RoDy+YqmU3fxu+b7XkDG7+7b51Gn7NU1dFtNlmgKpnwBi
SbFvTDucl3RagA/OyfhRKMsmy009e4ZWNWB9MtA72S4VVaP8wN7Fb2w8vwPy+d5K
LoMa7lmiK6hcXA7N7X4YEmc1V3YJCqZcXd2P7vVSLC2Os+HWkEOOp1uZUFxTVBZL
Ei2A6Js2wXAabnZxq0VkwyiOO59Rir+7dIgD+xMPnq+VmxjlwUErBxVF0VBtnPVk
IS6F3j93QrDX65PtHv78pt59xdaoYij0yY/L6yMvQKgCIFUM17w5ryYZDKXahpc/
mzViiFJv7yF/6MYWT9Z5MIZM2j7XM1iK4uqYwMXpF6wPUt8W7C5VouZIzcQua2nS
kac2lNwDsOMWrhX39Glw4axIJqiNz5K5W+DAkIzRuj/Mpcd6t/4mJuqF6JSrs5ff
suVG3j7Hi3DqPGy2weD/GofvaHejEHnGv66+Ckhh618y6H0/+u3MTcBbh3wcriqc
Wx5Jq/kjTs15FsFFFc98dyPrH2Im9MlCs6Htos8KVmsfumMyOsVEPlte+5frA/9W
6DUYN4zLcdaRlV1+Q449
=vaAC
-END PGP SIGNATURE-

-- 
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/ce61a311-7981-c898-6ae7-abc6ff270d85%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: off topic - invite codes to 'riseup'

2017-02-05 Thread Jeremy Rand
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

kamaliko...@gmail.com:
> need invite code for riseup.net email account pls help me

Aside from the fact that Riseup is probably compromised for months,
it's very bothersome seeing these spammy requests on a public mailing
list.  Please stop sending them; they have nothing to do with Qubes.
There are other email hosts that don't demand invite codes; you can
use one of them.

- -Jeremy Rand
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYl7j+AAoJELPy0WV4bWVwa5oP/2axmIdHHGjWpQv3wV7J4/6q
TP7ZTA8zt4ywcMVTCjePn0mbVi/7wNNnoYT8XA2iYxnOILEubUZHpbhgDDjD+KTH
Hc1faSv3Pmpi+rXW4ciU42s/jRL6xANOfpLfZXDzHt4kEJnxfrwUfPpVkm87sUOs
RzsaeHfOPG3HCLMrLTUMJuOkZkJKPuR/WqQ2xXwPOyFcKXiWFT6FjGp0zPUQe2nu
pl2IbDyZucMbzCehb2cvZUfLJEavvtExEATZkrLBus8/GCIwkhYupekC9c2xwUp1
HBU1hgkkeWgynrcPKoCBSMtATH4/6FPvlrRk1NaXpoHTUuaSMHnzNYRD22HQC5wG
6iMDF38e/vj8Wa7tyo7eQXFoSciXieTYo2++we4BhUJqytuXr2eLIW/STbji1Kae
okCvmOimNHZeRsRhTloazlcKNYwSZXHPYesre2BBjm76OVYSDszK0ljMooHFc1Gm
YJ2ty/WBkNpQALp2uL3pGN62gk0Mb/fw/wePiNBJ+N+lCEpUYfZ4x3DCxPD05yW1
/tYYi7ukKzCsA9fpcd6kadso2cRYOV/PweL+KHihTULxQPSAM2FeH9pagPNRMYzC
OlgJdG4sMvRXK9GFgpd7JkICQD3ndp5SuiauYpH9Bi8HWT5FRj+J0K4jH63d8JVS
DB7/gtW5io3i+glqSZDg
=Qzzs
-END PGP SIGNATURE-

-- 
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/0e73affa-1e29-5450-a5a1-b9f792986909%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Inconsistent Screen Resolution for Fedora VMs

2017-01-20 Thread Jeremy Rand
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Jeremy Rand:
> xmee...@gmail.com:
>> I just did a clean install of Qubes 3.2. For some reason the
>> resolution off apps in Fedora VMs is wildly inconsistent. The
>> borders of the windows, dom0, and the Debian VMs are correct but
>> the apps in Fedora VMs range from consistent with the others to
>> so low as to be almost unusable. I can't figure out what causes
>> them to change and xrandr outputs the same thing no matter what
>> the displayed resolution is.
> 
> I think this occurred for me a few weeks ago.  If I recall
> correctly, the HiDPI settings in GNOME had somehow been set to 0.
> No magnification is 1, double magnification is 2.  0 gets
> interpreted as 2, for reasons that only the GNOME people are likely
> to understand.  The standard GNOME procedures for changing HiDPI
> settings fixed it for me (I restored it to 1).
> 
> Sorry I don't have more details for you, I don't believe I wrote
> down the fix at the time.
> 
> -Jeremy

For future reference of anyone stumbling across this thread, you can
disable HiDPI in your Fedora VM's by running this terminal command in
each of your Fedora VM's and then rebooting those VM's:

gsettings set org.gnome.desktop.interface scaling-factor 1

Until you reboot those VM's, their GUI will have weird glitches.

Hope this helps anyone who runs into this.

- -Jeremy
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYgvO2AAoJELPy0WV4bWVwCtcQAIAGPsjKZzgKeisa67AHaYtE
kd21Ham1w6WNDQnweDmjOSPsalJfgA+vQ6jaTUJZoW6FAmgui91PDF0bTDjQYuIe
fVv4LzZNFFSbNAbnaySHdU3fZMOqV5qN1jZpYkC8tyExUfCUTzTNGdudZLIrqtYz
0bsPNAzC0zLoGZorqki52qMFR81Z4oztmAd2RMQRBUgxQF6f6YzZIUUIWCU7KLwx
ZuSL+kyw6wvVWUsEA5XesdGbguG8KzREyLr1YsZM02ARLf5aH+uWpuhWtey2ERGp
t+2ZbviKtHyeVKcrASfxaPCzYhlcIDLCS9y3v6Cp9G4CCy5RBnpa366WwXBpKn0l
flmswfXmtrfLSDlTgzi37huKOH0upMEb1CHfeVVUHm9ZfvSzySEvVu4KDJcc5rFr
RlgZ0HzPeNTtVvbpdIugj/isWwaQU6mmSLe96zmG9aeMt1vqYDqnjoNqnZaQ7/0Y
uBA+ukN91YRoG9RTMmJzfT3AVJvasyyt4giCKWRI/HmJkqrqAh1N6DcvlzNGfrZ7
2s7Rn5V1fJtQe3AsVeMVxgPqrqZ4fyXtW1poVHTp4dK9NNfngjj2tuVnNH3udwxP
xPX7GZQDve5G3M+1wzX+QtQnVYAUshxothhPVTRVciySJcNtZcpohAeFYSgI/u46
UJmSLOlXGYgMKBYnQGoX
=YBlP
-END PGP SIGNATURE-

-- 
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/cb80c92b-79cd-2923-d2cd-840ff4d1f48f%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Possible to get usable Win7 gui?

2017-01-01 Thread Jeremy Rand
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Robert Fisk:
> On 12/30/2016 01:33 AM, Jarle Thorsen wrote:
>> torsdag 29. desember 2016 13.14.25 UTC+1 skrev Grzesiek Chodzicki
>> følgende:
>>> W dniu czwartek, 29 grudnia 2016 13:07:44 UTC+1 użytkownik
>>> Jarle Thorsen napisał:
 Currently my Windows 7 StandaloneVM feels a bit sluggish.
 
 Moving windows (no phun intended) is a pain.
 
 Is it possible to have a Windows VM without any lag, or is
 this just a part of the deal with Qubes OS?
 
 What tweaks should I do to get my Windows VM as responsive as
 possible?
 
 I have no problems with lag in dom0 or any of the Linux VMs.
 
 My display is 2560x1440, maybe a large display is part of my
 problem?
>>> 
>>> VM Performance is largely dependent on the CPU and RAM so
>>> ensure that your Windows VM has enough vCPUs and RAM assigned
>>> to it.
>> 
>> Throwing more vCPUs and RAM at it hasn't made a big difference so
>> far, but I'm moving my system to a way more powerful system the
>> next couple of days, hope that will make a difference.
>> 
>> Can anybody please confirm that it is indeed possible to have a
>> lag-free Windows experience under QubesOS?
>> 
> 
> I run a Win7 VM on a i5 gen 4 ULV machine. I have always had
> problems with lag increasing over time. On bootup the VM is fast,
> but after 20 min it is unusable with each screen redraw taking ~4
> sec and associated high CPU usage. This has happened both on R3.0
> and R3.2.
> 
> I work around the issue by using Remmina (or other RDP client) in
> an appVM, and allowing IP forwarding in the firewall vm. This
> solution does not suffer from increasing lag, and should be usable
> for everything except gaming. See instructions here:
> 
> https://www.qubes-os.org/doc/firewall/
> 
> 
> Regards, Robert

I'm curious, are you using Qubes Windows Tools in that VM?  My Windows
VM's do not have Qubes Windows Tools.  (I'm trying to figure out what
might explain why you've run into this issue and I haven't.)

Cheers,
- -Jeremy
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYaWeLAAoJELPy0WV4bWVwUC8QALYQQA3bznqd2DS7HqGiBExR
PTvzBify76HRLA3IQh/W4oyNdQOFuv9Trb4P6eSeFIwo2TXakKhupV8xTeR3z00w
5L7CDfU7O61AFLPwdJyOTTVd3fR5JDajXuiDeUca8j3gdSnAJepMqwvpc7Tal/vo
YUWtZZWH6wEhH9MztB+/tZN3XUTKkZvedP7h8cjKkzkLQDNxmbmgc8YAuny16F1c
izo95kYqfQJyBfgOpbIoTldrXRAO70OUyOuNEjNPbYmd3paXZkSgyZ4yeg07YnhR
NiUNhvdyLqjwCVzyvRKEkPdMleop1SrgQxNjvOXhfULXwm+y3CHLQhFT1LYepeEc
+yHsBCfJ0bNKjcSz8mwAs0BjKrVdVtGrXRDHH4e5VNVjh5rUKYGS+Tq3mYw2Pz5d
YYd9DKtgJ4xRNkSZMEHFlcOoHD1+F1M5VYNNIEMY4LR5X/8MgDqQEEKkEDXbsNaY
lnbI0hECdqnyHW0+Roc20IpD01PLSpF2HOw4/DIslnhGrPpPTdPmQFPdwCdkvWFK
amcci0z3g6NCq9o5/PsZ4wBNTRQ6tlQ66Mjf4GgerOb8+QF+KrQf2X257xIJRiym
ZnfaPJImkug4OIYqf5rqDqVgqSVcmu7nP0e9P2aUp5n/cR9xpjZLBTYEKA8a6SFp
qKtP3xUDZ06mMMACCdSF
=RqRh
-END PGP SIGNATURE-

-- 
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/84cde2cc-3d58-703f-d076-5af8325a28b3%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Possible to get usable Win7 gui?

2017-01-01 Thread Jeremy Rand
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Jarle Thorsen:
> torsdag 29. desember 2016 13.14.25 UTC+1 skrev Grzesiek Chodzicki
> følgende:
>> W dniu czwartek, 29 grudnia 2016 13:07:44 UTC+1 użytkownik Jarle
>> Thorsen napisał:
>>> Currently my Windows 7 StandaloneVM feels a bit sluggish.
>>> 
>>> Moving windows (no phun intended) is a pain.
>>> 
>>> Is it possible to have a Windows VM without any lag, or is this
>>> just a part of the deal with Qubes OS?
>>> 
>>> What tweaks should I do to get my Windows VM as responsive as
>>> possible?
>>> 
>>> I have no problems with lag in dom0 or any of the Linux VMs.
>>> 
>>> My display is 2560x1440, maybe a large display is part of my
>>> problem?
>> 
>> VM Performance is largely dependent on the CPU and RAM so ensure
>> that your Windows VM has enough vCPUs and RAM assigned to it.
> 
> Throwing more vCPUs and RAM at it hasn't made a big difference so
> far, but I'm moving my system to a way more powerful system the
> next couple of days, hope that will make a difference.
> 
> Can anybody please confirm that it is indeed possible to have a
> lag-free Windows experience under QubesOS?

My Windows 7 and Windows 10 VM's feel reasonably responsive for
getting work done (although I definitely wouldn't want to try gaming
with that level of latency).  My dom0 resolution is larger than yours;
I haven't adjusted the default resolution in the Windows VM's.

The Windows VM's have between 2 GB and 4 GB of RAM and 2 CPU logical
cores; I'm on a Haswell i7.

Cheers,
- -Jeremy
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYaTvdAAoJELPy0WV4bWVwrwIQAKudnwSvu9iAItfV0ZAB91XK
gilr85VrXFFqMaFIAGt25JRZvqbaVhX8oijIbXdsHfp9m2c14b+IOs4/8wF+KIP8
RptE7QEd0Vz3mbrW1NwZoDnN4dSMQ9yzbdktladiHaM/QfEAkpWOCTzhzIAvdkYm
ep7IcbKasPsXVw9wBCuzfq5snKpeN09VUAcL5JpPB0zOMYN35fb/ccIHEEKwLNTG
ITWxkzbfLrgl6jTkZr7IZK1m+pOACHnlcw49/Lnv+Z/3U/q/GivrJFe+G6j1+nY5
IDdhiz2AXri4lLM91xHU1A+TiLAMxET+0dCn5jWoDpkj3NuwFfN+RykZZl03W9Ra
waX3+wHx/9BqUsGk0oKdi3f9NsRl5xMx2yruGMXRsqeSAABs74RdzkEQpX4jtccC
xvv7hBRV8cUFJBJxrnCDOKuzqPhVE09B9+zYz/FTqfrVEmQxyl+p/1rFcD2RoUQN
rEmIv9witEGmbC2K78sJgYCw32Wm27n0I5KYkRhgQ4C9+SdBun/IIWhY+cNRlI0X
SRD9VinSeKL1CbBoHH7BvueHP1djP8L7nactT4MjM2dZ4DxfxdpKLjI/e1//i1by
QnmFe8bAi00m+OuSsdDaxVkDHGhGlJ+xrffC7A5j1q/+V9SQ6U3kdgaIkO16dqgO
va3/mfdQAMQCUepZ8wVn
=xAip
-END PGP SIGNATURE-

-- 
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/fe4442bc-2ec4-c952-69ea-7ccc6cb748e4%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Is Fedora Really A Good Choice For QubeOS?

2017-01-01 Thread Jeremy Rand
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

pixel fairy:
> On Tuesday, October 1, 2013 at 6:32:41 PM UTC-7, ears...@gmail.com
> wrote:
>> We all know Fedora is a big name, but is it a good choice for a
>> Security Driven OS like QubeOS to be based around? What do others
>> here think?
> 
> There are a lot of packages creating a bigger attack surface. but,
> bigger distros like fedora have companies behind them like red hat.
> red hat has been pretty good about actively looking for
> vulnerabilities in those packages. distros that automatically
> upgrade to the latest version (gentoo etc) can also burn you. they
> would make better template vms where your more likely to want newer
> software and new issues can be better contained.
> 
> for dom0, newer distros are better at hardware compatibility with
> those fancy new processors, graphics cards and storage controllers
> in laptops.
> 
> just personal opinion, but wayland is a better fit than x11 for
> qubes in the long run. fedora is the only distro with a dedicated
> security staff actively supporting it.
> 
> anytime you abstract a layer, your diluting your resources.
> maintaining a dom0 isnt much more work than a domu template, but if
> you want to add slackware, arch, and gentoo, youve now more than
> doubled the developers distro maintanance work when they could be
> working on stability and features.

Potentially worth noting here that in Ed Snowden's keynote at
Libreplanet 2016, he criticized the free software community's tendency
to use stable, outdated software.  Snowden said that the attackers
move and adapt quickly, and it's dangerous to continue using outdated
software that doesn't have the latest security fixes/features just
because it's more stable or more backward-compatible.  Snowden did not
explicitly mention any distros that he was talking about, but I got
the distinct impression that he was (at least in part) talking about
Debian.

Of course, "appeal to authority" is a classic fallacy, so we shouldn't
do what Snowden says without questioning it, but I think it's at least
worth considering his argument seriously.

Cheers,
- -Jeremy
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYaTeQAAoJELPy0WV4bWVwbNgP+QG3jY+xlwsTnViOS+IFEHMP
Nyt+d9Cuq7iEnCsr1fuXbzjSNB8RDM0y2BY6rciELmo4kvyfsGoPYZod7nOlQPeV
xjgjubrlA3udMxSCsc5lc2DbP4IszehJECYGbZw4gaFabScs6ugt0P9gxKaiTIWR
pa9bAaSzJffZsJg9/efUJuo134Mdd8QBssKEC6idWCiEuM8YWHZI9xKfvhTjRrqj
g233nSNbvctg0yoUQbf2XHZ6gyGZ2p0Y1ab8o0o0MFVsuQIuPCKlWgr/WhjgdWDY
Ye4TCYZhonuLHRCiOt+ZuS2w8nj24O0qFvXra+asXAaW2mFzQa/Aq3CdLBE87nXE
z3dgNp2Z08dWi28ncbCwvn8mpw0w07yl1n6+2JlBC4pDTF2/r6BMgsp4DIS9sFDB
h+mFWCnqh80P/39SQeOoOcHATruMfHp8CUDVtOMVBRV4VpoA7YaKxiiiUXFnD21M
S6XP7QqxPkbPW0E77UeR53igB61QQ1t3Fb4QQRLZY1bhncKn3kM/OmUDnHzepLQn
0/FLW/aJMBofOHeb6xqrfipeayGrdHLNuav9Nu1QRuX2lY6E0Sl40VZBwRERxfaW
t+Ck3n4Qw2Gru13zXPhHuE8OpTV3/RgkMzNMnADxfArhSIW2zwoYQvNCn8U/LNaq
P2HMZA0yehx6CZnBmdb/
=RC2L
-END PGP SIGNATURE-

-- 
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/52d5d96c-c021-9673-27c5-1999e8541961%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] "Cannot find unused qid!" when restoring backup

2016-12-23 Thread Jeremy Rand
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Andrew David Wong:
> On 2016-12-13 12:56, Jeremy Rand wrote:
>> Andrew David Wong:
>>> On 2016-12-12 21:30, Jeremy Rand wrote:
>>>> I just tried to restore 5 VM's from a backup.  The backup was
>>>>  made on Qubes 3.0; I'm restoring to Qubes 3.2.  All 5 VM's 
>>>> fail to restore with this error (although of course the name
>>>> of the VM in the error message varies depending on what VM
>>>> I'm trying to restore):
> 
>>>> -> Restoring QubesAppVm iso-linux... ERROR: Cannot find
>>>> unused qid! *** Skipping VM: iso-linux
> 
>>>> The error was copied by hand since copying from dom0 to an 
>>>> AppVM is difficult, so there might be a typo.  Based on the 
>>>> error message, I infer that maybe this has something to do
>>>> with my Qubes 3.2 system having too many VM's on it already?
>>>> Is that an accurate guess, or is there a different reason for
>>>> this error? Is there any workaround?
> 
>>>> Cheers, -Jeremy
> 
> 
>>> The only other case in which I've seen this happen is when a
>>> user surpassed the maximum number of Qubes VMs (254):
> 
>>> https://groups.google.com/d/topic/qubes-users/Zw5XjZndrDo/discussion
>
>>>  Did you do the same?
> 
>> Looks like it.  I just checked and the highest final IP address 
>> octet is 253; add 1 for dom0 and it looks like I'm at the limit.
> 
>> I realize I'm probably much more gluttonous with VM's than most 
>> users, but is there by any chance any progress on increasing
>> that limit?
> 
>> Cheers, -Jeremy
> 
> 
> We can see if anyone's interested in providing a patch:
> 
> https://github.com/QubesOS/qubes-issues/issues/2519
> 
> Please understand that since this falls far outside of normal
> usage patterns and affects only a small minority of users, it's
> going to be a relatively low-priority issue. Therefore, it's
> unlikely that this will be changed soon, unless it either turns out
> to be trivial to change, or we receive a patch from the community.

Yes, totally understood -- seeing as I didn't pay anything for Qubes,
I certainly don't expect you to go out of your way to fix a minor
issue that so far has only affected 2 people.

Cheers,
- -Jeremy
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYXOUbAAoJELPy0WV4bWVwh0kP/2wiRxhYFa1V8pb5TGIV/khN
ELWZN0smAjo3JmQl7zvd/zWrANhun1X/prrEcFCvBGo7u62GuXfCioRUguXoBGZK
uk12gm8x+nsYzCMEoOfLJh6zuxNtMGz/Biq8X3f2aYKErLtm99G74ocaQO7aYN3u
zMyFw8Cfjkj5q1Zus0HejrPwVQTz5sLQjFBAZgXmH0LB+wKPOWDxs4UOxfBIcU/1
Ff5dEgdR+PVzgAdoFDns6OJXSy7r4js+gQ7kRLkuMV2R5Q9d2Rx5VwKXGLMdrhx2
vGn6BkD7kRxRHEgh4rQhjhXXWXd8/9r43Ggs+NsLx7mW4dTs2E6VwjEWaDPL/ypy
nbffOljdZNGRR48JRNKTjs8DCL04mGkq00QSF/Xllmdq2INA0Fl1KFEqsdkUQcl5
3BkRi8af9lK6Ms9K7djEqj1qzCbkJqjFMQVwDkWHsbAKnoiPkQ2+jN6izlUUtKfP
4emkY6JUk8KYArvNVf0FAPrtC32mYynWEOgV7ot5i+lGxNtiR6C2aZHPJyhicNxW
X6jA+LFdkp4X7ZEp8/79dBBoHxe5K3hB/Mdz5FSV+B+3o4o5pDxateQRjvcGLeeD
Su2PNaJ/IDfapR5NttnGQq37QZZCSGnIZH2ZbWT9su5XPwAN5gZJ/hzTm7ZRQUIl
hEY3OMxGEanhOpRuT135
=ZrQN
-END PGP SIGNATURE-

-- 
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/d0d2e441-3303-c9e1-2215-d5657daf8e1d%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Talos Secure Workstation Crowdfunding

2016-12-16 Thread Jeremy Rand
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

J. Eppler:
> Hello,
> 
> here is the correct link:

Looks like Enigmail's line breaks in combination with Google Groups
may have broken the link I provided.  Apologies (and thanks for
correcting) if that's the case.

Cheers,
- -Jeremy
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYVBJTAAoJELPy0WV4bWVwmuUP/0isdqGXH2xLPgY9q7QAwVlM
II/5Y7LdQ0HHk2r0tme/27BmThsVv7MYZIwkZg4AlxEqUTKMTSVXqvZAafqo5wl3
56Zms6ZF1LHUgjpuRo7YV0c/F+MR86jUnPY6WKkSmsqvUkeVfk8PJ2o8zJO8MyXh
Lh46nd5TJ4ZwsJiV/7YiWwIwpidlP0DfLGkFbCZ9zyUUcm+NvKUYPxHcQrHIozRd
ZEBs83iZGMy3PzxDPThujqa+BWkUAqxzuMeidsXZgY61IyDYpKiE9pAaBKkdmsrD
LNpoeyjdsE2gMZwXDU9YGZkZAICH5vB7y4Tg6K2UiVYk9AP1/nRToFJZof8E+pDy
R5xrkw2FcJH2DI8fkZ1q4Vnn7rYjRegS/7Tg1hF1z5uTxkAtI5Z9f4GCVm+B/5op
PZZRnC3Kx3whNOi6wABz70wJY/V9hQ1nvG6aXYQpRDAJ00ppjxdvS7zmwTP0pFZm
0d+OpHF9WB4ncHIVtYrqGF8+vsAaQLPIFpw9HMnzCoWYgUS1CtIqVx221Iftiimu
N7xJTbLr0nnWTmVYwxR/6JKz11gtcWJzB3VhxfwVHszUeoLd9mJnlHV8ZlX8B6l1
ybC/uGzFAdYnh+BXDEnhFH/e+jzPsPPGi5fPCBiblaZqVIwTwMGnilOeiL00mFXU
Jsqrrlbl2E8nK8aToFNH
=lyjA
-END PGP SIGNATURE-

-- 
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/c2053b75-8fb4-4837-4456-29143f8dc17f%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Talos Secure Workstation Crowdfunding

2016-12-15 Thread Jeremy Rand
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi everyone,

As those of you who've read Joanna's paper "Intel x86 Considered
Harmful" are well aware, the Intel ME and other closed-source firmware
pose a threat to trustworthy computing.  We can do all the awesome
hypervisor and isolation stuff we want (e.g. Qubes OS), but this
doesn't help when the firmware is evil (and closed-source firmware
should probably be assumed to be evil).

x86 is not likely to improve much on this front (although Trammel
Hudson's recent work is pretty cool), which means we should seriously
be looking into alternative architectures.  POWER8 is probably the
best contender for a serious alternative to x86.  As you may have
heard, Raptor Engineering is doing a crowdfund campaign on Crowd
Supply to produce the Talos Secure Workstation, a POWER8
desktop/workstation with fully libre firmware that is comparable in
performance to current Intel hardware.  In addition, most of the
mainboard logic is implemented using FPGA's with libre bitstreams and
libre toolchains instead of ASICs, which adds to the auditability and
control by the user.

Features particularly of interest to people who use Qubes include HVM,
IOMMU, and TPM, as well as some very interesting engineering relating
to preventing evil maid attacks.  Raptor has done an excellent writeup
of the latter; see the following links:

https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workst
ation/updates/talos-fpga-functions-and-responsibilities-part-1

https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workst
ation/updates/talos-fpga-functions-and-responsibilities-part-2

(People who enjoy reading Joanna's technical writeups are likely to
enjoy the above Raptor writeups too.)

And of course, as a workstation class machine, Talos supports plenty
of RAM for running lots of VM's simultaneously, as Qubes users tend to
do.

Raptor Engineering already has a solid track record of Coreboot and
Libreboot development (among other relevant areas of expertise), so
unlike most of the projects that have done crowdfunding in this space,
Raptor has an understanding of the tasks involved and is likely to
actually deliver.

Fedora and Debian already support POWER8, so the Qubes dom0 and AppVM
components shouldn't be hard to port.  Xen does not support POWER8 at
the moment, so Qubes won't run on Talos when the Talos ships.
However, there is interest in adding POWER8 support to Xen, and POWER8
support for Xen is much more likely to happen, and much faster, if
Talos meets their funding goal.

Yes, the price for a Talos is sadly quite high.  Note that it is much
more powerful than most consumer PC's (e.g. the low-end "Desktop
Edition" comes with 128 GiB of RAM), and that small production runs
are naturally more expensive.  If they meet their funding goal, it is
likely that price decreases will happen later in the product
lifecycle, as well as producing a new version based on POWER9.

If you're in a financial position to order a mainboard (or a complete
system), please support them.  For the far greater number of you who
are not (I definitely can't afford a mainboard), please consider the
$250 SSH option, and if you can't do that, please consider donating
$10.  If you have friends who understand that closed firmware is a
threat, tell them about Talos.  If you have friends who ideologically
are aligned (e.g. who support privacy rights) but who aren't aware of
the technical concerns about x86 and closed firmware, explain the
issue to them.  There are industry players watching to see how this
campaign goes and how diverse the support is; every $10 donation is a
vote that signals "We want this to happen."  $10 really does make a
difference here.

The crowdfund campaign ends in 29 days on Jan 14.

You can support them here:

https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workst
ation

Cheers,
- -Jeremy Rand
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYU3gOAAoJELPy0WV4bWVwO+IQAIr+UtgNk+29oFRjvd+UKMUF
QkWkXrn+PqWDYs63NSX4LWnyO3apo1wY/yjmBkSiKKvEnK+1v3nDOAxGxPSKyWC1
9DWhESfBzM1dagy2spGEB7YpuAM4yrp1Ih58PxT1e/mRRca14NomwzNiNiqDpw94
rZWQXxQ/igMQ8VTLivFosjB6aMKB2TyM8xFYMDg8+yefumG5wGrDKhSacM21L7MM
uLilg0eTJLkttYXNnnZOATcIsymuT3Wi84hCkGzbDWekNen2/ZJfZO5+K39tzUXo
xsK+ndi6RSU2khOJ2+/laU37aDV0iKAKRlWi0T40fmTaO/skedZSNIJ2Br7iXwGh
UyUSAnhy26oH1wYJ8Y+oAd+liJStlxCRf5TCDWo4SsojR1IYV9qoIjfFOjPmUxT6
pLNhuEKP5UdP1yDvCjF+DLr+LtCjmkP63hCz+Asj0sesO7zcO4EYQEwyATx2b60S
Uonczt9QFznxLy9wQdo8qi3beBDY3ap2dTvikvQydSMSSsh9kP3yVDhRkAxHMCn6
2u68jSUVszRQv5C15PG96bZa3cZ2oR570RJ9Yb+PfrOjRxd7z0e3+ApqIWyu68kf
hMQeJCkPpI/GKOqjnJaweu9cuoMfh0mGYGRs1tIfDuJBFFzt5A/8RA10O+aViZMO
h0OR5a2svxdfqY97t74y
=pROL
-END PGP SIGNATURE-

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

Re: [qubes-users] "Cannot find unused qid!" when restoring backup

2016-12-13 Thread Jeremy Rand
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Andrew David Wong:
> On 2016-12-12 21:30, Jeremy Rand wrote:
>> I just tried to restore 5 VM's from a backup.  The backup was
>> made on Qubes 3.0; I'm restoring to Qubes 3.2.  All 5 VM's fail
>> to restore with this error (although of course the name of the VM
>> in the error message varies depending on what VM I'm trying to
>> restore):
> 
>> -> Restoring QubesAppVm iso-linux... ERROR: Cannot find unused
>> qid! *** Skipping VM: iso-linux
> 
>> The error was copied by hand since copying from dom0 to an AppVM
>> is difficult, so there might be a typo.  Based on the error
>> message, I infer that maybe this has something to do with my
>> Qubes 3.2 system having too many VM's on it already?  Is that an
>> accurate guess, or is there a different reason for this error?
>> Is there any workaround?
> 
>> Cheers, -Jeremy
> 
> 
> The only other case in which I've seen this happen is when a user 
> surpassed the maximum number of Qubes VMs (254):
> 
> https://groups.google.com/d/topic/qubes-users/Zw5XjZndrDo/discussion
>
>  Did you do the same?

Looks like it.  I just checked and the highest final IP address octet
is 253; add 1 for dom0 and it looks like I'm at the limit.

I realize I'm probably much more gluttonous with VM's than most users,
but is there by any chance any progress on increasing that limit?

Cheers,
- -Jeremy
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYUGCOAAoJELPy0WV4bWVwehIP/2UWc57pEVmh/RzLy5y09s+L
m+3ttJ9+FMGg0Xm2jZGnNT3ufXhX3brxphC8I6hHij15z1ZuMrRQ6Ok3PFheDSD3
uLU+8pD3tX8L0TfU8PQsY5EkseiGM6fldQjgMhDzpX90+m1E7SwUCOO1JW50MbXH
WkmjXkWaztKiQrDKskv6Rp4GcVHuuOWxK/tHB2OnQDuyjI99125a+rpOPdMbI7N/
dl1Eq2Kjpq5kUkif12C/ONgija9EKycWDoNBVKbxUWnIarNwqHUynKRgaQNtapJN
UI4zkWX+oqdvYcXjn3+Hog37M7ZmTynCQMYI24G27YJP2AyTVu7ln9dOfe2aduHk
jqFRRWfZK6iC84WzzFiIsPmJ+9/lqEpFGn6BwLwn0RWGS5yvjhMVxtpw3fvUZW1g
n2stXQjSzxnWwN8cT0ojTEf0Q2J1HCbdUZApbzbbvs4+SuBNAQra1ly6fob8iCeo
l6ga5MwsviL8KmDCj2T2iZWx1Wnffe4WgKlJB8bGI2AgF31xkmsv8C79s8oPfQii
rj5tgzsh84S8LhtEuPiM6SZ8Kj/ViHuJ5KFoP4IQsaaICTg4TDfvVhp+8dTOnWka
HZm5idIrCEStC+SxVdpdBUXfw0I9zn/LKxGK9SG1tyKX6f23uV9VGMAcooZmC0/1
TfUwJnNMTiJHfSrFlpIh
=zC1M
-END PGP SIGNATURE-

-- 
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/c2832b10-231e-9121-1cc2-06c13848bbe5%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Massive performance improvement after disabling power management in the BIOS

2016-11-30 Thread Jeremy Rand
kotot...@gmail.com:
> Hello community,
> 
> I was wondering why one of my program was taking ~15 seconds to compile when 
> my colleague compiled it within ~3 seconds on his system. I know there are a 
> performance price to pay for the virtualisation but nonetheless. I was super 
> annoyed and I vaguely thinking about switching back to another distribution 
> but at the same time I was reading about DNS rebinding attacks and I really 
> wanted to stay on Qubes.
> 
> I gave a look at the BIOS settings, in the power management section. There 
> are options like "Maximize performance on AC" and also options for when the 
> laptop is on battery. I already had the "Maximize performance on AC" on. I 
> disabled the whole power management section. Performance are better! 
> 
> The program mentioned above now compiles in ~5 seconds. The whole systems 
> seems more responsive, Firefox and Youtube video (HTML5) seems also better. 
> The only drawback is that the laptop is definitively generating more heat 
> (and probably consuming more energy) but that's okay because I spend most of 
> the time connected to the AC.
> 
> Is there a bug somewhere in the kernel, in Xen or Qubes which prevent them to 
> properly use this BIOS power management system correctly?
> 
> Have other users experience something similar?
> 
> 
> When googling I found this article from VMWare with similar problems / 
> solutions
> 
> https://blogs.vmware.com/vsphere/2012/01/having-a-performance-problem-hard-to-resolve-have-you-checked-your-host-bios-lately.html

Hi, might I ask what manufacturer/model your laptop is?

-Jeremy


-- 
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/c81cf4fb-869a-5baa-ba53-5cf5d7c10118%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Future plans for KDE on Qubes?

2016-10-23 Thread Jeremy Rand
7v5w7go9ub0o:
> 
> On 10/23/2016 09:38 AM, Achim Patzner wrote:
>> Hi!
>>
>>
>> After a few months of severe suffering from xfce on a HiDPI display I
>> gave in and installed @kde-desktop-qubes on my system – and I'm pretty
>> sure I don't want to see xfce for the next few years. Title bars have a
>> usable size (something that cannot be configured in xfce without
>> building your own themes), icon aren't scaled randomly and fonts are
>> finally looking as they should. And third-party software like Softmaker
>> Office is finally working as expected. So: Will there be support for KDE
>> beyond Qubes 3.2 or will I have to plan for carrying a third machine for
>> my office work space?
> 
> +1
> 
> Never thought I'd admit it, but KDE (despite its legendary (and today
> overstated) bloat and complexity) - actually works rather well.

Good to see that I'm not the only Qubes user out there who finds KDE to
be more usable than the alternatives.  Totally agree -- I really hope
KDE continues to be supported on Qubes for those who prefer it.

Cheers,
-Jeremy

-- 
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/e77bfd4b-4ca7-c3c4-e538-49551bfc77c8%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Multiple monitors partially broken in Debian and Whonix AppVM's

2016-10-22 Thread Jeremy Rand
Jeremy Rand:
> If I install LibreOffice in a Fedora 23 Template using Qubes 3.2, the
> "Presentation Display" setting works properly with no issues, so I can
> see my notes on my main display and the presentation shows up on my
> external display.
> 
> However, this doesn't work properly under Debian 8 or Whonix 13.  It
> seems that both the notes window and the presentation window show up on
> the main display, and are forced to the resolution of the main display.
> I can drag the presentation window to the external display and maximize
> it, but its window size remains at the resolution of my main display.
> Since my main display is much higher resolution than the external
> display, the result is that the presentation appears zoomed in, with
> much of the border cut off.
> 
> Note that I'm using the jessie-backports version of LibreOffice in my
> Debian/Whonix VM's.
> 
> Any idea what might be causing this?
> 
> Cheers,
> -Jeremy Rand

Hello,

This problem is still occurring for me.  Does anyone know what might be
causing it?

Cheers,
-Jeremy


-- 
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/dc4b31c6-2718-1f07-fd23-62f993b75d1d%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Inconsistent Screen Resolution for Fedora VMs

2016-10-22 Thread Jeremy Rand
xmee...@gmail.com:
> I just did a clean install of Qubes 3.2. For some reason the resolution off 
> apps in Fedora VMs is wildly inconsistent. The borders of the windows, dom0, 
> and the Debian VMs are correct but the apps in Fedora VMs range from 
> consistent with the others to so low as to be almost unusable. I can't figure 
> out what causes them to change and xrandr outputs the same thing no matter 
> what the displayed resolution is.

I think this occurred for me a few weeks ago.  If I recall correctly,
the HiDPI settings in GNOME had somehow been set to 0.  No magnification
is 1, double magnification is 2.  0 gets interpreted as 2, for reasons
that only the GNOME people are likely to understand.  The standard GNOME
procedures for changing HiDPI settings fixed it for me (I restored it to 1).

Sorry I don't have more details for you, I don't believe I wrote down
the fix at the time.

-Jeremy

-- 
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/a60c47f9-0a8e-e671-8abf-77f034a3ae25%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Qubes 3.2 - Missing prompt: 'Edit Applications' - Problem creating Whonix Disposable vm (dvm)

2016-10-19 Thread Jeremy Rand
qer...@tutanota.com:
> 
> I am following this guide:
> 
> 
> 
> 
> https://forums.whonix.org/t/using-whonix-workstation-as-a-disposablevm-dispvm/2461
> 
> 
> 
> I have created the whonix-ws dvm template but am unable to create a usable 
> dvm like in the aforementioned guide, primarily because there is no 'edit 
> applications' prompt and I have not been able to discover the new way of 
> editing applications. Is there a way to edit applications like in 3.1 or must 
> a different process be followed to create whonix-ws dvm for tor browsing? 

Hi,

Might this be a KDE/XFCE difference?  I'm using KDE with Qubes 3.2 and
the "Edit Applications..." option is present for me.

Cheers,
-Jeremy

-- 
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/72c4ca1e-6a6f-89ca-694c-7875bdfe1e72%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] philosofy on qubes and other environment

2016-10-19 Thread Jeremy Rand
pleom...@gmail.com:
> philosofy of qubes is that you are safe when your app is isolatet.This is 
> wrong just keep app in sandboxes or jails  and what wrong can be happen? 

Thanks for the spamfest.  Looks like my null-routed email address list
finally has someone other than Drew in it.  Next time you feel tempted
to send a ridiculous number of 1-line emails to a mailing list, please
don't.  There are those of us who actually have useful things to be doing.

Cheers,
-Jeremy

-- 
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/eb16d477-fcd5-117e-d26d-24d29a0e079e%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Thoughts about installed software

2016-10-13 Thread Jeremy Rand
Rusty Bird:
> Hi Robert,
> 
>> However I would not use the "move to VM" command like this, as I 
>> experienced those requests getting lost One time files were 
>> actually deleted, since that time I always use copy instead of 
>> move.
> 
> Sounds troubling. Do you remember the last Qubes release version
> where you experienced this kind of data loss?
> 
> Rusty

In Qubes 3.0, I noticed that source files for the "move to VM" command
would be deleted even if the move failed due to insufficient disk space
in the destination VM.  (It goes without saying that this is a Very Bad
Thing.)  I'm not sure if this is still the case in newer releases of Qubes.

Cheers,
-Jeremy

-- 
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/6ba93f84-206a-303e-e608-262b10a79f97%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] ANN: Qubes network server

2016-10-12 Thread Jeremy Rand
Manuel Amador (Rudd-O):
> Folks, it gives me great pleasure to announce the product of over two
> years of work (primarily because I never paid enough attention to this
> project to bring it to completion): Qubes network server.
> 
> The traditional Qubes OS networking model contemplates a client-only use
> case. User VMs (AppVMs or StandaloneVMs) are attached to ProxyVMs, which
> give the user control over outbound connections taking place from user
> VMs. ProxyVMs in turn attach to NetVMs, which provide outbound
> connectivity for ProxyVMs and other user VMs alike.
> 
> Qubes network server changes all that.  With the Qubes network server
> software, it becomes possible to make network servers in user VMs
> available to other machines, be them peer VMs in the same Qubes OS
> system or machines connected to a physical link shared by a NetVM. You
> get actual, full, GUI control over network traffic, both exiting the VM
> and entering the VM, with exactly the same Qubes OS user experience you
> are used to.
> 
> This is all, of course, opt-in, so the standard Qubes OS network
> security model remains in effect until you decide to share network servers.
> 
> Anyway, without further ado:
> 
> https://github.com/Rudd-O/qubes-network-server
> 
> Real easy: clone, build, install, test.  I tested it with Qubes 3.1, but
> it's very likely that it'll work fine in Qubes 3.2.  I recommend you
> test this on a Qubes machine that is not your main Qubes machine, but
> the code does not do anything funky, and uninstalling the program should
> be enough to revert your system back to its original state.
> 
> I hope we can turn this add-on into a core Qubes feature.  As always,
> contributions to the project — reports, code enhancements, pull
> requests, other items — are very much welcome!

Ooh, nice!  This should be a huge benefit to usability for these use
cases -- while manual port forwarding via iptables is a thing, it's
really error-prone and time-consuming to debug.  Thanks for your work on
this.  (For anyone wondering, I haven't tested it due to lack of time at
the moment.)

Cheers,
-Jeremy

-- 
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/7ad3b276-56da-65fa-c62c-40dcb64a120a%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] HVM linux creating problem

2016-10-10 Thread Jeremy Rand
m.j.p@gmail.com:
> hello, i'm just starting with qubes and wanted to have vm with intellij 
> installed.
> 
> i've choosen hvm to have my working apps only on one vm than via template.

Why are you using an HVM for that rather than a PV StandaloneVM?  Am I
missing something?

Cheers,
-Jeremy


-- 
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/92badd62-a612-c8e7-1584-5190e4b4e14d%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] QVM Manager restart fails periodically

2016-10-04 Thread Jeremy Rand
raahe...@gmail.com:
> On Tuesday, October 4, 2016 at 12:13:38 PM UTC-4, cubit wrote:
>> 4. Oct 2016 16:04 by jerem...@airmail.cc:
>> I can confirm that I encountered this today.  It was with a VM that had
>> been running for several days.  I've encountered the same error (or one
>> similar to it) in the past when trying to shut down a VM that takes a
>> long time -- Qubes Manager asks me if I want to kill it, and if I say
>> yes, sometimes there's some apparent race condition and the error comes
>> up (I guess because the VM finished shutting down right before Qubes
>> Manager tried to kill it).
>>
>>
>>
>>
>> For mich I do not see any request to kill the AppVM and the uptime of the VM 
>> is very low. for example 50 minutes when I was testing the function to try 
>> and get it to error. 
> 
> happened to me a couple times,  when I tried to restart sys-usb and shut down 
> sys-net at the same time.  Sys-usb would fail to start ask me to kill it,  
> saying there is a possible bug in qubes manager.
> 
>  Now I just wait for sys-net to fully shutdown, wait a sec and then restart 
> sys-usb and haven't had the issue.

Yes -- like a lot of race conditions, it happens more often when the
system is under heavy load.  I see this behavior more often when
starting/stopping multiple VM's at once, or when the system is otherwise
under heavy CPU or I/O load.

Cheers,
-Jeremy

-- 
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/db9eb038-5d34-e901-5ebc-f4039a067824%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] QVM Manager restart fails periodically

2016-10-04 Thread Jeremy Rand
cubit:
> 4. Oct 2016 12:31 by a...@qubes-os.org:
> 
>> Thanks for the report. Tracking:
>>
>> https://github.com/QubesOS/qubes-issues/issues/2362
>>
> 
> 
> 
> 
> Some unscientific testing.
> 
> 
> 
> 
> Trying a restart after 15 minutes of not doing a restart and the function 
> works as expected
> 
> 
> 
> 
> Trying a restart after 50 minutes of not doing a restart and the function 
> fails the first time with the error as mentioned previously.

I can confirm that I encountered this today.  It was with a VM that had
been running for several days.  I've encountered the same error (or one
similar to it) in the past when trying to shut down a VM that takes a
long time -- Qubes Manager asks me if I want to kill it, and if I say
yes, sometimes there's some apparent race condition and the error comes
up (I guess because the VM finished shutting down right before Qubes
Manager tried to kill it).

Cheers,
-Jeremy

-- 
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/c5220077-a2ec-382a-d6b5-06d937b93bf2%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Re: I can't disable ipv6 on Debian Template

2016-10-02 Thread Jeremy Rand
nishiwak...@gmail.com:
> Uh ok, this ipv6 listening on my template set me in full paranoid mode. I 
> have found disappointing to see ipv6 wasn't disabled on Debian template, but 
> yea sorry, I went completely mad & full retard mode about Qubes on the rest.
> 
> I thought I was betrayed. I have been betrayed a lot by relatives but that 
> doesn't mean I'm supposed to react like a dumbass and think of conspiracy if 
> I got one port listening... Sadly my imagination went crazy mode. I guess you 
> can call it a defense mechanism, but nevertheless, I am sorry about that.
> 
> My boot problem is in fact related to "sudo dd if=/file.iso of=/dev/sdX" ends 
> up burning a UDF partition that refuses to boot. I tried your advices except 
> the ArchLinux one, but I guess I just have to keep trying. Also I read 
> somewhere I need to enter "bs=512" to burn more little fragments than the 
> original size to avoid boot problem with UDF. This might fix my issue, I will 
> try tomorrow.
> 
> Fun part is that I want to go back to Windows only very briefly, to install 
> my mouse drivers and fix its sensitivity being too fast, as Linux drivers are 
> really painful to install for this model (I did it on Debian, it took me a 
> lot of efforts to make it work).
> 
> Then I think I will probably join back in the future Qubes, as indeed it is a 
> very innovative OS. It's just I am interested on trying BSD systems. I found 
> a great guide to learn Korn shell scripting, watched all videos 
> https://m.youtube.com/playlist?list=PLCAFDE9B81B30388E
> It was very interesting and very well made, allows you to understand better 
> how command line work and the logics behind programs !
> 
> In fact I just want to learn to use a different Unix-based system than Linux 
> and try there what I have learnt on this great tutorial. It's easier when 
> your mouse isn't on steroids ^^

Sincere apologies for making the inference about the agenda thing.

Cheers,
-Jeremy

-- 
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/01c8c10c-fac3-63dc-a349-727aaa0d78cf%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Re: I can't disable ipv6 on Debian Template

2016-10-01 Thread Jeremy Rand
nishiwak...@gmail.com:
> I won't wait another week with my HDD disabled by this OS.

I'm trying to figure out if this is a veiled threat of some kind...?

FWIW, I've booted from USB drives while Qubes was installed internally
before.  I'm under the impression that lots of people here have done so.
 So perhaps you might want to consider the likely possibility that there
is something different about your setup compared to mine (and everyone
else's whose setup works fine), rather than this being a deliberate
attempt by Qubes developers to "make [sic] hostages".

Then again, based on your other posts in this thread, it's likely that
I'm wasting time trying to reason with someone who has an entirely
different agenda than getting an actual bug fixed.  I won't be bothering
to engage further if additional posts support that conclusion.

Cheers,
-Jeremy

-- 
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/3a46a661-d4bf-ea8b-5ff1-ba4f65520be3%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] sys-firewall no longer works after creating new Net VM

2016-09-30 Thread Jeremy Rand
neilhard...@gmail.com:
> I created a new Net VM, in order to use Debian, and it works fine.
> 
> But now I want to revert back to sys-net.
> 
> The problem is that my sys-firewall no longer works.
> 
> How do I get sys-firewall to work again?
> 
> It starts up fine, but simply doesn't work. Other App VMs are not getting 
> data through it.
> 
> Thanks.

Been a while since I did this, but I believe that if you create a new VM
and specify "ProxyVM" as the type instead of "AppVM" or "NetVM", you'll
wind up with a VM that has similar (or identical?) configuration as
sys-firewall.

Cheers,
-Jeremy

-- 
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/7df5acf9-3db3-ca97-d0c8-d6357eed6873%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Re: Qubes Windows Tools

2016-09-29 Thread Jeremy Rand
entr0py:
> 
> You're too modest. You make people's heads explode with your mastery of 
> complex subjects - for fun!

Well, my head did kind of explode from reading those highly entertaining
highlights, but I think your explanation only is valid if "mastery" is a
signed variable.

> Just including some highlights so Jeremy doesn't feel like he's missing out.

Much appreciated.  I've spent much of the past week doing boring things
that I'd rather not be doing, so it's certainly good to get some comic
relief.

> And a rhetorical question: What happens if /dev/null overflows?

I raise you another rhetorical question: How many clones of Drew would
have to bang on a typewriter, and for how long, to cause that behavior
to reliably occur?

Cheers,
-Jeremy

-- 
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/a6745433-c233-0974-9244-5cbea531208b%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Available memory

2016-09-28 Thread Jeremy Rand
York Keyser:
> Hi group,
> 
> I have a short, maybe stupid question, where or how can I see the
> available memory. Not the memory of each VM I need to know how much
> memory is availably global wide. (Short-term and Long-term memory)
> 
> Regards York

Last I heard, there isn't an easy way to see the total available RAM in
all VM's.  Maybe some progress happened there and I haven't heard?  It
would certainly be a useful feature.

Cheers,
-Jeremy

-- 
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/8f7dd740-bdba-3337-f464-f2f507f34e48%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Re: Qubes Windows Tools

2016-09-28 Thread Jeremy Rand
Achim Patzner:
> Am 28.09.2016 um 10:06 schrieb Drew White:
>> On Wednesday, 28 September 2016 17:47:01 UTC+10, Foppe de Haan  wrote:
>>> On Wednesday, September 28, 2016 at 8:20:29 AM UTC+2, Drew White wrote:
 Why does QWT require TESTSIGNING to be turned on?
 Is that because Win7 requires things to be signed?
>>> https://www.qubes-os.org/doc/windows-appvms/
>>> "Before proceeding with the installation we need to disable Windows 
>>> mechanism that allows only signed drivers to be installed, because 
>>> currently (beta releases) the drivers we provide as part of the Windows 
>>> Tools are not digitally signed with a publicly recognizable certificate."
>> Still doesn't answer that question either.
>>
>> I said "hi devs" because I needed someone with the knowledge of WHY, not 
>> just an end user reason, but a dev description that is technical.
> 
> Which part of "we don't provide signed drivers so if you want to run
> them you have to turn that requirement off" needs a developer to make
> you understand it and what kind of LART do you expect said developer to
> use for beating some sense into you? It's clear, it's precise and unless
> you need a translation into another language there is not much anyone
> could do for you. Please keep the developers doing something more
> important than correcting your refusal to accept facts.
> 
> 
> Achim
> 

It occurs to me that although I've re-routed messages from Drew to
/dev/null for quite a while (thus saving me from reading that drivel), I
didn't do so for messages that reply to him.  I think I'm actually okay
with that oversight, as now I get to enjoy reading 3 different people
explaining to him why his messages are the type of message that resulted
in me null-routing him, but I don't have to subject myself to reading
whatever replies he comes up with.

(On that note -- kudos to the 3 of you who managed to reply to him,
explaining in reasonable detail why he's off base, without losing your
sanity.  Quite impressive.)

Cheers,
-Jeremy

-- 
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/f180040c-2a30-c5be-6f84-6b6f056c2abf%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] "Carrying forward" a DMA attack..?

2016-09-27 Thread Jeremy Rand
raahe...@gmail.com:
> On Tuesday, September 27, 2016 at 5:11:27 PM UTC-4, Jeremy Rand wrote:
>> raahe...@gmail.com:
>>> or just only allow https in the vm firewall settings.
>>
>> I assume you mean whitelisting TCP port 443?  If so, be aware that while
>> this will stop most non-HTTPS traffic, there is nothing that prevents
>> other protocols from using port 443.  It's a fairly well-known attack on
>> Tor's "stream isolation by port" feature for websites to use nonstandard
>> ports in order to get isolated in the wrong Tor circuit (e.g. in order
>> to deanonymize SSH traffic), which is why Tor doesn't stream-isolate by
>> port by default.
>>
>> Whitelisting TCP port 443 is still better than nothing, though, assuming
>> that you don't expect any legitimate traffic to go over other ports.
>> Just be aware that it's trivially easy to bypass for an attacker.
>>
>> Assuming that you're using a Firefox-based browser (including Tor
>> Browser), you can get some defense in depth by also enabling the feature
>> of HTTPS-Everywhere that blocks all non-TLS requests.  Nothing wrong
>> with combining this with the firewall whitelist that you suggested.
>>
>> Cheers,
>> -Jeremy
> 
> oh I see now there is the feature in the plugin ive never used lol.  I still 
> think its unescessary if you already blocking that traffic with the firewall, 
> especially if that plugin or browser is compromised,  especially with latest 
> news about firefox plugins.  For example noscript itself is considered a 
> vulnerability on firefox now. 


As I said, it gets you defense in depth because the two mechanisms
prevent different (though overlapping) attacks.

HTTPS Everywhere's feature for blocking non-TLS requests will block
non-TLS requests from Firefox that use port 443, while the FirewallVM
won't be able to stop this.  For example, a request to
http://www.nsa.gov:443/ will be stopped by HTTPS Everywhere, since it
knows the protocol being used as opposed to just the TCP port.

The FirewallVM, on the other hand, will block TCP connections on ports
other than 443 even if Firefox in the AppVM is compromised.  E.g. you
visit https://www.nsa.gov/ , they deploy a Firefox zero-day, and are
thus able to bypass HTTPS Everywhere.

Both of these attacks have a lot of overlap (e.g. a simple request to
http://www.nsa.gov/ will be blocked by both).  But each defense does
prevent some types of attack that the other doesn't, so it makes sense
IMO to use both.  Definitely won't hurt you, and it might help depending
on what attacks get aimed at you.

(Of course, either of those defenses alone is likely to prevent the vast
majority of real-world attacks, but I'd still suggest doing both.
Justified paranoia is why we're all here, right?  :) )

Cheers,
-Jeremy

-- 
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/6560bf5f-8710-40e8-0a14-be32c57adae3%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Re: I can't disable ipv6 on Debian Template

2016-09-27 Thread Jeremy Rand
johnyju...@sigaint.org:
>> The "listening" services are less of a concern, since the firewall
>> wouldn't permit any incoming connections to be passed through to start
>> with.  It's the "phone home" style services, like time sync, Samba name
>> lookups on microsoft servers, and such, that are more concerning, and
>> privacy-busting.
> 
> The paranoid part of me (which is about 95% of me) half-suspects that NTP
> is actively monitored by the powers that be, to keep tabs on us
> security-minded Linux geeks.
> 
> There's been enough major security bugs in NTP, that one must wonder if
> they're akin to the heartbleed/rng/SSL/etc. compromises that don't
> necessarily look like innocent mistakes.
> 
> Qubes is good at trying to get dom0 to push the time to the VM's by its
> own means.  And if you set the ClockVM to sys-whonix, say, you remove, or
> at least greatly reduce, the ability of TPTB to track your setting your
> clock.  :)
> 
> However, as mentioned, the default of using NTP time syncing is enabled by
> default in the Debian-8 template, which defeats that protection for Debian
> Appvms, unless you disable it in the template.  Just an oversight, I'm
> sure.  (No sarcasm, for once.)
> 
> My PC's RT clock might drift by a few seconds each week, if that; I'm not
> sure why time synchronization has to be so damn frequent and aggressive. 
> A red flag for the paranoid.  :)
> 
> I have a RS232 GPS dongle that spits out the time with 1-second accuracy
> (or atomic-clock level accuracy, if you use the 1-second clock-tick signal
> available on one of the chips, which I have done, lol).
> 
> I plan on hooking that up to my Qubes setup in the near future, and
> disabling network-based clock sync all together.
> 
> (Until Qubes 4.0 comes out, forces me to upgrade to a newer motherboard
> with no RS232 support. :) )
> 
> Might be a good open-sourced hardware project.  I think I've seen some out
> there already, although not necessarily integrated smoothly into Qubes.
> 
> Just one more hole to make sure we plug.
> 
> JJ

You might find Jake Appelbaum's tlsdate interesting, or Adam Langley's
Roughtime.  Both are quite a bit more secure than NTP, although tlsdate
doesn't work with TLS 1.3, and Roughtime is still a proof of concept.

Cheers,
-Jeremy

-- 
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/6179d0f8-9f5b-5180-70dc-b60aec8c0aae%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] "Carrying forward" a DMA attack..?

2016-09-27 Thread Jeremy Rand
raahe...@gmail.com:
> or just only allow https in the vm firewall settings.

I assume you mean whitelisting TCP port 443?  If so, be aware that while
this will stop most non-HTTPS traffic, there is nothing that prevents
other protocols from using port 443.  It's a fairly well-known attack on
Tor's "stream isolation by port" feature for websites to use nonstandard
ports in order to get isolated in the wrong Tor circuit (e.g. in order
to deanonymize SSH traffic), which is why Tor doesn't stream-isolate by
port by default.

Whitelisting TCP port 443 is still better than nothing, though, assuming
that you don't expect any legitimate traffic to go over other ports.
Just be aware that it's trivially easy to bypass for an attacker.

Assuming that you're using a Firefox-based browser (including Tor
Browser), you can get some defense in depth by also enabling the feature
of HTTPS-Everywhere that blocks all non-TLS requests.  Nothing wrong
with combining this with the firewall whitelist that you suggested.

Cheers,
-Jeremy

-- 
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/8d47d4b9-7ed4-84f4-e697-13db24877024%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] backup

2016-09-27 Thread Jeremy Rand
'Gabriel' via qubes-users:
> Hi fellows,
> 
> I started using qubes a while ago and I have a question concerning backups.
> What I want is a complete backup to a dedicated external USB HDD. I 
> understand to achieve this all the VMs must be shut down.
> Therefore when I plugged in the HDD I mounted it in dom0 under /mnt.

You can backup a subset of VM's from the GUI.  I typically backup every
VM except the USB VM (with the external HDD attached to the USB VM and
mounted in a DispVM), under the assumption that if I'm ever restoring to
a fresh Qubes install, there will already be a USB VM there, so backing
up the USB VM isn't really needed.

Cheers,
-Jeremy

-- 
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/58032d10-22a7-7c1b-8ee1-bd95c4ba563a%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Does anyone use a dedicated Tor router box..?

2016-09-09 Thread Jeremy Rand
neilhard...@gmail.com:
> Does anyone use a dedicated Tor router..?
> 
> The theory is, Tor is secure, but Firefox is not.
> 
> Therefore, you have 1 computer that runs Tor only, and a WiFi hotspot... 
> Another computer runs Firefox and any other programs.
> 
> So long as the other computer connects to the Tor computer for network 
> access, it doesn't matter if it gets hacked, because your real IP address 
> never leaks.
> 
> Qubes implements this somewhat by separating the Whonix Net VM and App VM. 
> 
> However, the problem with Qubes, of course, is all the Xen exploits which 
> make it insecure.
> 
> If you were hacked in Qubes, the hacker could easily then leak out your real 
> IP address.
> 
> But if you were hacked behind a physical Tor box, your real IP can never 
> leak, unless the Tor box itself can be compromised... And as far as we know, 
> there are no exploits for the Tor network itself, only for Firefox.
> 
> I would use Qubes for the Tor box and the other box, if only for the VT-D 
> protection, although maybe there are other free Linux OSs that have VT-D 
> protection.
> 
> What do you think...? Has anyone tried doing this..? How did it work out...?

I'm pretty sure that I recall the Whonix people doing some experiments
with running the Workstation and Gateway on 2 physical machines instead
of 2 VM's.  I've never tried those instructions, and I don't know if
that setup is still maintained, but yes, it has been thought of.

Also, I think SecureDrop uses 4 physical machines, 1 of which runs Tor
and another of which runs the hidden service, a 3rd of which is offline
completely (I can't remember the purpose of the 4th offhand).  So it's
fairly similar to a Qubes setup in many ways.

Cheers,
-Jeremy Rand

-- 
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/bc34773a-c275-b87d-f550-ba2bfd9ed539%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Salt InterVM Configuration explorations and pitfalls in 3.2-rc2

2016-08-30 Thread Jeremy Rand
nekroze.law...@gmail.com:
> On Tuesday, August 30, 2016 at 12:57:54 PM UTC+10, Jeremy Rand wrote:
>> Seems to me that an attack could be constructed where the Tor exit used
>> for update downloads feeds sys-whonix an exploit, and from there is able
>> to either break out of Tor, or compromise Tor in some way that may
>> affect other VM's' anonymity.
> 
> Forgive me if I am misunderstanding the scenario you proposed, but the setup 
> in question "sys-net>sys-firewall>sys-whonix>sys-update" If dom0 uses 
> sys-update to pull updates we should be ok. The default for when qubes is 
> told to use whonix/tor for updates however is 
> "sys-net>sys-firewall>sys-whonix" with sys-whonix being the update VM if I 
> remember correctly. In that case dnf/yum is in fact running in a whonix VM 
> (which as you mention might be a security issue) and the previously discussed 
> method should prevent that, however as Marek mentioned it is not the default 
> because it would require the addition of another appVM and the base setup 
> should be as minimal as possible. Not everyone has 16+gb of ram.

Yes, you understand the scenario I suggested correctly.  I agree with
you and Marek that, for users with less RAM, it may be an acceptable
tradeoff to run the update in sys-whonix.  However, there are some users
who either have a lot of RAM or are willing to shut down other VM's
while performing dom0 updates in order to gain some extra security, and
I think it would be reasonable for those users to use a "sys-update" VM
for dom0 updates.  I also think that this is something that might make
sense to ask the user on Qubes install, and automatically configure
"sys-update" if the user opts for the extra security.

The attack surface probably isn't massive here.  But I always like
reducing attack surface when feasible, and using a "sys-update" VM seems
like a decent way to do so.

If Marek (or perhaps Patrick) disagree with me that there's a security
vs RAM usage tradeoff, I'd be very interested to hear their analysis on
this.

Cheers,
-Jeremy Rand

-- 
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/ce619a10-ecc2-3b31-85f2-f0d28afdcbb1%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Salt InterVM Configuration explorations and pitfalls in 3.2-rc2

2016-08-29 Thread Jeremy Rand
Marek Marczykowski-Górecki:
> On Wed, Aug 17, 2016 at 01:42:36AM -0700, nekroze.law...@gmail.com wrote:
> 
>>> In any case, if you put Fedora-based VM behind sys-whonix, and set it as 
>>> UpdateVM, it should work. 
> 
>> That does indeed seem to fix the problem. Is there a reason why the whonix 
>> setup choice that uses whonix for dom0 updates not also build an update vm 
>> that uses sys-whonix and is based off of fedora?
> 
> Basic actions (install updates, new packages) should work in this setup
> and it save some RAM (no need for additional VM in addition to
> sys-whonix).

Seems to me that an attack could be constructed where the Tor exit used
for update downloads feeds sys-whonix an exploit, and from there is able
to either break out of Tor, or compromise Tor in some way that may
affect other VM's' anonymity.

Granted, this is a fairly lousy attack as attacks go, but isn't the
entire point of Whonix that nothing is supposed to run inside the Whonix
gateway except Tor?

Cheers,
-Jeremy Rand

-- 
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/6d9feec4-a205-dc21-9158-bad70538f8ee%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


[qubes-users] Multiple monitors partially broken in Debian and Whonix AppVM's

2016-08-27 Thread Jeremy Rand
If I install LibreOffice in a Fedora 23 Template using Qubes 3.2, the
"Presentation Display" setting works properly with no issues, so I can
see my notes on my main display and the presentation shows up on my
external display.

However, this doesn't work properly under Debian 8 or Whonix 13.  It
seems that both the notes window and the presentation window show up on
the main display, and are forced to the resolution of the main display.
I can drag the presentation window to the external display and maximize
it, but its window size remains at the resolution of my main display.
Since my main display is much higher resolution than the external
display, the result is that the presentation appears zoomed in, with
much of the border cut off.

Note that I'm using the jessie-backports version of LibreOffice in my
Debian/Whonix VM's.

Any idea what might be causing this?

Cheers,
-Jeremy Rand

-- 
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/50eefa6e-6b57-deea-2c5f-1d6f570da464%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Qubes VM compromised? - Follow up

2016-08-26 Thread Jeremy Rand
johnyju...@sigaint.org:
> 
>> I just use Whonix within Qubes and I like it. I'm glad it comes out of
>> the box since 3.1
> 
> I've retreated to only using Fedora.  Setting up Tor and Firefox (with
> noscript, ssl observatory, adblocker) to use it as a proxy is essentially
> the same effect as Whonix (or tbb).  Even if tor/firefox are on the same
> vm rather than separated, you're behind sys-net and sys-firewall, so your
> real world address isn't going to leak.  Another two VM's on top of that
> (whonix-gw and whonix-ws) is a bit of overkill IMO, and a memory pig.

Running Tor in the same VM as the browser won't keep your public IP from
leaking to the same extent as using Whonix.  For example, if Firefox
gets pwned, it can simply generate a request to whatismyip.com without
going through Tor, and then send the result to whoever it likes.

(Unless I'm misunderstanding what you're doing.)

Cheers,
-Jeremy Rand

-- 
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/204c1635-520a-e9c4-aa87-edc40e59b59f%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Unnecessary things in dom0/templates?

2016-08-26 Thread Jeremy Rand
arthur.summ...@gmail.com:
> I just updated dom0 and saw a few packages - avahi and openssl - that made me 
> curious as to why they are there. I'm all about having a lean system, so I 
> remove things where and when I can. If there's a reason for these things 
> being there, then that's cool, but since dom0 is network-isolated, that 
> struck me as a little odd.
> 
> I'm also curious to know if other people have thoughts on certain packages 
> and why they're included (in dom0 or in templates), so feel free to list them 
> on this thread.

OpenSSL is used for lots of things that aren't network-related.  I'm
under the impression that OpenSSL is used for the Qubes backup/restore
system.  A Qubes devloper would be able to answer with more certainty.

-Jeremy Rand


-- 
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/9cbde4a0-027d-7f5b-c6eb-6ca87e744369%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Re: Fedora 23 template not updating - with a blank screen

2016-08-22 Thread Jeremy Rand
48juya+35xih7kuzgagg via qubes-users:
> It seems that doing a 'dnf update --refresh' it provides some output but 
> updating the repositories is taking forever:
> 
> [root@fedora-23 ~]# dnf update --refresh
> RPM Fusion for Fedora 23 - Nonfree
>  1.1 MB/s | 
> 156 kB 00:00
> RPM Fusion for Fedora 23 - Free   
>  3.8 kB/s | 
> 457 kB 02:00
> Qubes OS Repository for VM (updates)  
>  1.0 MB/s | 
> 286 kB 00:00
> Fedora 23 - x86_64 - Updates  
>  199 kB/s |  
> 24 MB 02:03
> 
> 
> Its hanging for more than 15m now, any ideas how to solve this?

Coincdentally, this occurred to me about 20 minutes ago.  Restarting the
fedora-23 TemplateVM and trying to update again fixed it for me.  Might
have been a server issue on Fedora's end.

-Jeremy Rand

-- 
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/e39a5b17-d83a-977e-a760-2125c24d2d3b%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] USB Root Drive Corruption

2016-08-19 Thread Jeremy Rand
johnyju...@sigaint.org:
>> This problem persists in 3.2rc2.
>>
>> (And I get 0 errors on the same USB drive under Tails.  When I can find
>> the SATA power connector around here somewhere, I'll try moving the drive
>> direct onto the SATA bus.)
> 
> I think the problem *may* be that systemd has a default 90 second timeout
> on jobs, including unmounting root.
> 
> On an external USB drive, due to slower transfer times, the shutdown
> process of all the VM's, killing processes, flushing buffers, etc.,
> happens to take long enough that a clean unmount of the drive doesn't get
> a chance to occur, leaned to a corrupted filesystem.
> 
> If I shut down each Appvm manually before finally doing the reboot, the
> work left to do on shutdown lets the unmount occur with in 90 seconds, so
> the drive shuts down cleanly.
> 
> I think that's what I've been seeing, anyway.  There's a lot of disk
> activity while systemd talks about outstanding jobs, and while the time
> remaining of waiting for the jobs, ticks down to zero.
> 
> Now, why the fsck on boot fails (and things fall into r/o mode, and fail
> thus hang the boot sequence), I'm not sure.  It could be a similar
> problem, that startup jobs aren't happening within the 90 second default
> job window for systemd (due to slower USB transfers, and the time taken
> for the fsck), and the boot process gives up.
> 
> People with internal drives and killer machines wouldn't see this issue.
> 
> I'm going to try cranking up DefaultTimeoutStartSec and
> DefaultTimeoutStopSec in /etc/systemd/system.conf, and see if that
> improves the situation.  I'll also scrutinize systemd-analyze (which I
> just learned about, being an old-school /etc/init.d guy, lol) and see if
> that confirms my suspicions.
> 
> Cheers,
> 
> JJ

This might explain why I didn't see this behavior, because the external
USB drive that I booted 3.2rc1 from was a USB3 drive that internally
used RAID0, so it's probably faster than most.  Might I ask whether your
external USB drive was USB2 or USB3, whether it was an HDD or SSD, and
whether it used RAID0?

Cheers,
-Jeremy Rand

-- 
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/168f1392-c917-c2f7-ce6f-70236a734eab%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] USB Root Drive Corruption

2016-08-17 Thread Jeremy Rand
johnyju...@sigaint.org:
> Well, my wild enthusiasm with Qubes has turned into complete frustration
> and exasperation this morning.
> 
> The "mild" corruption I was seeing on boot (running Qubes from a USB 2.5"
> HD) wasn't quite so mild the last time I booted.
> 
> This time, rather than "recovering journal... done," the fsck spewed more
> than I've ever seen an fsck spew, and the filesystem was trashed.  /var
> ended up as a symlink to liblber-2.4.so.2.10.2.  I found /var/lib/qubes in
> lost+found (along with 350 other directories).  Argh!
> 
> I'd highly recommend that nobody run Qubes 3.1 from an external USB drive.
> 
> I'm going back to another OS as my daily system.
> 
> I'll probably give Qubes 3.2rc a try on an internal hard drive, as a
> secondary OS, to see if that solves my HD and video corruption issues.  If
> not, I'll probably wait for Qubes to mature a bit more before using it in
> any serious manner.

I've run Qubes 3.0rc1 and Qubes 3.2rc1 from an external USD hard drive
(for about a month each).  3.0rc1 encountered kernel panics about once
per day (which wasn't the case when run from an internal drive) and
booted much slower than from an internal drive, but I didn't notice any
obvious drive corruption from it.  3.2rc1 had no issues whatsoever and
wasn't much slower than internal.  I haven't tried any release of 3.1.

So, my guess is that the issue you're encountering either was fixed
between 3.1 and 3.2rc1 (and didn't seem to exist in 3.0rc1), or is in
some way unique to your setup.  Maybe a hardware issue?

Cheers,
-Jeremy Rand

-- 
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/df5ff24c-c6ce-8dda-dfac-5f07bea4f9c0%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Question about Whonix / Tor Browser / exploits

2016-08-02 Thread Jeremy Rand
neilhard...@gmail.com:
> I have a question about Whonix/Tor Browser exploits.
> 
> I have played around a bit with Metasploit to see how browser exploits work.
> 
> They basically rig a web page with exploits, and then it does what's known as 
> "arbitrary code execution", to open up a "remote shell".
> 
> As far as I can tell.. the remote shell is running in the browser's RAM. They 
> are essentially hi-jacking the browser's RAM, and using it to run their own 
> remote shell.
> 
> The hacker then usually loads a file from the remote shell, onto the 
> computer's hard drive, in order to obtain persistence... As soon as the 
> browser tab closes, the remote shell is gone, hence why they need persistence.
> 
> So my question is about persistence.
> 
> Is it possible to simply remove the hard drive altogether from Whonix, to 
> prevent them achieving persistence...?
> 
> I know that TAILS simply doesn't have a hard drive at all.
> 
> Would this be useful to have in Whonix..? To remove the hard drive 
> altogether, perhaps in VM Settings in QUBES...?
> 
> Or is it possible to run a Xen exploit purely in the browser's RAM anyway...? 
> Thus, they don't even need a hard drive because they can just run the exploit 
> in RAM anyway...?
> 
> So the main question is really whether they can run the Xen exploit in RAM 
> anyway or not If not, then surely removing the hard drive itself 
> would be useful...?
> 
> Hopefully you understand my question.

It's possible to use Whonix as a DisposableVM (although it's not the
default configuration of a fresh Qubes installation), so in theory any
exploit placed in the VM will disappear when the VM is closed.  This
would, presumably, mitigate persistent malware placed via Firefox
exploits, but won't help against malware that combines a Firefox exploit
with a Xen exploit.  It still seems like an improvement against the
default configuration.

Cheers,
-Jeremy Rand

-- 
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/49652994-14ed-c71c-3f0a-9c595d304940%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] MicroSD assigned to dom0 and not to sys-usb

2016-08-02 Thread Jeremy Rand
Marek Marczykowski-Górecki:
> On Mon, Aug 01, 2016 at 07:35:26PM +, 468ezc+5r0fnwy87qeag via 
> qubes-users wrote:
>> Hi,
> 
>> My MicroSD while attached is assigned to dom0 and not sys-usb as is 
>> supposed. Notwithstanding, USB devices are still assigned to sys-usb.
> 
>> Is this the intended behavior? Doesn't this increases, in the same manner as 
>> usb devices does, the surface attack in dom0?
> 
> Your (micro)SD card reader is probably not a USB device, but PCI device.
> Yes, it's better to assign it to some VM - sys-usb is ok. You can do
> this in VM settings - "Devices" tab.

Seems to me that assigning the SD controller to a different VM than
sys-usb would eliminate some attack vectors, since if they're assigned
to the same VM, IOMMU won't prevent software accessing the SD card from
attacking software accessing the USB devices (and vice versa).  A
doomsday scenario that comes to mind is when the USB controller is being
used to connect to the Internet via a phone tether, and the SD card is
storing some high-value data.  (My doomsday imagination is limited;
perhaps there are better doomsday scenarios.)

Is my intuition on this corect?

Of course, using a separate VM means increased RAM usage, which may or
may not be worth it.

Cheers,
-Jeremy Rand

-- 
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/33219161-b369-6ddc-b4b2-f9e75310881d%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Re: [qubes-devel] Window border colors

2016-07-27 Thread Jeremy Rand
Marek Marczykowski-Górecki:
> On Wed, Jul 27, 2016 at 09:53:00AM +0000, Jeremy Rand wrote:
>> 45in10+d44wd6z0yzqcg via qubes-users:
>>> The proposed workaround solved part of the issue, however I'm still facing 
>>> issues with application windows that are not displayed as outlined on my 
>>> previous comment:
>>>
>>> Since this update every time a command is launched, when the respective 
>>> AppVM is down, the window is not displayed and the AppVm shows as being in 
>>> a transient state (for instance, when launching the gnome-terminal, the 
>>> terminal console only gets displayed after another instance of 
>>> gnome-terminal is launched, then two terminal console windows are displayed)
> 
>> I think this is an independent issue.  It's been happening to me
>> intermittently for at least a week prior to the update that broke the
>> window border colors.  In fact, I think it's been happening to me
>> intermittently since I started using 3.2rc1.
> 
> I think this is another instance of this:
> https://github.com/QubesOS/qubes-issues/issues/2085
> 
> When it happen, check /var/log/qubes/guid.VMNAME.log.old for something
> like:
>  XDestroyWindow 0x5e5
> ErrorHandler: BadWindow (invalid Window parameter)
>  Major opcode: 10 (X_UnmapWindow)
>  ResourceID:   0x5e5
>  Failed serial number:  194
>  Current serial number: 197
> 
> 

Hi Marek,

I was able to reproduce this today.  The requested log file is pasted below:

Icon size: 128x128
invalid PMinSize for 0x724 (0/0)
invalid PMaxSize for 0x724 (0/0)
invalid PResizeInc for 0x724 (0/0)
invalid PBaseSize for 0x724 (0/0)
invalid PMinSize for 0x725 (0/0)
invalid PMaxSize for 0x725 (0/0)
invalid PResizeInc for 0x725 (0/0)
invalid PBaseSize for 0x725 (0/0)
invalid PMaxSize for 0x725 (0/0)
invalid PResizeInc for 0x725 (0/0)
ErrorHandler: BadWindow (invalid Window parameter)
 Major opcode: 4 (X_DestroyWindow)
 ResourceID:   0x725
 Failed serial number:  144
 Current serial number: 146

The affected AppVM in this case is a Whonix WS AppVM; the window being
opened was Konsole.  This is on Qubes 3.2rc1 with KDE.

Hope this helps in diagnosing it.

Cheers,
-Jeremy Rand

-- 
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/aa15ea90-962f-c585-1a36-06c5a8e19e90%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Re: [qubes-devel] Window border colors

2016-07-27 Thread Jeremy Rand
45in10+d44wd6z0yzqcg via qubes-users:
> The proposed workaround solved part of the issue, however I'm still facing 
> issues with application windows that are not displayed as outlined on my 
> previous comment:
> 
> Since this update every time a command is launched, when the respective AppVM 
> is down, the window is not displayed and the AppVm shows as being in a 
> transient state (for instance, when launching the gnome-terminal, the 
> terminal console only gets displayed after another instance of gnome-terminal 
> is launched, then two terminal console windows are displayed)

I think this is an independent issue.  It's been happening to me
intermittently for at least a week prior to the update that broke the
window border colors.  In fact, I think it's been happening to me
intermittently since I started using 3.2rc1.

-Jeremy

-- 
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/838684bb-e06e-59b9-d861-83dcb58d1322%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Re: [qubes-devel] Window border colors

2016-07-26 Thread Jeremy Rand
Marek Marczykowski-Górecki:
> On Wed, Jul 27, 2016 at 04:32:24AM +0000, Jeremy Rand wrote:
>> Marek Marczykowski-Górecki:
>>> On Tue, Jul 26, 2016 at 03:11:33PM -0700, Andrew David Wong wrote:
>>>> On 2016-07-26 14:52, Manuel Amador (Rudd-O) wrote:
>>>>> Hello.  I just did an update, rebooted, and now my window borders do not 
>>>>> have the VM's colors.  The prefix on the window title is correct tho.
>>>>>
>>>>>
>>>>> What gives?
>>>>>
>>>>>
>>>
>>>> That sounds very strange. Have you done any kind of customization or made 
>>>> any
>>>> changes from the defaults? For example, have you changed the colors or 
>>>> changed
>>>> the window border style?
>>>
>>>> Also, are you using KDE or XFCE? R3.1 or R3.2-rc1?
>>>
>>> Those are important questions.
>>>
>>> In addition, please provide version of qubes-gui-dom0 package. And check
>>> properties of some VM window using xprop from dom0 (call xprop, then
>>> click on some VM window). Especially those properties:
>>> _QUBES_LABEL
>>> _QUBES_LABEL_COLOR
>>> _KDE_NET_WM_COLOR_SCHEME
>>>
>>>
> 
>> Same thing has happened to me.
> 
>> No customizations have been done.  I initially thought it might be due
>> to customizations, so I reinstalled Qubes from scratch, did a
>> qubes-dom0-update, and rebooted, and it happened.  So definitely not due
>> to customizations.
> 
>> All the windows now appear to have the window border coloring that is
>> normally associated with dom0 (gray when not in focus, cyan when in
>> focus).  Also interestingly, the icon of the Launcher in the Panel has
>> disappeared and became solid white.  (I was able to workaround it by
>> right-clicking it, and in the settings dialog manually choosing an icon
>> from the list.)  In addition, there is now an odd icon on the left side
>> of every window title bar (just to the right of the application icon)
>> that I don't recall ever being there before; it looks like a 1-pixel
>> thick square with the corner pixels removed.  (I can provide a
>> screenshot if you need it.)
> 
>> KDE on 3.2rc1.
> 
>> "dnf info qubes-gui-dom0" in dom0 shows version 3.2.1.
> 
>> I did the xprop you requested, and clicked on the fedora-23 TemplateVM.
> 
>> _QUBES_LABEL is 8.
>> _KDE_NET_WM_COLOR_SCHEME is
>> "/home/jeremy/.local/share/qubes-kde/black.colors".
> 
> This looks ok. I assume the file exists too.
> 
>> _QUBES_LABEL_COLOR does not show up in the xprop output at all.
> 
> This is also ok in qubes-gui-dom0 3.2.1.
> 
>> Hope this helps in diagnosing.
> 
> Try this:
> 
> Go to system settings -> Application Style -> Window Decorations. It
> should be set to "Breeze". If it is set to "Plastik", it may be the
> cause of the problems.
> 
> If this is the case, I think this may be related to KDE update done by
> Fedora recently (a lot of kf5-* packages), so unrelated to
> qubes-gui-dom0 version.

Yes!  It was set to Plastik.  Changing it to Breeze and clicking Apply
instantly fixed the issues.  (Well, I can't test whether it fixed the
icon of the launcher, because I've already done the workaround that I
described previously.  But everything else is fixed now.)

Thank you Marek!

-Jeremy

-- 
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/17fc9fcc-f323-1b34-9183-20006cd62519%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Re: [qubes-devel] Window border colors

2016-07-26 Thread Jeremy Rand
Marek Marczykowski-Górecki:
> On Tue, Jul 26, 2016 at 03:11:33PM -0700, Andrew David Wong wrote:
>> On 2016-07-26 14:52, Manuel Amador (Rudd-O) wrote:
>>> Hello.  I just did an update, rebooted, and now my window borders do not 
>>> have the VM's colors.  The prefix on the window title is correct tho.
>>>
>>>
>>> What gives?
>>>
>>>
> 
>> That sounds very strange. Have you done any kind of customization or made any
>> changes from the defaults? For example, have you changed the colors or 
>> changed
>> the window border style?
> 
>> Also, are you using KDE or XFCE? R3.1 or R3.2-rc1?
> 
> Those are important questions.
> 
> In addition, please provide version of qubes-gui-dom0 package. And check
> properties of some VM window using xprop from dom0 (call xprop, then
> click on some VM window). Especially those properties:
> _QUBES_LABEL
> _QUBES_LABEL_COLOR
> _KDE_NET_WM_COLOR_SCHEME
> 
> 

Same thing has happened to me.

No customizations have been done.  I initially thought it might be due
to customizations, so I reinstalled Qubes from scratch, did a
qubes-dom0-update, and rebooted, and it happened.  So definitely not due
to customizations.

All the windows now appear to have the window border coloring that is
normally associated with dom0 (gray when not in focus, cyan when in
focus).  Also interestingly, the icon of the Launcher in the Panel has
disappeared and became solid white.  (I was able to workaround it by
right-clicking it, and in the settings dialog manually choosing an icon
from the list.)  In addition, there is now an odd icon on the left side
of every window title bar (just to the right of the application icon)
that I don't recall ever being there before; it looks like a 1-pixel
thick square with the corner pixels removed.  (I can provide a
screenshot if you need it.)

KDE on 3.2rc1.

"dnf info qubes-gui-dom0" in dom0 shows version 3.2.1.

I did the xprop you requested, and clicked on the fedora-23 TemplateVM.

_QUBES_LABEL is 8.
_KDE_NET_WM_COLOR_SCHEME is
"/home/jeremy/.local/share/qubes-kde/black.colors".

_QUBES_LABEL_COLOR does not show up in the xprop output at all.

Hope this helps in diagnosing.

Cheers,
-Jeremy Rand

-- 
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/1329b606-183b-3eec-cc01-9de0bfd287d9%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Can't Boot From Win10 Retail USB

2016-07-18 Thread Jeremy Rand
rick.jeffr...@gmail.com:
> Win10 runs as an HVM; the devs haven't finished building the Windows Tools 
> for it. Within its limits it is fine. 
> 

I can confirm this; I've been running Windows 10 in an HVM for months
with no issues.  Windows Tools support would be nice, but for my use
cases being able to test software I write on the latest OS release is a
higher priority, so it's doing its job just fine.

-Jeremy Rand

-- 
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/6bfa3edf-807d-077a-4a13-126b76763b59%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Sending a directory to a DispVM?

2016-07-18 Thread Jeremy Rand
Andrew David Wong:
> On 2016-07-18 01:27, Jeremy Rand wrote:
>> Hello,
> 
>> Might there be any plans to allow sending a directory to a DispVM? Right 
>> now in Qubes 3.2 rc1, attempting to do so from the file manager GUI in a 
>> Fedora 23 template yields this error:
> 
>> qopen-in-vm: Fatal error: send file to dispVM (error type: Is a directory)
> 
>> The desired behavior, I think, would be to open a file manager window 
>> inside the DispVM that includes the full contents of the selected 
>> directory.  This way, files could be edited in a DispVM that depend on 
>> other nearby files (e.g. document files that reference image files).
> 
>> (I briefly looked on the issue tracker and didn't see any mention of this 
>> topic.)
> 
>> Cheers, -Jeremy Rand
> 
> 
> I think this would fall under "Allow to open more than one file in the same
> DispVM":
> 
> https://github.com/QubesOS/qubes-issues/issues/814

Thanks Andrew!  Yes, that issue looks like a superset of my suggested
use case.

> 
> As Marek says in a comment on this issue:
> 
>> Current "open-in-vm" protocol allow only to pass one file, because we want 
>> the protocol simple AND allow to pass possibly modified file back.
> 
> I've added your comment to this issue. Please note that it's a "help wanted"
> issue, so it's unlikely to be implemented without help from the community.

Sounds good.  I know you guys have a roadmap and priorities, and I
definitely trust you to make the call on what gets developer attention
and what needs community assistance to be implemented.

Cheers,
-Jeremy Rand

-- 
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/34c6616f-4e69-edde-8a31-fd8aa5c42508%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Re: Unable to install 3.2-rc1 on Thinkpad T450s

2016-06-27 Thread Jeremy Rand
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 06/27/2016 04:45 AM, 41zxmg+5qvzr7o3u2us via qubes-users wrote:
> Jeremy,
> 
> You are awesome, that does work indeed. The tutorial is a bit
> unclear, but when I add this as two separate lines it works
> smoothly :)
> 
> 
> Many thanks :)

Glad I could help, and that the hours I spent tinkering with it
(literally just a few hours ago) helped someone other than just me.  :)

Cheers!
- -Jeremy
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXcPgKAAoJEAHN/EbZ1y06a8oP/1xwx5yrc+WxuoyvXnJ9uI9l
lGfTk1uvOSIIqovKcp1z63mZveUrPpXUdeMeahzK5QCChTcyc3w9Vvqj8ezPe/ST
tYeWTdVIMi3V/w+S6pEP0g1F4jtbmvBwFAORPWmqka2mzTa23UoZc6Xu/4BJIiPU
QMNsOr0pbuaxvHwJ6Srm/NYTRf557ztg+4W+pcwiEZXQQxFzKQKBGkbqEFcoKU1Q
Qt4B027n9OHxX3uftyho9cwXcPpPj3W/9h6ZIDt3WbJuAbmi5zjWIXDlfsPQS+sZ
fm7HNa7mVgMMMjmf24+/g23br/X3IFhxHIO6lzFZOeUb1Jn8tjKU0EwsSXArCcQS
Cg31NACvBlk1o5vVs76zDw155i5BY7y/ErdxpwHDBSZPl4MYeo9iyYJ3mHnlXUkM
0qYKGdXFJXTw4MpbD7LvwFhg7MfkM+XCSdc/eK4sJnoGfhNBOhM+KPrS/cVpbIlF
WOTj83lcPPz7bTkRO7dWqzxo9b9Jlu/MfbVAKztI8NLvhJdtWLwkEaJV48ZMIMiZ
uMIOdgHkIebiwdGG3ycKOiDXGPkC7WHUlkS7vwrkcgwGB2BSUu6sP4CN7NY0G0V/
R/SNq3INa5w/2kbZdTz61Qd5cB3SZX/YMyTHgwStDLYd7HRIWnFu9LLpG1KWzU/F
Kq/c/23jdnjKsw1p54LH
=RtGv
-END PGP SIGNATURE-

-- 
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/62ccfafe-117d-3e32-d417-7024e2862b00%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Unable to install 3.2-rc1 on Thinkpad T450s

2016-06-27 Thread Jeremy Rand
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 06/27/2016 04:23 AM, 41zxmg+5qvzr7o3u2us via qubes-users wrote:
> Thanks for the suggestion but this doesn't relate to the problem at
> hands.
> 
> At this stage I'm simply not able to install Qubes 3.2Rc1 due to
> the UEFI implementation from lenovo. I followed the indications
> posted in this article
> (https://www.qubes-os.org/doc/uefi-troubleshooting/) and I was able
> to install Qubes (passing the kernel parameters /mapbs
> /noexitboot). However after the installation is completed and after
> enabled the same corresponding parameters (mapbs=1 noexitboot=1) on
> the installed system into /mnt/sysimage/boot/efi/EFI/qubes/xen.cfg
> I'm not able to boot the new installed system as this hangs on the
> same four penguins that were showed during the installation.
> 
> Thus, I suspect added kernel parameters on the xen.cfg are not
> being passed.
> 
> Any ideas how to solve this?

I don't know if this is your issue, but the instructions are a bit
ambiguous.  I initially tried adding those params to the end of the
"kernel" lines, but they had no effect.  You actually need to add the
params on 2 separate new lines (1 line per param), at the end of each
section that includes a kernel line.  (I.e. all sections except the
first one, because it doesn't have a kernel line.)

@Andrew David Wong, any chance those instructions could be made a
little bit more clear?  I'm totally okay with the fact that I lost a
few hours debugging this (I'm using a release candidate, after all),
but I imagine some users might find this frustrating.

Cheers,
- -Jeremy Rand
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXcPKfAAoJEAHN/EbZ1y06N9YP/2TR/IejUyrsGLvVWesJaK1m
KYWknCbtZBLhFtlHVAGPEGlXNKmGkfm+VdfJyMHQgAic7Vq+2u6eTXDtK0/G2AsW
yoze8bRV3U+IMyWR/97B9T9XL6tmCoW2FH+UWXB9eG+GHhpVHerVhf1rZE4aHVr5
S3Jm0/14yag7Q1vf/NZtqLNLyeyTeo9gQisqLtAw4FVY3IFtnb6NNZWhm7zrCzqi
WxlJsX7vX/q1zD/l3WTvedpNHgKtEo5uXE6WHQL7JyjzCti9InLlf6peRq8GG8wN
BnnQZEudGwCtM6rNIE5UMhJefJeX6tC1SCPjm7ggKKGaTYCNNVXekCo9pWYGyOkz
elTQMtIHCfi7zOYSpuFB6K+DvyPifxrudGiBiWk+M86oWphpf9ZPMHSV01rwiYnR
ICsLjJhX7ecVDZM96ALpil1xlUp4eF270oaAT8V81DzR//Wo8LRi/NX5kPfAR7KD
ZMSMTovytEqSzo9WCe24N+8E2QrjkNsKEbgK6BeXTZNYON5HakHC8oUvIcqPi+F5
Ty39mg3U7pp9ePodZG5DyA4IaUdYFDpAPPebRpeftyg7LvPvau37/m6PeBdcMJo4
c7w9bQ8z6y4ZrdF0pueOOgbtDfwJLCOAeOxKNfdDtMmGg0qg0Q01rhVDazKxS6Jg
l4znrkOS+ecPWlEZywCM
=seIa
-END PGP SIGNATURE-

-- 
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/e6d0bd20-3680-45be-ff94-15f7d06b599e%40gmail.com.
For more options, visit https://groups.google.com/d/optout.