date:20180124

On Wednesday, January 24, 2018 at 2:47:55 PM UTC+2, donoban wrote:
> On 01/24/2018 09:34 AM, beso wrote:
> > On Tuesday, January 23, 2018 at 3:53:15 PM UTC+2, steve.coleman wrote:
> >> On 01/23/2018 04:55 AM, beso wrote:
> >>> Something is eating free space in my system. It step by step decreasing. 
> >>> I haven't found any good solution for that.
> >>>
> >>
> >> This command should give you a clue as to where the space is going:
> >>
> >> $ sudo du -h / | sort  -g | tail -100
> >>
> 
> Try reversing the sort output:
> 
> sudo du -h / | sort  -g -r | tail -100

sudo du -h / | sort -g -r | tail -100
du: `/proc/5947/task/5947/fd/4' ei saa kasutada: No such file or directory
du: `/proc/5947/task/5947/fdinfo/4' ei saa kasutada: No such file or directory
du: `/proc/5947/fd/3' ei saa kasutada: No such file or directory
du: `/proc/5947/fdinfo/3' ei saa kasutada: No such file or directory
0   /proc/109/ns
0   /proc/109/net/stat
0   /proc/109/net/netfilter
0   /proc/109/net/dev_snmp6
0   /proc/109/net
0   /proc/109/map_files
0   /proc/109/fdinfo
0   /proc/109/fd
0   /proc/109/attr
0   /proc/109
0   /proc/108/task/108/ns
0   /proc/108/task/108/net/stat
0   /proc/108/task/108/net/netfilter
0   /proc/108/task/108/net/dev_snmp6
0   /proc/108/task/108/net
0   /proc/108/task/108/fdinfo
0   /proc/108/task/108/fd
0   /proc/108/task/108/attr
0   /proc/108/task/108
0   /proc/108/task
0   /proc/108/ns
0   /proc/108/net/stat
0   /proc/108/net/netfilter
0   /proc/108/net/dev_snmp6
0   /proc/108/net
0   /proc/108/map_files
0   /proc/108/fdinfo
0   /proc/108/fd
0   /proc/108/attr
0   /proc/108
0   /proc/106/task/106/ns
0   /proc/106/task/106/net/stat
0   /proc/106/task/106/net/netfilter
0   /proc/106/task/106/net/dev_snmp6
0   /proc/106/task/106/net
0   /proc/106/task/106/fdinfo
0   /proc/106/task/106/fd
0   /proc/106/task/106/attr
0   /proc/106/task/106
0   /proc/106/task
0   /proc/106/ns
0   /proc/106/net/stat
0   /proc/106/net/netfilter
0   /proc/106/net/dev_snmp6
0   /proc/106/net
0   /proc/106/map_files
0   /proc/106/fdinfo
0   /proc/106/fd
0   /proc/106/attr
0   /proc/106
0   /proc/105/task/105/ns
0   /proc/105/task/105/net/stat
0   /proc/105/task/105/net/netfilter
0   /proc/105/task/105/net/dev_snmp6
0   /proc/105/task/105/net
0   /proc/105/task/105/fdinfo
0   /proc/105/task/105/fd
0   /proc/105/task/105/attr
0   /proc/105/task/105
0   /proc/105/task
0   /proc/105/ns
0   /proc/105/net/stat
0   /proc/105/net/netfilter
0   /proc/105/net/dev_snmp6
0   /proc/105/net
0   /proc/105/map_files
0   /proc/105/fdinfo
0   /proc/105/fd
0   /proc/105/attr
0   /proc/105
0   /proc/10
0   /proc/1
0   /proc
0   /dev/xen
0   /dev/vfio
0   /dev/snd/by-path
0   /dev/snd
0   /dev/raw
0   /dev/qubes_dom0
0   /dev/pts
0   /dev/net
0   /dev/mqueue
0   /dev/mapper
0   /dev/lightnvm
0   /dev/input/by-path
0   /dev/input
0   /dev/dri
0   /dev/disk/by-uuid
0   /dev/disk/by-partuuid
0   /dev/disk/by-partlabel
0   /dev/disk/by-id
0   /dev/disk
0   /dev/cpu/3
0   /dev/cpu/2
0   /dev/cpu/1
0   /dev/cpu/0
0   /dev/cpu
0   /dev/char
0   /dev/bsg
0   /dev/block


-- 
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/00343d00-2601-4409-8c88-7b5da1444bdc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: When creating a fresh sys-usb

On Wednesday, January 24, 2018 at 3:48:33 PM UTC+1, awokd wrote:
> On Wed, January 24, 2018 1:34 pm, ThierryIT wrote:
> > Global settings / default template ?
> >
> >
> >
> > Le mercredi 24 janvier 2018 15:32:55 UTC+2, ThierryIT a écrit :
> >
> >> Hi,
> >>
> >>
> >> What template does it use ?
> >> How to make it change (from fedora to debian template) if I need to do
> >> it ?
> >>
> >> Thx
> 
> Look in VM Settings for sys-usb.

In addition to the above, if the template does not have the Qubes USB Proxy 
instealled, then it needs to be installed in order to use the qvm-usb 
functionality (to pass USB to a VM). Otherwise, one will only have USB in the 
sys-usb (or whichever name one chooses to give it).

It's my understanding this package is what sets the sys-usb different from all 
other VM's. It can also be installed in debian.

Look here https://www.qubes-os.org/doc/usb/
Scroll down to near the bottom (or use Ctrl+f to search) and look for the 
headlines containing "Qubes-Proxy-USB".

Warning: DO NOT use the "create sys-usb" part of the guide, unless you know the 
implications of it. For example, if you have a machine which only have USB 
keyboard/mouse input, and you use these commands to automatically make a 
sys-usb, then you might risk having a system that no longer can communicate 
with your keyboard or mouse if the USB controller your keyvoard and mosue 
relies on, no longer can communicate with dom0. The guide in the link also 
tells one how to do this with sys-usb, so you need to be sure you know what 
you're doing if you rely on your USB keyboard/mouse. 

If you don't have a PS/2 port with keyboard or mouse, or some other way to 
communicate, then you'll have a hard time to "undo" this mistake. In other 
words, be sure Qubes don't looses the USB controller it relies on to keep your 
USB keyboard/mouse working, or alternatively be sure the sys-usb sends 
mouse/keyboard input back to dom0 before it activates. Be careful, and one 
should probably make a backup of all ones qubes before you make a sys-usb, just 
in case you make a mistake.

-- 
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/50e4cb2f-be7c-4fa9-b684-08af9f31dcc1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Touchpad Problem on Acer laptop

2018-01-24 Thread darklampz


Also, if I go further in the installation using a mouse, I get an error message 
that says "3 more MB needed on /boot/efi, even though the partition has just 
been created by the installer himself.

-- 
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/a60bd797-e63a-48db-9d46-dd9e9988e27d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Touchpad Problem on Acer laptop

2018-01-24 Thread darklampz

Il giorno mercoledì 24 gennaio 2018 15:27:16 UTC+1, dark...@gmail.com ha 
scritto:
> Hi,
> today I tried installing qubes os 4.0 rc3 on my laptop but I'm not able to 
> use the touchpad inside of the installation process.
> What I tried: redownloaded the iso, reflashed multiple times, swapped USB 
> key, changed bios settings, troubleshooting mode.
> I also tried using an external usb mouse and it works, but I don't want to go 
> further on the installation process if I won't be able to use my touchpad 
> afterwards.
> If you have any idea on how to fix this I'd be very grateful.

Also, if I go further in the installation using a mouse, I get an error message 
that says "3 more MB needed on /boot/efi, even though the partition has just 
been created by the installer himself.

-- 
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/67dffea8-ce44-4e1d-bb10-322cbb6458d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] blanking screen with dpms off induces locking - how to disable?

2018-01-24 Thread 'Guillaume Bertin' via qubes-users

On January 24, 2018 7:41 PM, 'Tom Zander' via qubes-users 
 wrote:

> On Monday, 22 January 2018 15:56:06 CET 'Guillaume Bertin' via qubes-users
> wrote:
>
>> My ideal configuration for my standalone home computer would be "dpms
>> after 10 minutes" and "lock after 120 minutes".
>
> I'm not sure if this is the kind of answer you are looking for;
>
> xscreensaver is a really really old application and there are plenty of
> better ones, some likely do have the kind of features you and awod are
> looking for.
>
> I personally use kde which does this all.
> It has a "lock automatically (x min)" separate from
> "require password after locking (x seconds)"
> and "dim screen", "turn off screen" etc are all separately configurable.

These settings are also separately configurables with xscreensaver. :-)

On my Debian box (without Qubes) it works as expected, so I suspect a 
Qubes-specific or xfce-specific issue ("bug" of "feature"?).

Replacing xscreensaver could be an option, but I like this old and simple 
program. It does the job without depending on big libs.

Guillaume

-- 
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/cG3wwcUd9qj6Yi9Sd_sbvjqdW6P2XwFJUccUipxZVhPip6IcjX9hU2t1o8MzQ7ScRq8u_8yite5r7ina8ymdyIgtfoTNqqvHFlMdqNngYpg%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: No space left

On Tuesday, January 23, 2018 at 10:55:15 AM UTC+1, beso wrote:
> Something is eating free space in my system. It step by step decreasing. I
> haven't found any good solution for that.

Are you on Qubes 4 or Qubes 3.2.?

Perhaps discard or trimming is not working? I.e. every time have more space was
required, and following delete "of any files" (doesnt matter which), then the
virtual volume won't shrink again. I've recently had this issue too, assuming
it's the same issue you have.

Also you can verify if the above is the case or not, by checking your VM size
outside the VM, and then confirm the actual space used for your files inside
the VM, and see if they somewhat match. For example, run in dom0 terminal
"qvm-ls --format disk" and look at the PRIV-CURR column. The numbers are shown
in megabytes, i.e. 1000MB is the same as 1GB.

Then open up your VM, find the /rw folder, and right click on it to get the
size of the folder.

You're not looking for exact matching values here, but if the values are vastly
apart, then the above issue is probably what you're having. I never
investigated the exat cause of this issue, but I suspect it was discard not
working properly in the VM's, albeit discard in dom0 started working properly
after I enabled it.
Among the VM's that did not work, and took alot of disk space, I had to dispose
of. I just simply transferred all my files to a new AppVM and deleted the old
one after verifying if everything was working. I regained some 30GB alone on my
128GB disk, just by doing this. Perhaps you're having a similar issue.

Sometimes restating all of Qubes may help too, it may sometimes be a quick
temporary fix. Neither is replacing VM's with new ones. The real fix to this
issue is to get discard to work properly, not only in dom0, but also inside
each VM template.

--
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/47be5edb-334c-496e-8d2c-6eda47662329%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] VPN issues after upgrading to fed26?

2018-01-24 Thread Stumpy




On 25.01.2018 00:10, Chris Laprise wrote:

On 01/24/2018 05:58 PM, Stumpy wrote:
I recently upgraded to fedora 26 from 24 and since then I have not 
been able to get my VPN NetVM to work.
I have tried some things mentioned in other posts to restart my vpnvm 
like

qvm-run -u root my_vpn_vm "/rw/config/rc.local"
Which does get a "VPN: Starting..." notification but that is it, it 
never actually starts/runs.
As I am feeling a bit naked w/o my VPNvm I'd really appreciate any 
suggestions!




Are you using the regular or minimal fedora template? The newest
minimal template may require additional packages.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886


Sorry, that is an important/relevant detail I forgot to mention.

No. I am using the full template, not minimal.

--
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/f069f141fb659139f7295399d8db7f14%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: [qubes-announce] [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

2018-01-24 Thread yrebstv

On 2018-01-23 23:29, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Dear Qubes Community,
> 
> We have just updated Qubes Security Bulletin (QSB) #37:
> Information leaks due to processor speculative execution bugs.
> 
> The text of the main changes are reproduced below. For the full
> text, please see the complete QSB in the qubes-secpack:
> 
> 
> 
> Learn about the qubes-secpack, including how to obtain, verify, and
> read it:
> 
> 
> 
> View all past QSBs:
> 
> 
> 
> View XSA-254 in the XSA Tracker:
> 
> 
> 
> ```
> Changelog
> ==
> 
> 2018-01-11: Original QSB published
> 2018-01-23: Updated mitigation plan to XPTI; added Xen package versions
> 
> [...]
> 
> (Proper) patching
> ==
> 
> ## Qubes 4.0
> 
> As explained above, almost all the VMs in Qubes 4.0 are
> fully-virtualized by default (specifically, they are HVMs), which
> mitigates the most severe issue, Meltdown. The only PV domains in Qubes
> 4.0 are stub domains, which we plan to eliminate by switching to PVH
> where possible. This will be done in Qubes 4.0-rc4 and also released as
> a normal update for existing Qubes 4.0 installations. The only remaining
> PV stub domains will be those used for VMs with PCI devices. (In the
> default configuration, these are sys-net and sys-usb.) To protect those
> domains, we will provide the Xen page-table isolation (XPTI) patch, as
> described in the following section on Qubes 3.2.
> 
> ## Qubes 3.2
> 
> Previously, we had planned to release an update for Qubes 3.2 that would
> have made almost all VMs run in PVH mode by backporting support for this
> mode from Qubes 4.0. However, a much less drastic option has become
> available sooner than we and the Xen Security Team anticipated: what the
> Xen Security Team refers to as a "stage 1" implementation of the Xen
> page-table isolation (XPTI) mitigation strategy [5]. This mitigation
> will make the most sensitive memory regions (including all of physical
> memory mapped into Xen address space) immune to the Meltdown attack. In
> addition, this mitigation will work on systems that lack VT-x support.
> (By contrast, our original plan to backport PVH would have worked only
> when the hardware supported VT-x or equivalent technology.)
> 
> Please note that this mitigation is expected to have a noticeable
> performance impact. While there will be an option to disable the
> mitigation (and thereby avoid the performance impact), doing so will
> return the system to a vulnerable state.
> 
> The following packages contain the patches described above:
> 
>  - Xen packages, version 4.6.6-36
> 
> [...]
> 
> Here is an overview of the VM modes that correspond to each Qubes OS
> version:
> 
> VM type \ Qubes OS version | 3.2 | 4.0-rc1-3 | 4.0-rc4 |
> - -- | --- | - | --- |
> Default VMs without PCI devices| PV  |HVM|   PVH   |
> Default VMs with PCI devices   | PV  |HVM|   HVM   |
> Stub domains - Default VMs w/o PCI | N/A |PV |   N/A   |
> Stub domains - Default VMs w/ PCI  | N/A |PV |   PV|
> Stub domains - HVMs| PV  |PV |   PV|
> 
> ```
> 
> On 2018-01-11 08:57, Andrew David Wong wrote:
>> Dear Qubes Community,
>>
>> We have just published Qubes Security Bulletin (QSB) #37:
>> Information leaks due to processor speculative execution bugs.
>> The text of this QSB is reproduced below. This QSB and its accompanying
>> signatures will always be available in the Qubes Security Pack
>> (qubes-secpack).
>>
>> View QSB #37 in the qubes-secpack:
>>
>> 
>>
>> Learn about the qubes-secpack, including how to obtain, verify, and
>> read it:
>>
>> 
>>
>> View all past QSBs:
>>
>> 
>>
>> View XSA-254 in the XSA Tracker:
>>
>> 
>>
>> ```
>>  ---===[ Qubes Security Bulletin #37 ]===---
>>
>>January 11, 2018
>>
>>
>> Information leaks due to processor speculative execution bugs
>>
>> Summary
>> 
>>
>> On the night of January 3, two independent groups of researchers
>> announced the results of their months-long work into abusing modern
>> processors' so-called speculative mode to leak secrets from the system's
>> privileged memory [1][2][3][4]. As a response, the Xen Security Team
>> published Xen Security Advisory 254 [5]. The Xen Security Team did _not_
>> previously share information about these problems via their (non-public)
>> security pre-disclosure list, of which the Qubes Security Team is a
>> member.
>>
>> In the limited time we've had to

[qubes-users] Re: Qubes and Whonix now have next-generation Tor onion services!

2018-01-24 Thread allisonmwelter

On Tuesday, January 23, 2018 at 2:26:09 AM UTC-5, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Dear Qubes Community,
> 
> The Qubes and Whonix projects now have next-generation Tor onion
> services [1] (a.k.a. "v3 onion services"), which provide several
> security improvements [2] over v2 onion services:
> 
> Qubes:
> http://sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion
> 
> Whonix:
> http://dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion
> 
> These services run alongside our existing ("v2") onion services:
> 
> Qubes:
> http://qubesos4z6n4.onion
> 
> Whonix:
> http://kk63ava6.onion
> 
> For instructions on accessing the new addresses and further details,
> please see the Whonix announcement [3]. Our sincere thanks go to the
> Whonix team, and especially fortasse, the Whonix server
> administrator, for doing this.
> 
> 
> [1] 
> https://blog.torproject.org/tors-fall-harvest-next-generation-onion-services
> [2] https://trac.torproject.org/projects/tor/wiki/doc/NextGenOnions
> [3] https://www.whonix.org/blog/whonix-new-v3-onion-address
> 
> This announcement is also available on the Qubes website:
> https://www.qubes-os.org/news/2018/01/23/qubes-whonix-next-gen-tor-onion-services/
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpm44UACgkQ203TvDlQ
> MDBlMg//T7lj6NCoy8YNNKDSjtkoe6WIcfdvoLFxQrIy+fmEJMQKTgKBb18kFxH4
> Q67+iyL+hvhFOCb3ss98Xj2ogrRvv4VkPypPRmmMRx7dJChpCdBylRNtx0rPslw9
> OUNHw3mj3frXjAbw4cOb2Tlsd8ANKDrQoFMaADKfenLCQnMzPpqMx4rt0Rw912Jn
> +wShCF6RM0gyUFTiqxYrPgJn0RHvSUVKlWwFCUXWVnGmvdwRy7G5bqb6/a6RrV8p
> CO3zXHM+/pclfK4ls61FyseYY2iIOLCqVid7Oez/BWqVS4ckmQWknK1juo2/Qzwm
> exNCSF2+nzGfg9v15LiOKDP/35hiqvh04y1JPUf2WbivWGUfkOpNt1rvdSHa/wjH
> f6y42Dqq5GYfcz9XGmehazKCI4/usXOpa+eH3Uar3hJD5AIe0f/3URe9LrdUgp68
> bN0WLcu9ctpAXtufhbgf2KcPwhrsB9uBqG4fBgHl9YLRgppv8tiuteKosFuhDOGE
> CpskV3izqmyLYIQ1P9u3wvM4/MZ652fBZKUD/4PNrEQuW8g6Nmv0dFD/KE2V/72G
> TME+YKVSB8Rs8Q3dfgVLw5gnF5Z3p/0i0EfM0m5LuBF4ScFGAMAVnZ+Ax61ESNkD
> 1Bv0+xS3lpTHs05Qw/MY8ecSbcZTHPqF9a8jTUmc1CMJNm5EceI=
> =cwtv
> -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/3f6f55b0-457c-49c3-90d2-1c761c952d35%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] USB3 attach problem

ERROR: Device attach failed: USB SuperSpeed require kernel >= 
4.13/usr/lib/qubes/usb-import: line 71: printf: write error: Invalid argument

-- 
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/5228e1b7-7bd2-4b1d-ab8a-1f3afe5cdd97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Do allowing USB Keyboard expose to badusb attacks?

2018-01-24 Thread taii...@gmx.com

If you buy crappy USB devices that have internal firmware re-write
capability for no reason then yes, or if you let random people plug
devices in to your "trusted" usb controller (most boards have two)

I would suggest only buying USB devices where the firmware can only be
re-written externally not internally from the computer.
Unicomp's high quality mechanical keyboards (they are also made in
america not china so they are trustworthy) come with write-locked ROM
firmware as there is no reason to have re-writable firmware on a keyboard.

I am not sure what to buy for a mouse however but unicomp makes a
keyboard with a trackball and another with a pointing stick similar to a
laptop keyboard.

If you purchase a motherboard with libre firmware (not purism) such as
the KCMA-D8 or the (blobs for video and power unfortunately, so open
source but not libre) lenovo g505s laptop you can easily verify that the
firmware has not been fucked around with via a usb attack such as the
intel skylake debug controller exploit.

--
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/1968bbdf-f158-ec8d-4c1c-8a92612b8542%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] VPN issues after upgrading to fed26?

2018-01-24 Thread Chris Laprise

On 01/24/2018 06:10 PM, Chris Laprise wrote:

On 01/24/2018 05:58 PM, Stumpy wrote:
I recently upgraded to fedora 26 from 24 and since then I have not
been able to get my VPN NetVM to work.
I have tried some things mentioned in other posts to restart my vpnvm
like

qvm-run -u root my_vpn_vm "/rw/config/rc.local"
Which does get a "VPN: Starting..." notification but that is it, it
never actually starts/runs.
As I am feeling a bit naked w/o my VPNvm I'd really appreciate any
suggestions!

Are you using the regular or minimal fedora template? The newest minimal
template may require additional packages.

I re-tested on regular f26 (installed from qubes-template-fedora-26) and
it works. (Just remember that Qubes 4.0rc still needs a
'qubes-ip-change-hook' symlink that points to
`qubes-firewall-user-script` in the same /rw/config dir.)

You can try using the Qubes-supplied f26, otherwise my suggestion is to
troubleshoot by changing the top lines in rc.local to:

---
#!/bin/bash
VPN_CLIENT='openvpn'
VPN_OPTIONS='--cd /rw/config/vpn/ --config openvpn-client.ovpn'
[[ $1 == 'test' ]] || VPN_OPTIONS="$VPN_OPTIONS --daemon"
---

Then you can see the status messages in the CLI when you manually run it
like so:

$ sudo pkill openvpn
$ sudo /rw/config/rc.local test

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

--
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/8891b0f8-365f-ebe8-7f4a-39c386108b00%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] VPN issues after upgrading to fed26?

2018-01-24 Thread Chris Laprise


On 01/24/2018 05:58 PM, Stumpy wrote:
I recently upgraded to fedora 26 from 24 and since then I have not been 
able to get my VPN NetVM to work.

I have tried some things mentioned in other posts to restart my vpnvm like
qvm-run -u root my_vpn_vm "/rw/config/rc.local"
Which does get a "VPN: Starting..." notification but that is it, it 
never actually starts/runs.
As I am feeling a bit naked w/o my VPNvm I'd really appreciate any 
suggestions!




Are you using the regular or minimal fedora template? The newest minimal 
template may require additional packages.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/b3310949-385b-19be-e4ce-ba823ef5f9ea%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: No space left

On Tuesday, January 23, 2018 at 10:55:15 AM UTC+1, beso wrote:
> Something is eating free space in my system. It step by step decreasing. I
> haven't found any good solution for that.

I forgot to add, before you right click on the /rw folder of any VM you might
suspect to have space issues, make sure first that invisible folders and files
are shown, otherwise they won't be counted in the size calculation. In fedora
templates, the normal files window manager, simply just hold Ctrl, and then
type "H" once. Then all hidden files should be shown in that folder, and all
sub-folders, and a more accurate measure of the actual used size will show.

For example Firefox's hidden folder in /home is usually use several 100MB's,
and it can make a difference in your size comparison. Thunderbird can also be
quite big, i.e. my Thunderbird hidden folder in /home is several GB's in size.

Keep in mind that /rw (read / write) folder, is where your /home folder is,
among other folders, which an AppVM needs to have write access to.

--
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/823b0222-7173-4386-b063-4d8a4d59da5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: No space left

On Thursday, January 25, 2018 at 2:12:25 AM UTC+2, Yuraeitha wrote:
> On Tuesday, January 23, 2018 at 10:55:15 AM UTC+1, beso wrote:
> > Something is eating free space in my system. It step by step decreasing. I 
> > haven't found any good solution for that.
> 
> I forgot to add, before you right click on the /rw folder of any VM you might 
> suspect to have space issues, make sure first that invisible folders and 
> files are shown, otherwise they won't be counted in the size calculation. In 
> fedora templates, the normal files window manager, simply just hold Ctrl, and 
> then type "H" once. Then all hidden files should be shown in that folder, and 
> all sub-folders, and a more accurate measure of the actual used size will 
> show.
> 
> For example Firefox's hidden folder in /home is usually use several 100MB's, 
> and it can make a difference in your size comparison. Thunderbird can also be 
> quite big, i.e. my Thunderbird hidden folder in /home is several GB's in 
> size. 
> 
> Keep in mind that /rw (read / write) folder, is where your /home folder is, 
> among other folders, which an AppVM needs to have write access to.

Thank for the answer. Actually I didn't understand "qvm-ls --format disk" 
command. So I couldn't compare them. I trimmed again all my appvm-s, I got back 
about 5G. 
One strange thing for me - in case I start some appvm, free space is increasing 
about 500MB. It is different every time.
So its increasing and then starts decreasing. Sometimes this decreasing stops 
but sometime it goes to 0.  

-- 
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/4f63b4bd-2f28-4999-8a3a-4585ef040fdb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: USB3 attach problem

On Thursday, January 25, 2018 at 5:01:00 AM UTC+2, cooloutac wrote:
> On Wednesday, January 24, 2018 at 2:35:14 PM UTC-5, beso wrote:
> > ERROR: Device attach failed: USB SuperSpeed require kernel >= 
> > 4.13/usr/lib/qubes/usb-import: line 71: printf: write error: Invalid 
> > argument
> 
> I don't have this issue on 3.2.  are you using 4.0?

No, I use 3.2.

-- 
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/23b44686-4fb8-45eb-b4d6-61647dc6825c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Save virtual machine state?

2018-01-24 Thread Loren Rogers

I'm sure this has already been discussed, but is there a way to save the state 
of a virtual machine, instead of shutting it down? I can't find any info in the 
docs on what exactly pausing a VM does, but could this be similar?

Thanks

-- 
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/YLlI92_baYNpOg00YB4EBKyADgnxFp2i6wCS-y26odAuiU5L5EKtPZuEqNPVDT2ENEsEZKMlj_ZL35v3It5H10tu4GCQAgeyRmmckPxXxKE%3D%40lorentrogers.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] OpenGL 4.0

2018-01-24 Thread Andrew Morgan

Hello all,

I know GPU virtualization is currently not possible, so we have software
rendering with mesa. Currently, I only seem to be able to run Open GL ES
OpenGL ES 2.0 with Mesa 17.2.4.

I'm aware we're only able to use software drivers here, but is there a
way to run a more up-to-date OpenGL version, such as 4.0+ within a Qube?

Thanks,
Andrew Morgan

-- 
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/p4bj5u%24h6s%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] Re: [qubes-announce] [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

2018-01-24 Thread yrebstv

On 2018-01-24 15:12, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2018-01-24 16:14, yreb...@riseup.net wrote:
>> [...]
>>
>> So... there are packages *to be released *at some undefined point
>> in the near future? -- The following packages contain the patches
>> described above:
>>
>> - Xen packages, version 4.6.6-36 --
>>
>> via the normal dom0 update process ?   would be nice to see it in
>> simple English
>>
> 
> Sorry! We forgot to include our usual patching instructions. I've just
> created a pull request [1] to have this added to the QSB:
> 
> ```
> The specific packages that contain the XPTI patches for Qubes 3.2 are
> as follows:
> 
>   - Xen packages, version 4.6.6-36
> 
> The packages are to be installed in dom0 via the Qubes VM Manager or via
> the qubes-dom0-update command as follows:
> 
>   For updates from the stable repository (not immediately available):
>   $ sudo qubes-dom0-update
> 
>   For updates from the security-testing repository:
>   $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
> 
> A system restart will be required afterwards.
> 
> These packages will migrate from the security-testing repository to the
> current (stable) repository over the next two weeks after being tested
> by the community.


1)
The latter (security) packages will migrate, I'd assume this means ?  

2)
Where would I find the repositories in dom0 for the track I'm currently
using?

3) 
after doing the 1x securitytesting repo update, how do I check which Xen
package is now installed? and/or  how do I bring up the  GUI
update manager  when it doesn't actually need to update it doesn't
persist 

cc: thelist

-- 
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/239f63f73844750735049543719e3032%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: USB3 attach problem

2018-01-24 Thread cooloutac

On Wednesday, January 24, 2018 at 2:35:14 PM UTC-5, beso wrote:
> ERROR: Device attach failed: USB SuperSpeed require kernel >= 
> 4.13/usr/lib/qubes/usb-import: line 71: printf: write error: Invalid argument

I don't have this issue on 3.2.  are you using 4.0?

-- 
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/34b895b7-fc53-41b7-8ac0-4caff507053d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes and Whonix now have next-generation Tor onion services!

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2018-01-24 04:28, Andrew David Wong wrote:
> On 2018-01-23 09:17, Alex Dubois wrote:
>> On Tuesday, 23 January 2018 07:26:09 UTC, Andrew David Wong  wrote:
>> Dear Qubes Community,
> 
>> The Qubes and Whonix projects now have next-generation Tor onion
>> services [1] (a.k.a. "v3 onion services"), which provide several
>> security improvements [2] over v2 onion services:
> 
>> Qubes:
>> http://sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion
> 
>>> Is it https://www.qubes-os.org/ over tor? or is it to get Qubes updates?
>  
> At least the website, but possibly for both. Right now, you can get
> Qubes updates via yum.qubesos4z6n4.onion and
> deb.qubesos4z6n4.onion. It should (eventually) also work with the
> next-gen onion service, but I'm not sure if it's set up yet. I asked
> fortasse:
> 
> https://github.com/QubesOS/qubes-issues/issues/2576#issuecomment-360087220
> 

fortasse wrote:

"Yes. All of the subdomains for qubesos4z6n4.onion _should_ work on
sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion. Let me
know if that's not the case."

https://github.com/QubesOS/qubes-issues/issues/2576#issuecomment-360304683

> 
>> Whonix:
>> http://dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion
> 
>> These services run alongside our existing ("v2") onion services:
> 
>> Qubes:
>> http://qubesos4z6n4.onion
> 
>> Whonix:
>> http://kk63ava6.onion
> 
>> For instructions on accessing the new addresses and further details,
>> please see the Whonix announcement [3]. Our sincere thanks go to the
>> Whonix team, and especially fortasse, the Whonix server
>> administrator, for doing this.
> 
> 
>> [1] 
>> https://blog.torproject.org/tors-fall-harvest-next-generation-onion-services
>> [2] https://trac.torproject.org/projects/tor/wiki/doc/NextGenOnions
>> [3] https://www.whonix.org/blog/whonix-new-v3-onion-address
> 
>> This announcement is also available on the Qubes website:
>> https://www.qubes-os.org/news/2018/01/23/qubes-whonix-next-gen-tor-onion-services/

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlppKhAACgkQ203TvDlQ
MDCmsg//RRW8IfLILkqskKyaYcGrrA1oD/Xl4kEGBPUOKqsNkQlug703wefYOjxq
43u9DF8dvHrUIIrXEibQuNkJGN+7LZMfjVc80w5tEIVaN86HHcivEirYGVBo9OrK
eAtcB3Nl/zE7jJ1yzt4ZKDlSxyJWRG9/NZRgJvhWgGwLXhjXHswwU1I+mkAm2JZf
uGcW6W+8xVqwiPiAHtzxx93ED9m1NLZ0dLpxCPN+w0cn8gsNltnKB6+CNahLJPaC
4J+hnfgCGD6GuOKRtxaeaVezQ0jHsHdTp9NdF9Epye4RPiuPlyseIGF1kyU/cHUd
+C6mgQ1PQIHtcX+09JAC7X+TKYcmuyklZ51dy9uyenj/4kp+STtSJb6fdHnj247S
/bHzuuGHqP/iPCkwzWsTxRsq2UZvr7f4pltUeh5Jf+OFkGx4PRE8PYzsNlF16OyI
15uTz64GUohQV5TpY9NNONtRt7TDH5XRS1bnjeddqLfYag9KDzTuqHrftP7uvYS8
x+DOLntreMg1XpdtODaAka8QdjSD2wS11+I/JYhlGFVt6W4/nk/6LQg269gtNVqh
ym2IDma/9cxKwn+1m8DcZ4ug/GMFB2/BUdzLP+liyw8HM2qmbxLMPfHv8+0BubLr
rSRftFF6S37JltkfhhG2U95Sv4peZ50Vu6AHQ+B5nCYwfrnH29U=
=og88
-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/baeb4b60-a9e9-0fc9-7c13-82424b16a4b9%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: [qubes-announce] [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2018-01-24 16:14, yreb...@riseup.net wrote:
> [...]
> 
> So... there are packages *to be released *at some undefined point
> in the near future? -- The following packages contain the patches
> described above:
> 
> - Xen packages, version 4.6.6-36 --
> 
> via the normal dom0 update process ?   would be nice to see it in
> simple English
> 

Sorry! We forgot to include our usual patching instructions. I've just
created a pull request [1] to have this added to the QSB:

```
The specific packages that contain the XPTI patches for Qubes 3.2 are
as follows:

  - Xen packages, version 4.6.6-36

The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:

  For updates from the stable repository (not immediately available):
  $ sudo qubes-dom0-update

  For updates from the security-testing repository:
  $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing

A system restart will be required afterwards.

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.

If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new Xen
binaries.
```

[1] https://github.com/QubesOS/qubes-secpack/pull/18

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlppLtoACgkQ203TvDlQ
MDDTmRAAw2QrNmo6JHHrgwa7Y2izZXIA84sjE/3HRVA1PkTZTlef3y6xLzCB9nYn
o3TFnIvgHztkqlNFw67DMIGaXj8lf/KotlknnEIl8uuDufJNtjZHQ36KFkOud4KU
H7nlKGSYELzAllydPhQZy6joqCcgCWAscJDwHNq8wDcMjgXVp0/E42jP6tGvYylL
4cCg66sjAoGH3jN8sJZZhaWKfhS7N+CagATUgHPjSy7d3Zh2hTI7JGOofGJ7V92f
YZ2s7CEu8RAxYld8GHzyRasKL8Ri+gLx2uUa+qlKmBVNvRMuoUeysu0oHJmEHMEG
uZsrrCL/ldL1jYyaXhsJt6lrUxgwYC7MuVp5NlnFsKxmw1fN2enjnOUVMV4/ikdI
iGq02cagbtLowO5vctQz4heNFo583xhFRk0ib9BBeb1vx4qfhMrJkZ3qEmWFlq8j
ZFbE13YNnJflOappGmSIXlB1hx4OqeaZS55ORjIbiIKTM/dZ0wRNDO5LxFFv9b1W
rLF4HFP5AIpNF4AxBp5AeYcPee++8Jqtdgb4nBjlWtiYNIFAwg52xLW6DJLErrOy
YCZ2Ujq+XxtXHFd4Ci131TXTCVkGH3+YzzvYAgErxPMh+wDPT1yhaI8YkhQxExMG
+yBiofdwk10b5k0TVUncW6UgNqo+96cGlIJFxiKjQl4h7X9G0+o=
=W9b/
-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/ab89cb1e-3904-b774-af7d-0773ea8a61b0%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Migrating to 4.0 (backup / restore)

On Tuesday, January 23, 2018 at 5:55:52 PM UTC+1, Nuno Branco wrote:
> Basically, if I backup my current 3.2 VMs am I going to be able to
> restore them on 4.0 ? Not clear on what the implications are of the HVM
> vs PVVM change on 4.0 are for backups / restores.
> 
> -- 
> 
> Best regards,
> Nuno Branco

Any VM's restored from Qubes 3.2. will retain their PV state, but can be 
changed to HVM or PVH. However, it might not be the desired approach, at least, 
in my experience, it isn't. Perhaps newer updates fixed what caused my issues, 
but either way, here is what I recommend to avoid any potential issues.

This might help Ivan too, regarding the issue starting applications. Generally 
my experience have been that using any old templates or AppVM's from Qubes 3.2. 
works "somewhat". However, they were in my experience sluggish, slow, and even 
sometimes error prone. I don't know if this issue has been fixed, but during 
the Qubes 4 RC-2 phase I had this issue. In contrast, any Qubes 4 
templates/AppVM's I made were free from errors, and were running smooth. My 
deduction then, was to get rid of any old 3.2. AppVM's I had, and it did indeed 
help a lot of my issues.

What I did back when I upgraded, is as I initially mentioned above, not what I 
will recommend, because I lost some files doing that. Which is using file 
transfer between Qubes 3.2. and Qubes 4.0 AppVM's. Please be very careful if 
you do this. I'm not sure if this conflic has been fixed, since I no longer 
have any old 3.2. qubes on my Qubes 4 system.

Instead, I will recommend you put all your files on an external drive while 
still on Qubes 3.2., i.e. make a folder for each VM's files. Doing this while 
on Qubes 3.2. will ensure you don't encounter errors and avoid any conflicts. 

After you did that, then just transfer the files back into each their 
respective VM on fresh new Qubes 4.0 VM's. 

Also keep in mind that Qubes 4.0 has the qvm-usb widget, which makes passing 
USB to each VM quite easy and trivial. But be sure you update fully before you 
use it, as its had many updates since RC-3. Also be absolutely sure you 
disconnect from within the VM first when you want to stop using it, before you 
disconnect a drive from the widget itself. Just like you would do before 
unplugging an USB drive normally, instead, you do it twice. Once inside the VM, 
once outside the VM. Maybe this is improved in the future, but right now its 
important to do both steps to avoid data corruption.

You might know some of this already, but just in case. Qubes 4 has PV, HVM, and 
PVH states for VM's. As you know, PV is the one used in Qubes 3.2, and HVM was 
used in Qubes 4 for a while under development from RC-1 to RC-3. However 
recently PVH was made available too. PVH is pr. my understanding great for 
security, except, PCI passthrough does currently not work for any VM using PVH. 
So any template or AppVM, which does not have any PCI devices passed to them, 
you should remain PVH. sys-net should obviously be HVM (or even PV if HVM is 
not working). sys-usb should also be HVM. Windoes 7 should always use HVM. The 
rest can benefit from being PVH. You can change it in the VM-Settings 
preference GUI window for each VM, or instead via terminal by "qvm-prefs 
VM-name virt_mode" which prints the current state of the VM, either reporting 
PV, HVM or PVH.
To change the mode, just write "qvm-prefs VM-name virt_mode pvh", but remember 
to only use HVM for pass-through VM's and full HVM like Win7. Also right now, 
the preference window for each VM doesn't always show the correct PV/HVM/PVH. 
Use the qvm-prefs command to print the state if you want to be sure it's shown 
correct. This will probably be fixed soon.

Be mindful of that Qubes 4 can't simply re-naming VM's so easily like it does 
in Qubes 3.2. In Qubes 4, it will copy the entire VM under the new chosen name, 
and then delete the VM with the old name. Which requires not only a lot of 
extra disk space to pull off, it can also take a while if the VM is large. I've 
heard that there is a good reason for this, but I did not check the technical 
reason.

Some of this is a bit of a hassle, but other than that if you ask me, I'm quite 
enjoy Qubes 4, I'm personally quite happy on it. The issue with my old 3.2. 
AppVM's however did give me a bad start, so as long as you're mindful of this 
potential issue, and your hardware is supported (Qubes 4 is more hardware 
strict than 3.2.), then you should be okay.

Oh, also, be sure to read the Qubes news articles when a new RC-X version is 
released, because the Qubes developers will write if they recommend to 
re-install or not. For example between RC-2 and RC-3 it was said to be fine to 
just update as usual and carry on without re-install. But sometimes, it may be 
needed to re-install Qubes between RC-X releases, just be mindful of this. RC-4 
is still due to be released, and it's still unknown if the current RC-3 can be 
updated, or if a re-install will be

[qubes-users] Re: Migrating to 4.0 (backup / restore)

2018-01-24 Thread cooloutac

On Wednesday, January 24, 2018 at 8:12:22 PM UTC-5, Yuraeitha wrote:
> On Tuesday, January 23, 2018 at 5:55:52 PM UTC+1, Nuno Branco wrote:
> > Basically, if I backup my current 3.2 VMs am I going to be able to
> > restore them on 4.0 ? Not clear on what the implications are of the HVM
> > vs PVVM change on 4.0 are for backups / restores.
> > 
> > -- 
> > 
> > Best regards,
> > Nuno Branco
> 
> Any VM's restored from Qubes 3.2. will retain their PV state, but can be 
> changed to HVM or PVH. However, it might not be the desired approach, at 
> least, in my experience, it isn't. Perhaps newer updates fixed what caused my 
> issues, but either way, here is what I recommend to avoid any potential 
> issues.
> 
> This might help Ivan too, regarding the issue starting applications. 
> Generally my experience have been that using any old templates or AppVM's 
> from Qubes 3.2. works "somewhat". However, they were in my experience 
> sluggish, slow, and even sometimes error prone. I don't know if this issue 
> has been fixed, but during the Qubes 4 RC-2 phase I had this issue. In 
> contrast, any Qubes 4 templates/AppVM's I made were free from errors, and 
> were running smooth. My deduction then, was to get rid of any old 3.2. 
> AppVM's I had, and it did indeed help a lot of my issues.
> 
> What I did back when I upgraded, is as I initially mentioned above, not what 
> I will recommend, because I lost some files doing that. Which is using file 
> transfer between Qubes 3.2. and Qubes 4.0 AppVM's. Please be very careful if 
> you do this. I'm not sure if this conflic has been fixed, since I no longer 
> have any old 3.2. qubes on my Qubes 4 system.
> 
> Instead, I will recommend you put all your files on an external drive while 
> still on Qubes 3.2., i.e. make a folder for each VM's files. Doing this while 
> on Qubes 3.2. will ensure you don't encounter errors and avoid any conflicts. 
> 
> After you did that, then just transfer the files back into each their 
> respective VM on fresh new Qubes 4.0 VM's. 
> 
> Also keep in mind that Qubes 4.0 has the qvm-usb widget, which makes passing 
> USB to each VM quite easy and trivial. But be sure you update fully before 
> you use it, as its had many updates since RC-3. Also be absolutely sure you 
> disconnect from within the VM first when you want to stop using it, before 
> you disconnect a drive from the widget itself. Just like you would do before 
> unplugging an USB drive normally, instead, you do it twice. Once inside the 
> VM, once outside the VM. Maybe this is improved in the future, but right now 
> its important to do both steps to avoid data corruption.
> 
> You might know some of this already, but just in case. Qubes 4 has PV, HVM, 
> and PVH states for VM's. As you know, PV is the one used in Qubes 3.2, and 
> HVM was used in Qubes 4 for a while under development from RC-1 to RC-3. 
> However recently PVH was made available too. PVH is pr. my understanding 
> great for security, except, PCI passthrough does currently not work for any 
> VM using PVH. So any template or AppVM, which does not have any PCI devices 
> passed to them, you should remain PVH. sys-net should obviously be HVM (or 
> even PV if HVM is not working). sys-usb should also be HVM. Windoes 7 should 
> always use HVM. The rest can benefit from being PVH. You can change it in the 
> VM-Settings preference GUI window for each VM, or instead via terminal by 
> "qvm-prefs VM-name virt_mode" which prints the current state of the VM, 
> either reporting PV, HVM or PVH.
> To change the mode, just write "qvm-prefs VM-name virt_mode pvh", but 
> remember to only use HVM for pass-through VM's and full HVM like Win7. Also 
> right now, the preference window for each VM doesn't always show the correct 
> PV/HVM/PVH. Use the qvm-prefs command to print the state if you want to be 
> sure it's shown correct. This will probably be fixed soon.
> 
> Be mindful of that Qubes 4 can't simply re-naming VM's so easily like it does 
> in Qubes 3.2. In Qubes 4, it will copy the entire VM under the new chosen 
> name, and then delete the VM with the old name. Which requires not only a lot 
> of extra disk space to pull off, it can also take a while if the VM is large. 
> I've heard that there is a good reason for this, but I did not check the 
> technical reason.
> 
> Some of this is a bit of a hassle, but other than that if you ask me, I'm 
> quite enjoy Qubes 4, I'm personally quite happy on it. The issue with my old 
> 3.2. AppVM's however did give me a bad start, so as long as you're mindful of 
> this potential issue, and your hardware is supported (Qubes 4 is more 
> hardware strict than 3.2.), then you should be okay.
> 
> Oh, also, be sure to read the Qubes news articles when a new RC-X version is 
> released, because the Qubes developers will write if they recommend to 
> re-install or not. For example between RC-2 and RC-3 it was said to be fine 
> to just update as usual and carry on without

[qubes-users] Re: Do allowing USB Keyboard expose to badusb attacks?

2018-01-24 Thread cooloutac

On Wednesday, January 24, 2018 at 5:47:58 AM UTC-5, koto...@gmail.com wrote:
> If a USB keyboard is allowed with /etc/qubes-rpc/policy/qubes.InputKeyboard, 
> does it increase the risk for badusb kind of attacks?

yes.  like yuraeitha said,  I use a usb to ps/2 adapter for my keyboard.   and 
when using usb mouse in sys-usb I set screenlock to like 1 min.

-- 
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/7a5dd8c9-8096-4253-b61b-49784e7de168%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] which linux works well as a standalone hvm in qubes-4.0?

2018-01-24 Thread pixel fairy

has anyone gotten a linux desktop with more than 800x600 in hvm in qubes-4?

ive tried the linux-HVM-tips. with ubuntu, X -configure usually crashes weather 
or not its run from console. even then, modding the file and putting it in 
/etc/X11 seems to have no effect. the installer for ubuntu 17.10.1 runs in 
1280x720, but goes back to 800x600 after installation.

Fedora27s installer wont boot.

before i got trying a million distros, has anyone else gotten this to work?

my goal is to run virt-manager for windows displays on a remote vagrant-libvirt 
box. vmm wont run in an appvm due to conflicting xen libraries with a fedora-26 
or debian-9 template, though this did work with debian-9 and qubes-3.2

-- 
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/bf86d7bd-89df-45de-be4d-7bd6c9ece1db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Touchpad Problem on Acer laptop

2018-01-24 Thread darklampz

Hi,
today I tried installing qubes os 4.0 rc3 on my laptop but I'm not able to use 
the touchpad inside of the installation process.
What I tried: redownloaded the iso, reflashed multiple times, swapped USB key, 
changed bios settings, troubleshooting mode.
I also tried using an external usb mouse and it works, but I don't want to go 
further on the installation process if I won't be able to use my touchpad 
afterwards.
If you have any idea on how to fix this I'd be very grateful.


-- 
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/b4f4595b-d760-483d-b7da-bb419c03e8e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: When creating a fresh sys-usb

2018-01-24 Thread 'awokd' via qubes-users

On Wed, January 24, 2018 1:34 pm, ThierryIT wrote:
> Global settings / default template ?
>
>
>
> Le mercredi 24 janvier 2018 15:32:55 UTC+2, ThierryIT a écrit :
>
>> Hi,
>>
>>
>> What template does it use ?
>> How to make it change (from fedora to debian template) if I need to do
>> it ?
>>
>> Thx

Look in VM Settings for sys-usb.

-- 
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/8e213aa0fc23ba76266bb91326a1ad62.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

2018-01-24 Thread Ed


On 01/24/2018 04:29 AM, Andrew David Wong wrote:


## Qubes 3.2

Previously, we had planned to release an update for Qubes 3.2 that would
have made almost all VMs run in PVH mode by backporting support for this
mode from Qubes 4.0. 


Out of curiosity, is this still going to happen?  I would love to see 
this if possible, not only helping mitigate Meltdown without the 
performance penalty (I believe), but also would give a nice general 
security boost to 3.2


Thanks,
Ed

--
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/p4a6db%248qa%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] qubes 4.0 hvm crashes on boot after probing EDD

2018-01-24 Thread 'awokd' via qubes-users

On Wed, January 24, 2018 1:18 pm, pixel fairy wrote:
> starting a standalone hvm with
>
> qvm-start myhvm --cdrom=myappvm:/home/user/Downloads/linux.iso
>
> the bootscreen quits just after
>
> Probing EDD (edd=off to disable)... ok

Set Kernel to "" [none].

-- 
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/758144428aaa572d70d4408ec64bbdcd.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Do allowing USB Keyboard expose to badusb attacks?

On Wednesday, January 24, 2018 at 11:47:58 AM UTC+1, koto...@gmail.com wrote:
> If a USB keyboard is allowed with /etc/qubes-rpc/policy/qubes.InputKeyboard,
> does it increase the risk for badusb kind of attacks?

It's been explicitly said by the Qubes developers that it's best to use PS2
keyboard/mouse, or internal laptop keyboards, if possible. Since USB
keyboard/mouse poses risk. This "risk" is highly subject to your risk profile
and environment, as well as your needs. Really, some people may need to worry
much more about badUSB, than other people need to. At least in the current day
and age, it might be much more worrysome for more people in the future.

It's my understanding, that all USB devices have firmware memory, even if the
device has no computer within it (such as usb headphones or speakers, and yes,
keyboards too). Few vendors "lock" the firmware, hench without a lock on the
firmware, it can be modified. If the firmware is "locked", then it's likely
that the device is immune to badUSB, however, few vendors do this, and it's
certainly not a marketing information available when buying either, nor is it
industry recommended (although it probably should be).

By that definition, whereever there is USB, there is an unlocked firmware.
Whereever there is an unlocked firmnware, there is a risk of USB-exploit.
Whereever there is a risk of USB-exploit, there is a risk of badUSB.

- Limit the amount of USB devices that come near your Desktop/Laptop, since
even a single bad exposure means you have to throw the machine away to get rid
of the badUSB.

- Limit USB to trusted USB devices, don't put in other people's USB devices.
BadUSB is like a virus, it can spread from one firmware to the next, and since
there is a firmware on both ends, then it can easily spread.

- Only use new USB devices, never use used ones.

- Don't leave your computer or laptop exposed to questionable people, or people
you don't know well. For example at work, or in the class-room. Even if you put
it to sleep with a password protection when you leave the area, even if you
trust it won't be stolen, you should here still worry if someone inserts a
badUSB to your machine. If power is on, irregardless if it can boot up or not,
then you've been infected the moment firmware talks to each others, and that
happens already at BIOS/UEFI level, or even if there is password protection.

- If you got a desktop, then you can put in a USB-PCI card, and whenever you
feel your USB might be exposed, you can always throw away the PCI card and buy
a new one. Hopefully the badUSB did not spread to other firmwares, but whether
that is likely to happen is outside my knowledge area.

Really, if you're careful, then you don't have to worry as much with badUSB in
comparison to when being reckless and inserting whatever USB. Think of it like
a human infection, you don't go around touching questionable surfaces and then
stick your finger in your mouth, right? The same goes to BadUSB, take your
precautions, and if done right, then you minimize the risk dramatically. No
matter what you do though, there will always be a risk, but the size of the
risk is however still very much in your control, you can minimize it.

--
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/d4a8affb-ba74-4d67-9c06-066cdbe7a589%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How to deal with Yubikey ?

On Wednesday, January 24, 2018 at 3:58:25 PM UTC+1, ThierryIT wrote:
> Hi,
> 
> If using sys-usb, I am not able to use the cli: qvm-usb 
> How to mount it ?
> I can see on my sys-usb VM that the system see my key.
> 
> Thx
> 
> Le mardi 23 janvier 2018 14:42:18 UTC+2, Matty South a écrit :
> > On Tuesday, January 23, 2018 at 2:11:33 AM UTC-6, ThierryIT wrote:
> > > I am on R3.2 and I would like to avoid upgrading to 4.0 :)
> > > 
> > > Le mardi 23 janvier 2018 09:51:17 UTC+2, Kushal Das a écrit :
> > > > On Tue, Jan 23, 2018 at 12:17 PM, ThierryIT wrote:
> > > > > Hello,
> > > > >
> > > > > I have today to deal with two problems:
> > > > >
> > > > > 1) I am using Yubikey to be authentified on some web site like Github 
> > > > > ...
> > > > > 2) I am using Yubikey to stock my PGP keys and to use them with 
> > > > > mainly my emails (Thinderbird+Enigmail)
> > > > >
> > > > > What to do under Qubes to make this possible ?
> > > > > I have already sys-usb running.
> > > > 
> > > > On Qubes 4.0rc3, I just attach it to the vm as required, and use it.
> > > > No configuratino is required.
> > > > 
> > > > Kushal
> > > > -- 
> > > > Staff, Freedom of the Press Foundation
> > > > CPython Core Developer
> > > > Director, Python Software Foundation
> > > > https://kushaldas.in
> > 
> > I can confirm Kushal's experience. Two things I wanted to point out:
> > 1) install yubikey software in the target vm template: 
> > sudo dnf install yubioath-desktop [for Fedora template]
> > 
> > 2) I attach it to the desired VM in dom0 terminal using
> > qvm-usb -a ...
> > 
> > Then you can double-checke that everything is working here: 
> > https://demo.yubico.com/
> > 
> > Hope that helps some folks out!

Did you install the Qubes USB Proxy? You need that to use qvm-usb.

Some relevant background knowledge might be due first. For starts, sys-usb in 
and on itself adds no features, no functionality, it's specifically and purely 
a self-defense mechanism to protect dom0, nothing more, nothing less. It does 
however move all your USB to sys-usb, giving you a means to use USB the same 
way, as if it was used in dom0. 

The USB Proxy, however, does add some functionality, and it can be installed in 
whichever VM you keep your USB Controllers. Be it sys-usb or your 
wibbly-wobbly-timey-wimey VM, in other words, it doesn't matter where, as long 
as it is kept safely away from dom0. If you use USB keyboard or USB mouse, 
however, you need to be careful you don't lock yourself out of your system, 
especially if sys-usb has automatic start on boot. If USB is the only input you 
have for keyboard/mouse, then be careful of what you do, or at least make a 
backup of your system first, just in case you make a mistake. 

https://www.qubes-os.org/doc/usb/
Go here, you don't need the full guide. Just scroll (or cftl+f to search) for 
the headline containing "Qubes-USB-Proxy", it's quite a bit down the page near 
the bottom.

Once you installed the Qubes Proxy package, you can go the the next headline, 
which shows you how to use it. 

Keep in mind, you need to type this in every time you need to switch it to 
another VM, or if you stop/start your VM and need it again. This is however 
far, far easier in Qubes 4, which has a widget that allows for this with 3 
small quick clicks of your mouse. So this becomes much easier in Qubes 4, and 
it's likely not too far from final release now.

You could however make it easy in Qubes 3.2. if you use the same few VM's for 
the USB. For example you can write a small simple script, and then simply 
keybind the script with "qvm-run sys-usb bash 'path-to-your-'qvm-usb'-script".

You execute qvm-run in dom0, and you execute qvm-usb in your sys-usb (or 
whichever VM yo use). To keybind, go to Qubes menu ---> System Tools --> 
Keyboard settings --> Shortcuts tab --> Click "Add", and type in the qvm-run 
command. 

For example you can pass your Yubi-key to VM-A with Ctrl+Shift+Alt+A or your 
VM-C with Ctrl+Shift+Alt+K. Whatever you can imagine or desire, the 
Ctrl+Shift+Alt is nice because it's easy to just hold all 3 keys down without 
worring about which one to holddown, while also not causing many keybind 
conflicts.

-- 
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/dec695a9-5931-408c-84e4-ba13f9549f46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Upgrade from 3.2 to 4.0 ?

On Wednesday, January 24, 2018 at 8:49:03 AM UTC+1, ThierryIT wrote:
> Will have to wait the stable version in this case :)
> Thx
> 
> Le mercredi 24 janvier 2018 08:01:18 UTC+2, Chris Laprise a écrit :
> > On 01/24/2018 12:52 AM, ThierryIT wrote:
> > > Hi,
> > > 
> > > Is there any procedure available ?
> > > Or can I follow this one: https://www.qubes-os.org/doc/upgrade-to-r3.2/
> > > 
> > > Thx
> > > 
> > 
> > There is no procedure for in-place upgrading that I'm aware of. You'll 
> > need to backup your VMs, install 4.0, then restore the VMs.
> > 
> > -- 
> > 
> > Chris Laprise, tas...@posteo.net
> > https://github.com/tasket
> > https://twitter.com/ttaskett
> > PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

I think too much has changed to allow such an upgrade from 3.2. to 4.0. For one 
consider release 3.1. and 3.2. were similar, no big changes, just adding on-top 
the old. It's my understanding that new "versions" releases contain new 
"features", while regular updates are fixes of errors and bugs. In other words, 
3.2. upgrade added some features on-to 3.1. But Qubes 4 is much more different 
than 3.2., a lot was changed and it's not merely about adding on-top anymore. I 
don't think it's feasible to use such a method to upgrade, not without the 
developers spending extra significant time (and a lot of it) to make it work, 
and they're busy already as it is with higher priorities already as it is. 
Maybe once Qubes won't change so much between major releases, in the future, 
but not now.

Consider that I have no insider knowledge, nor am I an expert, however it's 
possible that Qubes 4 RC-4 will be the final release. I'm saying this, because 
I've used Qubes 4 since RC-2, and it's become quite stable now. To me, it seems 
like they are just polishing it off right now, making last adjustments, fixing 
the last errors, ensuring hardware compability, and so on. But as said, I have 
no insider knowledge, nor am I an expert, this is just my impression sitting on 
Qubes 4 while it improved. 

Also consider, that like between RC-2 and RC-3, no re-install were required, 
you just kept updating. However sometimes, a re-install is required. The Qubes 
developers has started telling us what they recommend on the release day of a 
RC-X version, just read the release article to find out, they started doing 
this since the last 2 RC-X releases and will likely keep doing this.

So if you install RC-3, the current one, you might not have to re-install for 
RC-4, and even then, you might not have to re-install for the final release.

I say "might not", because, odds are that they might recommend a re-install 
between RC-3 and RC-4, or a RC-5 if they extend it further, but I do think a 
RC-5 is quite unlikely considering how stale it feels now. It's also my 
understanding that the moment they can say no further re-install is required to 
fix an issue, is the moment we will stop seeing new RC-X releases, and just see 
regular qubes-dom0-update's instead.

It's up to you, to me personally Qubes 4 works just fine, I'm quite happy with 
it. But it's also true that it isn't ready for final release yet, although, it 
might be soon considering how stable it feels now. At least personally I only 
experience minor issues now a days.

- - - 

Also note, it might be a good idea to abandone your Qubes 3.2. templates on 
Qubes 4. There is no official announcement on this, but in my experience, while 
it works, it becomes sluggish and error prone. I've experienced performance 
increas too by abandoning my old AppVM's. So what I did was ignore templates 
from my backup, only restoring my AppVM's. Then I systematically made new VM's, 
and simply transfered my files from the old to the new. Once confirmed it all 
worked, I then deleted the old. Do keep in mind that re-naming qubes in Qubes 4 
is no simple matter, it will basically copy your entire VM and delete the old, 
instead of just renaming as it does it in Qubes 3.2. I do not know why, but 
there is apparently a good reason for it. Keep this in mind if you got low disk 
space, and stay patient. If you want to keep the names of your AppVM's, it 
might be a good idea to re-name them slightly with a single letter difference, 
before you backup on Qubes 3.2., so it's easier to build new VM's with the 
correct names on your new system. This way, you avoid some hassles. I don't 
know why the AppVM's seem more smooth when they are of the Qubes 4 version, 
seemingly it should not matter, however this is my anecdotal experience. Maybe 
it's been fixed too by the time you get on qubes 4, who knows.

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

Re: [qubes-users] No space left

On Tuesday, January 23, 2018 at 3:53:15 PM UTC+2, steve.coleman wrote:
> On 01/23/2018 04:55 AM, beso wrote:
> > Something is eating free space in my system. It step by step decreasing. I 
> > haven't found any good solution for that.
> > 
> 
> This command should give you a clue as to where the space is going:
> 
> $ sudo du -h / | sort  -g | tail -100
> 
> Once you know where the space is going, its just a matter of what is 
> putting it all there.

[x@dom0 /]$ sudo du -h / | sort -g | tail -100
du: `/proc/17545/task/17545/fd/4' ei saa kasutada: No such file or directory
du: `/proc/17545/task/17545/fdinfo/4' ei saa kasutada: No such file or directory
du: `/proc/17545/fd/3' ei saa kasutada: No such file or directory
du: `/proc/17545/fdinfo/3' ei saa kasutada: No such file or directory
928K/usr/lib/modules/4.9.35-20.pvops.qubes.x86_64/kernel/sound/pci/echoaudio
928K
/usr/lib/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/intersil
928K/usr/lib/modules/4.9.45-21.pvops.qubes.x86_64/kernel/sound/pci/echoaudio
928K
/usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/intersil
928K/usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/sound/pci/echoaudio
928K/usr/share/icons/Adwaita/16x16/status
928K/usr/share/icons/Adwaita/24x24/status
928K
/var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/net/wireless/intersil
928K
/var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/kernel/sound/pci/echoaudio
928K
/var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/intersil
928K
/var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/kernel/sound/pci/echoaudio
928K
/var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/intersil
928K
/var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/sound/pci/echoaudio
932K
/usr/lib/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/input/touchscreen
932K
/usr/lib/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/net/wireless/marvell
932K
/usr/lib/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/input/touchscreen
932K
/usr/lib/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/marvell
932K
/usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/input/touchscreen
932K
/var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/input/touchscreen
932K
/var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/net/wireless/marvell
932K
/var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/input/touchscreen
932K
/var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/marvell
932K
/var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/input/touchscreen
936K/usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/crypto
936K
/usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/marvell
936K
/var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/crypto
936K
/var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/marvell
940K/usr/lib64/python3.4/email
940K
/usr/lib/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/net/wireless/ath/ath9k
940K
/usr/lib/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/ath/ath9k
940K
/usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/ath/ath9k
940K
/var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/net/wireless/ath/ath9k
940K
/var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/ath/ath9k
940K
/var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/ath/ath9k
944K/usr/lib/firmware/ath6k
944K/usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/isdn/hisax
944K
/var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/build/include/media
944K
/var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/build/scripts/gcc-plugins
944K
/var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/build/include/media
944K
/var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/build/scripts/gcc-plugins
944K
/var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/build/include/media
944K
/var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/build/scripts/gcc-plugins
944K
/var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/isdn/hisax
948K

[qubes-users] [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Qubes Community,

We have just updated Qubes Security Bulletin (QSB) #37:
Information leaks due to processor speculative execution bugs.

The text of the main changes are reproduced below. For the full
text, please see the complete QSB in the qubes-secpack:

Learn about the qubes-secpack, including how to obtain, verify, and
read it:

View all past QSBs:

View XSA-254 in the XSA Tracker:

```
Changelog
==

2018-01-11: Original QSB published
2018-01-23: Updated mitigation plan to XPTI; added Xen package versions

[...]

(Proper) patching
==

## Qubes 4.0

As explained above, almost all the VMs in Qubes 4.0 are
fully-virtualized by default (specifically, they are HVMs), which
mitigates the most severe issue, Meltdown. The only PV domains in Qubes
4.0 are stub domains, which we plan to eliminate by switching to PVH
where possible. This will be done in Qubes 4.0-rc4 and also released as
a normal update for existing Qubes 4.0 installations. The only remaining
PV stub domains will be those used for VMs with PCI devices. (In the
default configuration, these are sys-net and sys-usb.) To protect those
domains, we will provide the Xen page-table isolation (XPTI) patch, as
described in the following section on Qubes 3.2.

## Qubes 3.2

Previously, we had planned to release an update for Qubes 3.2 that would
have made almost all VMs run in PVH mode by backporting support for this
mode from Qubes 4.0. However, a much less drastic option has become
available sooner than we and the Xen Security Team anticipated: what the
Xen Security Team refers to as a "stage 1" implementation of the Xen
page-table isolation (XPTI) mitigation strategy [5]. This mitigation
will make the most sensitive memory regions (including all of physical
memory mapped into Xen address space) immune to the Meltdown attack. In
addition, this mitigation will work on systems that lack VT-x support.
(By contrast, our original plan to backport PVH would have worked only
when the hardware supported VT-x or equivalent technology.)

Please note that this mitigation is expected to have a noticeable
performance impact. While there will be an option to disable the
mitigation (and thereby avoid the performance impact), doing so will
return the system to a vulnerable state.

The following packages contain the patches described above:

 - Xen packages, version 4.6.6-36

[...]

Here is an overview of the VM modes that correspond to each Qubes OS
version:

VM type \ Qubes OS version | 3.2 | 4.0-rc1-3 | 4.0-rc4 |
- -- | --- | - | --- |
Default VMs without PCI devices| PV  |HVM|   PVH   |
Default VMs with PCI devices   | PV  |HVM|   HVM   |
Stub domains - Default VMs w/o PCI | N/A |PV |   N/A   |
Stub domains - Default VMs w/ PCI  | N/A |PV |   PV|
Stub domains - HVMs| PV  |PV |   PV|

```

On 2018-01-11 08:57, Andrew David Wong wrote:
> Dear Qubes Community,
> 
> We have just published Qubes Security Bulletin (QSB) #37:
> Information leaks due to processor speculative execution bugs.
> The text of this QSB is reproduced below. This QSB and its accompanying
> signatures will always be available in the Qubes Security Pack
> (qubes-secpack).
> 
> View QSB #37 in the qubes-secpack:
> 
> 
> 
> Learn about the qubes-secpack, including how to obtain, verify, and
> read it:
> 
> 
> 
> View all past QSBs:
> 
> 
> 
> View XSA-254 in the XSA Tracker:
> 
> 
> 
> ```
>  ---===[ Qubes Security Bulletin #37 ]===---
> 
>January 11, 2018
> 
> 
> Information leaks due to processor speculative execution bugs
> 
> Summary
> 
> 
> On the night of January 3, two independent groups of researchers
> announced the results of their months-long work into abusing modern
> processors' so-called speculative mode to leak secrets from the system's
> privileged memory [1][2][3][4]. As a response, the Xen Security Team
> published Xen Security Advisory 254 [5]. The Xen Security Team did _not_
> previously share information about these problems via their (non-public)
> security pre-disclosure list, of which the Qubes Security Team is a
> member.
> 
> In the limited time we've had to analyze the issue, we've come to the
> following conclusions about the practical impact on Qubes OS users and
> possible remedies. We'll also share a plan to address the issues in a
> more systematic way in the coming weeks.
> 
> Practical impact and limiting

Re: [qubes-users] my mouse is dead

2018-01-24 Thread Alex Dubois

On Tuesday, 23 January 2018 20:34:20 UTC, Ivan Mitev  wrote:
> On 01/23/18 21:52, evo wrote:
> > Hey!
> > 
> > my mouse doesn't react, nothing happens.
> > Can somebody help please?
> 
> external mouse ? laptop's track{pad,point} ? never worked at all or 
> stopped working ?
> 
> if external mouse: restart sys-usb and/or make sure that sys-usb has the 
> qubes-input-proxy-sender rpm package installed (dom0 should have 
> qubes-input-proxy installed by default).

Mouse should not use sys-usb, this USB should be for untrusted usb devices. The 
mouse should be on a dedicated controller.

In Dom0:
lsusb
should give you the controller bound to it. The mouse (and possibly keyboard) 
needs to be attached to one of the port of that controller. The other ports 
should be bound to controllers attached to sys-usb.
But in general the keyboard and mouse are PS2 attached I think...

-- 
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/0a892b66-09c3-4c58-ab25-9fe296b442e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Please help with custom template build

2018-01-24 Thread 'awokd' via qubes-users

On Wed, January 24, 2018 7:46 am, Krišjānis Gross wrote:
> On Tuesday, 23 January 2018 17:36:00 UTC, Krišjānis Gross  wrote:

>>
>> I am running a Fedora linux and trying to build with these
>> instructions: https://www.qubes-os.org/doc/building-archlinux-template/
>>
>>
>> I use the ./setup to create the installation configuration.
>
> Yes, I did that and I think that I did it correctly. Could post more
> details if you think this could be the root cause.

Haha sorry, didn't see you were already using the same link I replied with
last time.

Maybe confirm you have the master signing key as trusted? Note the
.trustdb the builder uses isn't in the default location. Otherwise, it
might just be a Fedora glitch on the mirror you hit, try another?


-- 
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/608da2be39c38e8e4cffafb3bc4c7e27.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] No space left

On Tuesday, January 23, 2018 at 3:53:15 PM UTC+2, steve.coleman wrote:
> On 01/23/2018 04:55 AM, beso wrote:
> > Something is eating free space in my system. It step by step decreasing. I 
> > haven't found any good solution for that.
> > 
> 
> This command should give you a clue as to where the space is going:
> 
> $ sudo du -h / | sort  -g | tail -100
> 
> Once you know where the space is going, its just a matter of what is 
> putting it all there.

[x@dom0 /]$ sudo du -h / | sort -g | tail -100
du: `/proc/17545/task/17545/fd/4' ei saa kasutada: No such file or directory
du: `/proc/17545/task/17545/fdinfo/4' ei saa kasutada: No such file or directory
du: `/proc/17545/fd/3' ei saa kasutada: No such file or directory
du: `/proc/17545/fdinfo/3' ei saa kasutada: No such file or directory
928K/usr/lib/modules/4.9.35-20.pvops.qubes.x86_64/kernel/sound/pci/echoaudio
928K
/usr/lib/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/intersil
928K/usr/lib/modules/4.9.45-21.pvops.qubes.x86_64/kernel/sound/pci/echoaudio
928K
/usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/intersil
928K/usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/sound/pci/echoaudio
928K/usr/share/icons/Adwaita/16x16/status
928K/usr/share/icons/Adwaita/24x24/status
928K
/var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/net/wireless/intersil
928K
/var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/kernel/sound/pci/echoaudio
928K
/var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/intersil
928K
/var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/kernel/sound/pci/echoaudio
928K
/var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/intersil
928K
/var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/sound/pci/echoaudio
932K
/usr/lib/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/input/touchscreen
932K
/usr/lib/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/net/wireless/marvell
932K
/usr/lib/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/input/touchscreen
932K
/usr/lib/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/marvell
932K
/usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/input/touchscreen
932K
/var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/input/touchscreen
932K
/var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/net/wireless/marvell
932K
/var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/input/touchscreen
932K
/var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/marvell
932K
/var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/input/touchscreen
936K/usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/crypto
936K
/usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/marvell
936K
/var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/crypto
936K
/var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/marvell
940K/usr/lib64/python3.4/email
940K
/usr/lib/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/net/wireless/ath/ath9k
940K
/usr/lib/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/ath/ath9k
940K
/usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/ath/ath9k
940K
/var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/net/wireless/ath/ath9k
940K
/var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/ath/ath9k
940K
/var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/ath/ath9k
944K/usr/lib/firmware/ath6k
944K/usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/isdn/hisax
944K
/var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/build/include/media
944K
/var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/build/scripts/gcc-plugins
944K
/var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/build/include/media
944K
/var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/build/scripts/gcc-plugins
944K
/var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/build/include/media
944K
/var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/build/scripts/gcc-plugins
944K
/var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/isdn/hisax
948K

[qubes-users] Re: "Qubes Air: Generalizing the Qubes Architecture" by Joanna Rutkowska

2018-01-24 Thread Alex Dubois

On Wednesday, 24 January 2018 04:30:08 UTC, Syd Brisby  wrote:
> some considerations:
> 
> * Raspberry Pi, beagleboard, USB armory, etc are very low-powered devices (in 
> both CPU & RAM). So running Qubes software on them at a productive speed will 
> be a challenge.

Perfectly fine as a USB decryptionVM or as a Split PGP with the benefit of not 
have your keys in CPU cache.

> 
> * You're saying that laptop hardware specs are a problem for users. But 
> remember we had the problem of wireless modules still broadcasting after 
> being turned "off". So we needed laptops with wireless hardware switches to 
> be more certain that we couldn't be hacked. But now you are asking us to 
> again trust ordinary laptops and tablets that may not have hardware switches. 
> 
> * In reality, you are also changing from "deployment and virtualization" as a 
> single point of failure to "wireless" as the single point of failure. For 
> example, WPA2 has been declared insecure (hackable), with WPA3 being 
> necessary as a replacement. But, amazingly, WPA2 is still being "patched" by 
> manufacturers who think it's still acceptable - so how long will it take for 
> WPA3 to become ubiquitous?

On the Raspberry side, wireless is a no go. Secure wired connection will be 
required (to mitigate L2 and below attacks).

On the laptop side, sys-net will mitigate L2 and lower attacks. so your GUI 
connect to your QubesAIR by connecting to sys-firewall... nothing is changing 
(with the assumption that the protocol for remoting between Qubes is secure).

-- 
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/e467b8dd-f3c6-4633-b6c6-5bcc33bae388%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: "Qubes Air: Generalizing the Qubes Architecture" by Joanna Rutkowska

2018-01-24 Thread Tim W

On Tuesday, January 23, 2018 at 11:30:08 PM UTC-5, Syd Brisby wrote:
> some considerations:
> 
> * Raspberry Pi, beagleboard, USB armory, etc are very low-powered devices (in 
> both CPU & RAM). So running Qubes software on them at a productive speed will 
> be a challenge.
> 
> * You're saying that laptop hardware specs are a problem for users. But 
> remember we had the problem of wireless modules still broadcasting after 
> being turned "off". So we needed laptops with wireless hardware switches to 
> be more certain that we couldn't be hacked. But now you are asking us to 
> again trust ordinary laptops and tablets that may not have hardware switches. 
> 
> * In reality, you are also changing from "deployment and virtualization" as a 
> single point of failure to "wireless" as the single point of failure. For 
> example, WPA2 has been declared insecure (hackable), with WPA3 being 
> necessary as a replacement. But, amazingly, WPA2 is still being "patched" by 
> manufacturers who think it's still acceptable - so how long will it take for 
> WPA3 to become ubiquitous?

Not sure how WIFI own encryption would be a single point failure, be it WPA2 or 
not, which I fully agree was a mess from the start.  

Is it not one a fair number of reasons we all use some combo of HTTPS VPN SSH 
TOR etc?   Would anyone here connect to the net without such a combo even just 
to surf regardless of the inherent black box network security?  Regardless of 
the connection medium be it radio waves via wifi bluetooth a network patch 
cable would it really matter?  

At my house I use a pi as a radius server so I am quite happy I got my patches 
for the wpa and not just sitting for 8 months waiting to get a unproven wpa3 
rolled out.  Not to mention that if wifi upgrades match android it will take 
5-7 years before unsupported code is no longer in wide spread use.  (I also use 
separate networks for things like TV IOT etc and data I consider higher value.)

Back on the subject of Qubes Air:

I could see connecting to a Raspberry cube or USB Armory Qube etc in a separate 
Zone via coms thru a VPN proxy VM qube connection.  I think this works to 
handle the above stated PDF scenario or as even a way as a further isolation 
from a badusb infected drive containing files.  I can also see it being a way 
to expand it into a decentrailized network of managed qubes with differing 
levels of security much like our current single PC Qubes OS presently offers.

Qubes has to be removed from any specific platform such as X86 or even the 
hypervisor unless we will always be at the mercy of their security practices 
etc..  Best not to be permanently married but rather a dating relationship. The 
key would be ensuring one zone could not compromise another zone if proper 
workflow security practices are enforced/followed.  Much how we handle data 
transfers between domains/qubes of different trust/security levels i.e red vs 
black etc... IMO once a level is chosen it would nice if rules could be 
enforced to prevent data flow rather than relying on the user to remember the 
proper flow.   IMO this becomes a priority with increased domains zones qubes 
etc.. That data can only flow in the proper direction without explicit work.

Its critical to understand that what the qubes OS is today would not be what 
would necessarily be running on these other zones but it also does not dismiss 
them from running it either.   You have to remove the idea of being what the 
entire QUBES OS we have today .

Anyways I liked the thought process and vision of the writeup.

-- 
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/6702b77f-10cc-4d8b-b76a-fb2fa486f16a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes and Whonix now have next-generation Tor onion services!

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2018-01-23 09:17, Alex Dubois wrote:
> On Tuesday, 23 January 2018 07:26:09 UTC, Andrew David Wong  wrote:
> Dear Qubes Community,
> 
> The Qubes and Whonix projects now have next-generation Tor onion
> services [1] (a.k.a. "v3 onion services"), which provide several
> security improvements [2] over v2 onion services:
> 
> Qubes:
> http://sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion
> 
>> Is it https://www.qubes-os.org/ over tor? or is it to get Qubes updates?
 
At least the website, but possibly for both. Right now, you can get
Qubes updates via yum.qubesos4z6n4.onion and
deb.qubesos4z6n4.onion. It should (eventually) also work with the
next-gen onion service, but I'm not sure if it's set up yet. I asked
fortasse:

https://github.com/QubesOS/qubes-issues/issues/2576#issuecomment-360087220

> 
> Whonix:
> http://dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion
> 
> These services run alongside our existing ("v2") onion services:
> 
> Qubes:
> http://qubesos4z6n4.onion
> 
> Whonix:
> http://kk63ava6.onion
> 
> For instructions on accessing the new addresses and further details,
> please see the Whonix announcement [3]. Our sincere thanks go to the
> Whonix team, and especially fortasse, the Whonix server
> administrator, for doing this.
> 
> 
> [1] 
> https://blog.torproject.org/tors-fall-harvest-next-generation-onion-services
> [2] https://trac.torproject.org/projects/tor/wiki/doc/NextGenOnions
> [3] https://www.whonix.org/blog/whonix-new-v3-onion-address
> 
> This announcement is also available on the Qubes website:
> https://www.qubes-os.org/news/2018/01/23/qubes-whonix-next-gen-tor-onion-services/
> 

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpoX8YACgkQ203TvDlQ
MDAU0Q/+M4eG1o+mXIYBuVAzJ7aQwrM07iW78wf9ws27e+6F87abuHpiG9LbuVjV
DeaHokbss7kaUGCBSu9cIkkVpdybgWGAjqfdarkFJVojF6SSqrPSE9E3NTpfU38L
6JtqaDm8iOHD26VzVjGDC/Sz2os4f//WScmEJ04t/1KHToWGnuCHFy+KBMzybsuW
34c5i9/hzuJujiWkwQOscaYriEufMxMG1wu+nxeOKQvTZYzO79cYiFLY8XJ5Y05Q
FVkYeW5yslnTUWia0p6ms3W2PJWAn56N9DOc5CUJdhHgZmm1BTuzWvKD9dqli3mn
KJTr9gTK11jPAk9WghCxloFGKPspVQlP2gDMI28Q8BKG3p+R70Liu2prDguNiyeU
+WQh5ik0GlxKlIDsovWVUnBdCfZDTGSozBNGVAPGTARnY+O3daN4IouX0EvgO1b3
vOxaRSVUs4zKbTtFMh9/QVjYCcDHo0IVPP+sdcjR8rbouMMTGQi7eh9OHOJ1LRuj
MmKsRlOoPtOGlSjsAoIliG5N1rqDbLJ9bELyJzLpzLeuvw4Z14turpAGLm5oD1q+
NqYz80GsGh6Kc09WCXUu1IWccnRgVK87SuiQ/ILXKmIjZVZYWXAvBT4SCpmC8flM
bil9P3o38Ofvvt0FfljsNR81lEJIcUy8AUUJF4r3jcVSr5Gpccg=
=oNch
-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/fc2be2c7-adae-ea45-4533-7224aa928ea1%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Do allowing USB Keyboard expose to badusb attacks?

2018-01-24 Thread kototamo

If a USB keyboard is allowed with /etc/qubes-rpc/policy/qubes.InputKeyboard, 
does it increase the risk for badusb kind of attacks?

-- 
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/82d5f838-6efe-42a1-a68e-f3e4094421d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] whonix-?? update

2018-01-24 Thread donoban

On 01/24/2018 08:47 AM, haaber wrote:
> I was used to start templates from time to time & update them with
> apt-get. However my out-of-the-box Q4rc3 wnonix-xx systems complain
> 
> Cannot initiate connection to 127.0.0.1:8082
> 
> although I can update other appvm templates (debian, fedora) and dom0
> via sys-whonix. Do I miss something on how to update whonix-templates?
>  Cheers, Bernhard
> 

Are you using tor? Try to run whonixcheck on sys-whonix.

-- 
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/c8d527bf-2070-2a22-b617-b185223cb383%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes OS screensharing

2018-01-24 Thread Nuno Branco

I was under the impression that 4.0, by virtue of running on HVM, would
allow for native screensharing (webex, zoom, skype, etc) by simply
disabling seamless mode on the VM you want to share - is this not the case ?


On 01/24/2018 07:25 AM, Dave C wrote:
> I hope no one minds reviving an old thread...
>
> I recently needed to screenshare in Qubes (4.x, but 3.2 should work the 
> same).  I wrote up my notes:
>
> https://www.dave-cohen.com/blog/qubes-vnc-screenshare/
>
> Feedback welcome, especially if the method can be improved.  Thanks.
>

-- 

Best regards,
Nuno Branco

-- 
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/53832a2a-0ece-3239-fdca-ae795f85bacf%40mulligans.pw.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] No space left

2018-01-24 Thread donoban

On 01/24/2018 09:34 AM, beso wrote:
> On Tuesday, January 23, 2018 at 3:53:15 PM UTC+2, steve.coleman wrote:
>> On 01/23/2018 04:55 AM, beso wrote:
>>> Something is eating free space in my system. It step by step decreasing. I 
>>> haven't found any good solution for that.
>>>
>>
>> This command should give you a clue as to where the space is going:
>>
>> $ sudo du -h / | sort  -g | tail -100
>>

Try reversing the sort output:

sudo du -h / | sort  -g -r | tail -100

-- 
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/e568c045-3b08-89c3-e10c-8da86db05d8d%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] whonix-?? update

2018-01-24 Thread haaber

> On 01/24/2018 08:47 AM, haaber wrote:
>> I was used to start templates from time to time & update them with
>> apt-get. However my out-of-the-box Q4rc3 wnonix-xx systems complain
>>
>> Cannot initiate connection to 127.0.0.1:8082
>>
>> although I can update other appvm templates (debian, fedora) and dom0
>> via sys-whonix. Do I miss something on how to update whonix-templates?
>>  Cheers, Bernhard
>>
> 
> Are you using tor? Try to run whonixcheck on sys-whonix.
> 
I have the impression that template updates run by default over tor
(sys-whonix) .. otherwise the slowness could not be explained :)) My
problem disappeared either by "time has passed" and a better tor-access
or, maybe,  because I tried apt-get instead of aptitude (?). I fear I
will never know. Thank you anyhow.  Bernhard

-- 
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/c83b8d79-b1ea-0055-8c6f-a39c30b769a4%40web.de.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] qubes 4.0 hvm crashes on boot after probing EDD

2018-01-24 Thread pixel fairy

starting a standalone hvm with

qvm-start myhvm --cdrom=myappvm:/home/user/Downloads/linux.iso

the bootscreen quits just after 

Probing EDD (edd=off to disable)... ok

-- 
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/caa2c6a1-d6d7-4a10-90d0-cfe48af776b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: When creating a fresh sys-usb

2018-01-24 Thread ThierryIT

Global settings / default template ?


Le mercredi 24 janvier 2018 15:32:55 UTC+2, ThierryIT a écrit :
> Hi,
> 
> What template does it use ?
> How to make it change (from fedora to debian template) if I need to do it ?
> 
> Thx

-- 
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/287fe05e-9799-47e7-a1ab-49cddc30f534%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] When creating a fresh sys-usb

2018-01-24 Thread ThierryIT

Hi,

What template does it use ?
How to make it change (from fedora to debian template) if I need to do it ?

Thx

-- 
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/b0dbffb2-0165-4554-9c28-7dca4982a069%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How to deal with Yubikey ?

2018-01-24 Thread ThierryIT

Hi,

If using sys-usb, I am not able to use the cli: qvm-usb 
How to mount it ?
I can see on my sys-usb VM that the system see my key.

Thx

Le mardi 23 janvier 2018 14:42:18 UTC+2, Matty South a écrit :
> On Tuesday, January 23, 2018 at 2:11:33 AM UTC-6, ThierryIT wrote:
> > I am on R3.2 and I would like to avoid upgrading to 4.0 :)
> > 
> > Le mardi 23 janvier 2018 09:51:17 UTC+2, Kushal Das a écrit :
> > > On Tue, Jan 23, 2018 at 12:17 PM, ThierryIT wrote:
> > > > Hello,
> > > >
> > > > I have today to deal with two problems:
> > > >
> > > > 1) I am using Yubikey to be authentified on some web site like Github 
> > > > ...
> > > > 2) I am using Yubikey to stock my PGP keys and to use them with mainly 
> > > > my emails (Thinderbird+Enigmail)
> > > >
> > > > What to do under Qubes to make this possible ?
> > > > I have already sys-usb running.
> > > 
> > > On Qubes 4.0rc3, I just attach it to the vm as required, and use it.
> > > No configuratino is required.
> > > 
> > > Kushal
> > > -- 
> > > Staff, Freedom of the Press Foundation
> > > CPython Core Developer
> > > Director, Python Software Foundation
> > > https://kushaldas.in
> 
> I can confirm Kushal's experience. Two things I wanted to point out:
> 1) install yubikey software in the target vm template: 
> sudo dnf install yubioath-desktop [for Fedora template]
> 
> 2) I attach it to the desired VM in dom0 terminal using
> qvm-usb -a ...
> 
> Then you can double-checke that everything is working here: 
> https://demo.yubico.com/
> 
> Hope that helps some folks out!

-- 
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/4970a84c-0846-4a18-87fc-476abb1a1684%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] my mouse is dead

2018-01-24 Thread Ivan Mitev

On 01/24/18 12:06, Alex Dubois wrote:

On Tuesday, 23 January 2018 20:34:20 UTC, Ivan Mitev wrote:

On 01/23/18 21:52, evo wrote:

Hey!

my mouse doesn't react, nothing happens.
Can somebody help please?

external mouse ? laptop's track{pad,point} ? never worked at all or
stopped working ?

if external mouse: restart sys-usb and/or make sure that sys-usb has the
qubes-input-proxy-sender rpm package installed (dom0 should have
qubes-input-proxy installed by default).

Mouse should not use sys-usb, this USB should be for untrusted usb devices. The
mouse should be on a dedicated controller.

err ??

I don't see what kind of security gain you get from using your mouse on
a different controller (if you have the chance to have several ones,
that is). The worst cases would be that:

- you use your mouse to enter sensitive stuff on a virtual keyboard; but
1- the attacker has no way to know the screen location and layout of
your virtual keyboard, and 2- even if he managed to understand what you
"typed" it would be very difficult for him to get that info back because
sys-usb isn't networked.

- your compromised external mouse advertises itself as a keyboard and
issue commands on your behalf (is that even possible?). But the mouse
doesn't know which window is focused, what app you're using, etc., so
the chance that its "commands" ever do something bad to your system
without you noticing anything is close to 0.

In Dom0:
lsusb
should give you the controller bound to it. The mouse (and possibly keyboard)
needs to be attached to one of the port of that controller. The other ports
should be bound to controllers attached to sys-usb.
But in general the keyboard and mouse are PS2 attached I think...

The OP mentioned having a problem with his mouse, hence the question
about external vs. integrated. If it is integrated, then the problem is
likely not sys-usb (except if his laptop's keyb/mouse is USB but I
haven't seen this yet). If it is external, then either the mouse is
broken or something's amiss with qubes' input proxy.

--
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/ed5a837b-5b6f-be0f-dec5-adc213ab2cfb%40maa.bz.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Looking for an approach to change the borderline between /dev/xvda and /dev/xvdb