Re: [qubes-users] Release date for qube os 4

2017-12-15 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-12-15 19:14, Yuraeitha wrote:
> On Wednesday, December 13, 2017 at 2:05:30 AM UTC, Andrew David 
> Wong wrote: On 2017-12-12 17:33, grv wrote:
 I see on https://www.qubes-os.org/doc/releases/4.0/schedule/ 
 that Dec 11 is the last date mentioned to decide if rc3 is 
 final. Have we taken the decision?
 
> 
> As far as I know, the decision has not yet been made. Either way, 
> the schedule will be updated soon.
> 
 If I install rc3, would I be able to update to QubeOS 4 in 
 place (without having to migrate my VMs manually) ?
 
> 
> We'll announce this as soon as we can. We usually can't say for 
> certain whether an in-place upgrade will be possible until very 
> close to the stable release.
> 
> If we say that it'll be possible based on our current plans, and 
> those plans change, users may be inconvenienced (or worse). If we 
> refrain from changing our plans because we've already said that an 
> in-place upgrade will be possible, that limits our ability to 
> improve the final release while it's still in testing. We don't 
> want to make promises that we can't keep, but we also don't want
> to lock ourselves into a path that turns out to be sub-optimal.
> That's why we wait to announce things like this until we can be
> reasonably certain.
> 
> 
> Hey Andrew, Is there any chance if we can get recommendations, as 
> for when it is recommendable to re-install between the Qubes 
> release candidates? I.e. an extra line in the release schedule 
> saying re-install recommended, or something akin to that? I'm just 
> pondering thoughts here, whether it's possible or not.
> 
>> From what I can gather, release candidates can be seen in two 
>> ways.
> 
> - 'Updates are so major, that a re-install for the next release 
> candidate makes for a more stable and reliable system.'
> 
> or
> 
> - 'Some systems won't work properly before updates are applied, 
> therefore creating an impossible circle if booting, installing, 
> reaching the update process, is unreachable.'
> 
> When decisions are made in keeping or making a new release 
> candidate, it would be greatly appreciated to have a means to know 
> if re-install is the former, or the latter, scenario, or maybe
> even sometimes both. This would save a lot of time for many people
> to re-install, or even be worried and stressed about not doing so, 
> when not knowing if one should or not.
> 
> Is it possible we can include this tiny detail somewhere, i.e. in 
> the release schedule, or somewhere else that is a sensible
> location that is easy to find for users?
> 

We've actually already started doing that. :)

Take a look at our last two release candidate announcements:

"As a consequence of the partition layout change, it will be necessary
for current 4.0-rc1 testers to perform a clean reinstall of 4.0-rc2
rather than attempting to upgrade in-place."

https://www.qubes-os.org/news/2017/10/23/qubes-40-rc2/

"Current users of Qubes 4.0-rc2 can upgrade in-place by downloading
the latest updates from the testing repositories in both dom0 and
TemplateVMs."

https://www.qubes-os.org/news/2017/11/27/qubes-40-rc3/

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

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJaNK9ZAAoJENtN07w5UDAw0+oQAMQ8EFQNpMnRIe/yhC1o4v9G
PKta+7YsCjfawTu7oWUdbh8ETKAzqo7BGyqZeZsQzOIlgRLZo4/1C3BCLSsYjUQm
E8kYADe/8i4YGyeXU2SUeGgzSrbZGfvWdE2dMB5oc3uLp0eYB/jtKMIxNdbPRp6B
vmDvTFRgSoUNHq8hgS+p8A8VNB696xPoCx4jzWHjo7NbWubaRGRKsArCHkPjwfMW
x5Skro/DslYjSU+Bx5r61sJLZZT46bFIrqogc5pmZzcvw3M0VnjKZD2H0D5RoOrD
JKuz+2RiZZRkqzNZpS5fOxD392Y0r9D3YlcEM/1+QrMy1xfix8wdik4bDb/49Rxu
+ZgI5yZw2HpDILc2wUcF2Ph+LvS7u8J1VwwkZXdgyjL4CO2DZBO0VMiiUvDwg98Q
8WuWZDPfkgFE8fsNiStiQwFtqOE/hCvAhJ6qE4pJMujMdbm1mjQJErQH1LCAE9pV
cz2fLHWlPzWp06PqNV9zRFHA4twQUat0IDTd2wikPDG30HzjcE+WVengoKo8iTCs
/EvbfmY6MabDMkisC+y7zgQkZeGIGFTdjvG1SG6asYdklrNvGHfJkOlQw376Fkda
a0+aC3A2qy8pgbh6vC8voTkpuzd7+H/gXET2kyzGdzA9tWKhpqXHtP0RWUpQ7EXC
1gzCPMVIykmTkIUsK3TL
=VA2a
-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/647f7ef0-8ef1-4f35-89df-a978dbfe81c4%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] qubes won't boot, how to rescue system or save my data?

2017-12-15 Thread jerry56
i first tried setup for my printer which has USB connected to PC...
using the guide in Using and Managing USB Devices in qubes-os website in docs..
enabled sys-sub using the command
sudo qubesctl top.enable qvm.sys-usb

then the command
sudo qubesctl state.highstate

computer froze, restarted pc, the keyboard didn't work (in passphrase 
encryption part), but if press a button only num lock color appears for a 
second, and if i hold a button the num lock button is lighted..

i then tried installing new qubes, using manual partition configuration (not 
the automatic), i think i didn't delete the partition with my data.. i tried 
adding some new partitions..

now after installing qubes, after encryption password for disk, entering 
password, it was counting number when clicking alt tab, and says unlimited...

how can i rescue

-- 
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/20171214211617.9C0254E2F34%40mta-1.openmailbox.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Trying to get my head around a configuration for a VPN-Proxy VM and its firewall?

2017-12-15 Thread velcro
I have scenario #1 working...I checked DNS leak and was able to get different 
results depending on the VM I was on. Is this just likely to break due to the 
bug you reference?


Scenario 2 was supposed to depict 3 separate sys-net, not running at the same 
time. clarified as follows:

Clarrified Scenario #2
a) VMa--sys-vpn--sys-firewall---sys-net(Wireless and ethernet)
b) VMb---sys-firewall---sys-net(Wireless and ethernet)
c) VMc---sys-firewall---sys-net(Wireless and ethernet)

If I want to get on VMa(VPN)...I would need to close all VMs in b) and c), if I 
wanted to get on VMb, I would need to close all VMs in a) and c), etc...pain in 
the but! But is this more secure due to multiple seperated sys-net? 



Scenario #3 clarified
a) VMa--sys-vpn-sys-net(Wireless and ethernet)
b) VMb--sys-firewallsys-net(Ethernet only)
c) VMc--sys-firewallsys-net(Wireless only)

#3 Scenario is insipired by this post(multiple sys-net's):
Multiple sys-net:
http://theinvisiblethings.blogspot.com/2011/09/playing-with-qubes-networking-for-fun.html

...is the only benefit of this configuration that I can use VMb and VMc at the 
same time? or is there better isolation with this config having multiple 
sys-net's? This assumes all VMs in a) and b) would need to be closed to get on 
VMa(VPN)


Regarding the firewall rules in sys-vpn:

Unfortunately (or fortunately?) my VPN provides a domain name instead of IPs 
e.g. VPNprovider.Canada.com, the VPN provider requires port 1194(UDP only), 
with user name/password and a local cert(all set up in the OpenVPN client in 
sys-vpn). 

In the sys-vpn VM firewall, I would "allow DNS queries" and "deny network 
access except": 1) put a rule that allows "*"(Which I believe allows "Any" 
domain/IP to pass, although it is limited to VPNprovider.Canada.com i.e. the 
Gateway in OpenVPN client )for "address", 2) port 1195 for "service" and 3) a 
protocol of "UDP". Wouldn't this block port 80, 443 and all other ports and 
only allow VPNprovider.Canada.com on port 1195 via UDP only? Therefor if VPN 
goes down all other ports 80, 443 would not be allowed? i.e. a kill 
switch?...similar to whats on the Qubes instructions except GUI configured?

Similar to this post:
https://github.com/Rudd-O/qubes-vpn

Specifically:
Firewall your VPN VM

Open the Firewall rules tab of your new VPN VM's preferences page.

Deny network access except for Allow DNS queries. If the VPN server is just an 
IP address (check the configuration given you by the VPN provider) then you do 
not have to Allow DNS queries at all.

Add a single rule:

Address: either * (all hosts) as address (use this when you do not know the 
IP address of the VPN server in advance, and all you have is a DNS host name), 
or the fixed VPN IP address (if your VPN configuration has a fixed IP address).
Protocol: choose the protocol that your VPN server configuration indicates 
(TCP or UDP).
Port number: type in the port number of your VPN server (with OpenVPN, it's 
typically 1194, 5000 or 443, but refer to your VPN configuration).


Thanks for the thoughts...I know there are multiple questions here that are 
difficult for me to articulate.

-- 
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/fbb5a97f-5693-479e-914a-8a75cf5f64ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Installation Issues on Asus Zenbook UX303 - both 3.2 and 4.0 halting during first-run VM creation

2017-12-15 Thread Yuraeitha
On Friday, December 15, 2017 at 1:54:23 PM UTC, callu...@gmail.com wrote:
> Dear qubes-users,
> 
> I've been trying to get a version of Qubes running on an Asus Zenbook UX303 
> (albeit by installing to a large USB 3 stick). 
> 
> Having DD'd the latest image (after verification) to an installation stick 
> using the latest Rufus the installer boots, recognises the target stick and 
> appears to install successfully using default settings and automatic 
> partition scheme. 
> 
> The target stick then boots successfully and proceeds to 1st-time setup and 
> VM creation, but hangs at a seemingly random point during this process (the 
> panning progress bar freezes indefinitely). 
> 
> I've tested with both 3.2 and 4.0, with the network card enabled and 
> disabled, and with and without default VM creation.
> 
> The UX303 seems to be in a solid position in the HCL, so I'm wondering 
> whether I'm making a rookie error somewhere or whether it's that I'm 
> targeting a stick rather than the internal SSD that's causing the freezes 
> (such as the USB going to sleep midway).
> 
> Any advice would be greatly appreciated.
> 
> Callum

The overall topic from this quote is different, but there is however a small 
part that is relate-able.
Quote: "So, I installed Qubes 3.2 RC1 on a USB stick instead of the nvme hd, 
and it does not work if I try and boot from the USB stick option. If I boot 
from the Qubes UEFI option, it boots from the USB stick card.

The only change I made since then was turning on Intel TXT in the firmware 
option." /quote

Source: 
https://www.reddit.com/r/Qubes/comments/4onsfe/qubes_os_32_rc1_has_been_released/

Seemingly settings like wannabe Intel security features like TXT, and the EFI 
boot method, might possibly be other factors worth looking further into, in 
regard to your BIOS settings and search-engine topics to search on for further 
information (albeit it can be a jungle).

My point is, there is a lot of things that can affect your Qubes install, in 
your BIOS. Try go through them all systematically, and eventually you might 
have good chances finding the culprit.

-- 
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/a2c819a7-e03b-4eb6-b6eb-9d72ebc250c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Installation Issues on Asus Zenbook UX303 - both 3.2 and 4.0 halting during first-run VM creation

2017-12-15 Thread Yuraeitha
On Friday, December 15, 2017 at 1:54:23 PM UTC, callu...@gmail.com wrote:
> Dear qubes-users,
> 
> I've been trying to get a version of Qubes running on an Asus Zenbook UX303 
> (albeit by installing to a large USB 3 stick). 
> 
> Having DD'd the latest image (after verification) to an installation stick 
> using the latest Rufus the installer boots, recognises the target stick and 
> appears to install successfully using default settings and automatic 
> partition scheme. 
> 
> The target stick then boots successfully and proceeds to 1st-time setup and 
> VM creation, but hangs at a seemingly random point during this process (the 
> panning progress bar freezes indefinitely). 
> 
> I've tested with both 3.2 and 4.0, with the network card enabled and 
> disabled, and with and without default VM creation.
> 
> The UX303 seems to be in a solid position in the HCL, so I'm wondering 
> whether I'm making a rookie error somewhere or whether it's that I'm 
> targeting a stick rather than the internal SSD that's causing the freezes 
> (such as the USB going to sleep midway).
> 
> Any advice would be greatly appreciated.
> 
> Callum

oh btw, a warning, fedora 23, which Qubes 3.2. is based on, apparently has a 
bug that can mess up other partitions, even if you did not flag them for change 
during install. If you install Qubes 3.2. (which has fedora 23 as dom0 and is 
base for the installer itself), then you might mess up other partitions. Be 
sure to disconnect those drives if you install Qubes 3.2., just in case the bug 
will hit you. 

I never experienced the bug my self, but I've heard about it.
I'm unsure if it's gone in Qubes 4, which is based on Fedora 25, however 
presumably it should be gone. You can search after it in the Fedora community, 
since Qubes does not fix issues that belongs to upstream developers like 
Fedora, as it would needlessly complicate everything and waste resources. But 
just keep this in mind. I assume you install on an USB pen to avoid loosing 
your current drive data, so this now older issue is presumably important to be 
aware of. 

-- 
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/3d5e6d90-eaff-41c1-96a3-80317449c9e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Installation Issues on Asus Zenbook UX303 - both 3.2 and 4.0 halting during first-run VM creation

2017-12-15 Thread Yuraeitha
On Friday, December 15, 2017 at 1:54:23 PM UTC, callu...@gmail.com wrote:
> Dear qubes-users,
> 
> I've been trying to get a version of Qubes running on an Asus Zenbook UX303 
> (albeit by installing to a large USB 3 stick). 
> 
> Having DD'd the latest image (after verification) to an installation stick 
> using the latest Rufus the installer boots, recognises the target stick and 
> appears to install successfully using default settings and automatic 
> partition scheme. 
> 
> The target stick then boots successfully and proceeds to 1st-time setup and 
> VM creation, but hangs at a seemingly random point during this process (the 
> panning progress bar freezes indefinitely). 
> 
> I've tested with both 3.2 and 4.0, with the network card enabled and 
> disabled, and with and without default VM creation.
> 
> The UX303 seems to be in a solid position in the HCL, so I'm wondering 
> whether I'm making a rookie error somewhere or whether it's that I'm 
> targeting a stick rather than the internal SSD that's causing the freezes 
> (such as the USB going to sleep midway).
> 
> Any advice would be greatly appreciated.
> 
> Callum

Well I successfully installed Qubes 4 RC-1 on a USB pen once, some months back 
when the first candidate was released. I only messed around for a few minutes, 
but despite the bugs and errors a first release has, it seemed to work 
somewhat. 

I'd rather try look elsewhere for a possible explanation first, for one, did 
you make sure to check all your BIOS settings? 
- Intel VT-d or AMD-Vi, enabled? (Default is typically disabled out of box).
- Made sure there is no extra setting for Virtualisation? Some BIOS's have one.
- Did you try remove hardware, or settings, which can be temporarily removed, 
and see if it fixes anything? I.e. use onboard graphics instead of graphic 
card. Try install, see if it works. Remove PCI cards, turn off unessential BIOS 
settings that might trigger driver issues (but don't change without knowing 
what you're doing, of course, as it can be dangerous and break the machine, but 
you probably know that already?). 
- It can also be something that needs to be turned on, sometimes it can be 
something unexpected, i.e. an otherwise unrelated BIOS setting that does not 
play nice with virtualization during a system install, unless its turned on, or 
off. 
- It can also make a difference if you install via EFI (granted without 
secureboot since Qubes currently has no key), or via LegacyBIOS boot and grub. 
Essentially, in my anecdotal experience it tends to work more times than not, 
by using legacy, in terms of driver issues and freezes.
- As you suggested yourself, you might also have to try install on an actual 
harddrive, in case it really is the install location on an USB pen that is 
causing the issues. But in my optics this issue is somewhat lower on the list 
of suspects, however, I'm not an expert either.

The fact that both 3.2. and 4 freezes, makes it seem like that there is 
something wrong with the hardware features, or BIOS settings. Did you at any 
previous time successfully install any other Linux on the machine? The kernel 
worked fine?

-- 
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/ecf2c4f4-9965-4478-b814-8805a6ce6e7e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] GPU Passthrough Status - (Purely a meta-discussion, no specifics)

2017-12-15 Thread Yuraeitha
Aight, so the idea of this thread, is to get an overview of where we stand, 
that is, how far are we away from archiving GPU Passthrough on Qubes. 

The underlying reason it's currently not working, appears to be because of its 
current state a virtual GPU for a specific VM, would require direct access to 
dom0. This is deemed a serious security threat breaking a central pillar of 
what Qubes is all about, attempting to isolate dom0 as far as possibly 
possible. Therefore, from what I can gather, what we need is virtual GPU 
operating from an underlying DomU stub-domain, preferably, one separated from 
another DomU stub-domain, which holds the important and critical VM data and 
user operations. Thereby it's not only about single virtualization anymore, but 
also about group segmenting and isolating entire virtual stub-domains. That 
means, one group of VM's is isolated from another group of VM's. Please correct 
me if I'm wrong here, it's great for the discussion to have the most accurate 
information.

Here is a scenario that stresses the above, 
https://groups.google.com/forum/#!topic/qubes-users/cmPRMOkxkdA
Managing to make GPU passthrough work, but only by passing it directly to Xen, 
instead of Libvirt, which in turn, exposes dom0.

Initially, this is all the reasons I can think of for wanting V-GPU. 
- Heavy graphic designer job or hobby (movies, animations, etc.).
- Running Qubes on many screens at desk. 
- Extending a single Qubes machine around the house or company, using multiple 
of screens, keyboards/mouses or other thinkable means.
- Gamers who take security and privacy seriously (there is surprisingly many of 
them out there).
- Cryptocoin miners who wish to utilize a single machine for all round purposes.
- Using a qube as a streaming TV, and want good graphics for the specific 
TV-VM. For example 4k or even 8k+ or more on multiple tied screens.

Some of these are exotic and probably not many around use them, however, others 
are quite common. Whichever the case, it's all scenarios with a common problem. 
The point here, is to underpin the possible use-cases.



I must be tired, I initially wrote 'qubestions' instead of 'questions' here... 
aight, so possible questions for the discussion.

- What would it take for Qubes to obtain stubdomains in a feasible means to 
allow safe GPU Passthrough? 
- Are there other problems that needs solving too? If so, which ones? 
- What is the grand big picture status between the above two questions? 
- Are there currently any plans for any of these required implementations? For 
example Qubes stub-domains in Qubes 4.1? Qubes 5? or are they still unplanned? 
If planned, or in part planned, like only halfway there, then, what are these 
plans? Please elaborate. 
- Other possible questions you can think of. 


I'm sure there are aspects I did not think of, but that's fine, after all, this 
is a discussion. This initial post is just to kick it off. The purpose is to 
combine information that a few selected individuals might be sitting on, with 
the many users who do not know about the current state. Thereby, building 
community awareness of the current situation. Whatever you got to say, or ask, 
about GPU Passthrough, this thread can be used for that! The only limitation, 
is that it is a discussion, and not a place to ask how to get your own specific 
case of GPU Passthrough to work. It's a general, meta discussion. 

What is your thoughts on the matter?

-- 
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/2dad5415-fd4b-42f7-b6cb-ad0094cfca07%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: HCL - Thinkpad X1 Carbon 5th gen - Qubes 4.0-rc3

2017-12-15 Thread Marek Marczykowski-Górecki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Dec 16, 2017 at 01:54:09AM +0100, Marek Marczykowski-Górecki wrote:
> Hi,
> 
> I have some initial comments about Qubes 4.0rc3 on Lenovo Thinkpad X1
> Carbon 5th gen. I'll dig further into issues listed below. But for now I
> wouldn't call it "works out of the box", unfortunately :/
> 
>  - EFI installer do not boot - gets back into grub instantly, /noexitboot
>/mapbs do not help
>  - legacy mode install works fine (although I've noticed small graphics
>glithes once or twice)
>  - at next boot grub is horribly slow (you can see drawing each char)
>  - system starts with default kernel (4.9.56)
>  - trackpoint/touchpad do not work:
>  
>  psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
>  psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
>  psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
>  psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
>  psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
>  psmouse serio1: issuing reconnect request
>  psmouse serio1: synaptics: queried max coordinates: x [..5678], y 
> [..4758]
>  psmouse serio1: synaptics: queried min coordinates: x [1266..], y 
> [1094..]

Fixed by adding psmouse.synaptics_intertouch=1 dom0 kernel parameter
(available in 4.14+).

>  
>  - suspend: hang on suspend (green light flash quickly)
> 
> Next step: upgrade dom0 (only!) kernel to 4.14.6
> (https://github.com/QubesOS/qubes-linux-kernel/pull/13). You need to
> build it yourself, there is no
> binary package available, yet. 
> 
> Then add iwlmvm and iwlwifi to /rw/config/suspend-module-backlist in sys-net
> 
>  - this fixed suspend issue, wireless also works after suspend
>  - touchpad/trackpoint still do not work
> 
> Other issues:
>  - https://github.com/QubesOS/qubes-issues/issues/3108
> 
> 
> Untested:
>  - mic
>  - camera
>  - ethernet
>  - thunderbolt (and do not plan to)
>  - WiGig (does it even have Linux support?)
>  - bluetooth
>  - NFC
>  - fingerprint reader (do not plan to test)
> 
> Attached hardware info.
> 





- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJaL3qDAAoJENuP0xzK19csKzYH/iu1x869BqLeOkf2tthetBaK
njaKZb9SfP8QvX8XUPZcVOwCOldFuHjzGGf+zrCM3IRtsUKf3Ry6suKH7YRrmP2a
qUScHkusfDePDH47XpFnKvE2vRINCbd6j709dttr/GZtAHTKx8J6B6ZDuQl1YkSH
gqyQkW0FDtC3jEEQnAyh5249OwJjxW56EM/WvlVOqykBkx7GkmTPGk5PSVB76i+b
W3QFlj+XEmryMSbp51Nzzb1yuK7nkMiKcZBC74bg+/jOjipH/j4vphAnzMzZ/5MK
wi3vXzjf4G+M+IrsGbSOerURadQMsQTiEwVaeydquQOc7Op72vD5LsvoJUhOu8U=
=aCgK
-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/20171216015712.GD1062%40mail-itl.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: windows 10 sound

2017-12-15 Thread Yuraeitha
On Wednesday, December 13, 2017 at 1:37:44 PM UTC, Nuno Branco wrote:
> Hi all,
> 
> I know this is already a problem on win7 HVMs  not having sound by
> default and I guess win10 will be even worse due to lack of tools but
> just wondering if anyone on the list got win10 to work with audio?
> 
> I attempted to pass trough the PCI sound card but not only that did not
> work it destroyed the ethernet connection on the WinBox. Has anyone
> tried some cheap USB sound card with better results?
> 
> -- 
> 
> Best regards,
> Nuno Branco

I once bought a cheap USB sound card, like dirt cheap, for Win7 in Qubes 3.2, 
however I passed an entire USB controller to said Win AppVM. 

I assume, the same should work for Win10, without relying on any Qubes tools as 
such (Since there is none for Win10). If it fails with an entire passthrough of 
the USB controller, then either 
1) the USB controller is not playing nice with passtrough technology, or; 
2) the there are issues in the passthrough mechanism (Qubes/Xen). I believe, 
mostly, it's the USB controller causes issues, however early Qubes 4 for 
example, had such issues as in part 2) here. 
3) something else important is relying on your USB controller, in your case, 
it's probably your network card, which is wired over an internal USB 
controller. If you pass that USB controller, you loose networking. Do a "lspci 
-t" in your dom0 terminal. Open another dom0 terminal, and write "lspci". Now 
compare both informations, and get an overview. Is your network card tied to 
your USB controller? or perhaps you even got more USB controllers? (would be an 
unexpected but pleasant surprise if so).

However, maybe you don't need to pass the entire USB controller, and instead 
can just pass the sound card with the Qubes virtual passthrough utilities. I'm 
frankly unaware if this would work for a sound card, but it never hurts to try. 
They're quire cheap as you said yourself too, maybe give it a shot and try?

-- 
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/62fa4ed3-1d3d-424b-9dda-26857f87e553%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Crossover (Office 2016) and Qubes 4rc3

2017-12-15 Thread Yuraeitha
On Tuesday, December 12, 2017 at 1:47:06 AM UTC, [799] wrote:
> Hello,
> 
> As you might have heard a new version of Crossover for Linux has been 
> released.
> 
> With Crossover it is possible to run Windows Apps on top of Linux.
> Crossover is based on Wine but has enhancement which are implemented by 
> Codeweavers.
> 
> Warning: while it is based on wine, crossovers comes with a price which is on 
> per-year base., Which is ok for me, as having office running under Qubes 
> would offer a great productivity improvement.
> 
> Has someone tried to run latest version of Crossover in Qubes.
> 
> I'd like to use Crossover to run Office in a Fedora based AppVM.
> 
> [799]

I once was a hardcore lock-in'ed on MS-Office products too, but at one point, I 
decided to write a major paper entirely on LibreOffice. I learned a great deal 
in the process. Putting it short, you can get past your MS-product addiction, 
if you push through it. 

However, it's true some aspects of the MS-products still prevail, for example 
the difference between Calc and Excel, is a massive headache, considering how 
much each of them can do, and do in such a different way.

But if you don't use Excel, then I don't see much reason to stick with 
MS-products, or perhaps, you got some reason I overlooked?

I once fancied the aesthetics of MS-Office (and I still do), but after growing 
used to LibreOffice, I don't care much anymore. The aesthetics are still nice 
and all, but it's just not as important as it was before. 

Perhaps you can use some of these thoughts, or perhaps you got valid reasons, 
whichever is the case, I hope you find your sweet-spot. 

-- 
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/db9e0ef2-c09b-4cd7-855d-0cadf962bf14%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Dumping BIOS

2017-12-15 Thread taii...@gmx.com

On 12/15/2017 12:54 PM, Matteo wrote:


I disagree when you say nooone is going to backdoor your bios.   I think its 
very common nowadays.
Actually no it isn't - unless you have managed to ruffle the feathers of 
a state actor such as the FSB or MSS.


I have never heard of a real proven BIOS hack of anyone even a serious 
military intelligence target let alone a common law abiding citizen who 
simply managed to piss off some guy in a chat-room or what not, I am 
sure it has been done many times but despite being active in the 
firmware modification community I haven't heard about it.

as far as i know there is computrace that is an anti theft system that
gain persistence over the os by dropping an exe that windows will load
at boot time but this works only over fat32 and ntfs (not encrypted).
i heard also about lenovo doing the same thing for ads or whatever. and
after people got angry they released a bios patch to opt-out.
but i wouldn't say "very common".
Computrace uses a windows utility to do this not direct code injection 
so using linux or simply disabling it in your vendor BIOS would solve 
the issue of an out-dated problematic exe being forcibly loaded.


If you wish for better security you can use a coreboot board with open 
source silicon init (not purism, get the libre RYF kcma-d8 or the lenovo 
g505s laptop for instance) otherwise while you can use an external flash 
clip to read back the BIOS and make sure it hasn't been modified you 
still would be vulnerable to manufacturer security problems, ME etc.


--
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/ba5da426-2d01-a6d6-1cd3-c3c863af9bc0%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Release date for qube os 4

2017-12-15 Thread Yuraeitha
On Wednesday, December 13, 2017 at 2:05:30 AM UTC, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2017-12-12 17:33, grv wrote:
> > I see on https://www.qubes-os.org/doc/releases/4.0/schedule/ that
> > Dec 11 is the last date mentioned to decide if rc3 is final. Have
> > we taken the decision?
> > 
> 
> As far as I know, the decision has not yet been made. Either way, the
> schedule will be updated soon.
> 
> > If I install rc3, would I be able to update to QubeOS 4 in place
> > (without having to migrate my VMs manually) ?
> > 
> 
> We'll announce this as soon as we can. We usually can't say
> for certain whether an in-place upgrade will be possible until very
> close to the stable release.
> 
> If we say that it'll be possible based on our current plans, and those
> plans change, users may be inconvenienced (or worse). If we refrain
> from changing our plans because we've already said that an in-place
> upgrade will be possible, that limits our ability to improve the final
> release while it's still in testing. We don't want to make promises
> that we can't keep, but we also don't want to lock ourselves into a
> path that turns out to be sub-optimal. That's why we wait to announce
> things like this until we can be reasonably certain.
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIcBAEBCgAGBQJaMIrWAAoJENtN07w5UDAwFb0P/jXEX9uR9gRG4epXtm0MD6Nb
> VRfFclrqa/stuPlRkqnI3Ny/l8nDzltw3SX3RH9Ju9c2mK78XVKBGabw9VQbnLCP
> lqKAVn2rcEZsMorKhUjjuwIsQjE6WJ9/OwrofTGjBLGlURNy2MvtChxe70u1XMw8
> PlTrmA4JgS3lBLLP7LLNi71WyQ2HZNZaI/k9yJ1v7LdCwyikVyhBnh3P3dc/YlZi
> I9i4k/h2W8rDcBuTG3/S+MntMkAMypGpdqDwWEQCtR+JSsV1x5qT8gc6/WVPOhVs
> A1I7qBLT2F5GjZg5ZUCTKdXIOu1FVM1pYsuYuTrLx5XbVvXVCWWEjC/DqQLEul77
> zUzZQDqkm/NfV7L8i3/CP1rlzG8PKPpzV4bM0ERsP5vrmOybyeKIu6rwoJzPPnLB
> 8Ci2VOKG/I3/Ywf29GIl4uDydyBd5jHJYK5vxllGdNPwiBsQGPkRe4CSdp7QG2eO
> o1ukxocmNSdKHgzs98ry1AvDPrbVKo62zRc+Q11W6B7/P0f4u5qIK5cVnVhk6jb2
> N/tgx2y4wMRJb2u3fF0t/YRci3qtA9GyaC1mxF9UOCYY+lalOxrT/tyhgd8p6mgu
> 6f6X6pjgli+kbwCOszy1N1t5xrHyUY/KmDvEb4HkyrLu2Ut1y8IM+mS4nk0NygvR
> temARax0ky3Duiw/Cg3C
> =fZMg
> -END PGP SIGNATURE-

Hey Andrew,
Is there any chance if we can get recommendations, as for when it is 
recommendable to re-install between the Qubes release candidates? I.e. an extra 
line in the release schedule saying re-install recommended, or something akin 
to that? I'm just pondering thoughts here, whether it's possible or not.

>From what I can gather, release candidates can be seen in two ways. 

- 'Updates are so major, that a re-install for the next release candidate makes 
for a more stable and reliable system.'

or

- 'Some systems won't work properly before updates are applied, therefore 
creating an impossible circle if booting, installing, reaching the update 
process, is unreachable.'

When decisions are made in keeping or making a new release candidate, it would 
be greatly appreciated to have a means to know if re-install is the former, or 
the latter, scenario, or maybe even sometimes both. This would save a lot of 
time for many people to re-install, or even be worried and stressed about not 
doing so, when not knowing if one should or not.

Is it possible we can include this tiny detail somewhere, i.e. in the release 
schedule, or somewhere else that is a sensible location that is easy to find 
for users?

-- 
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/b9c6b28b-e72f-41fb-b0cd-1eaf2ab96156%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: how to use "Rescue a Qubes system" or save my data, won't boot

2017-12-15 Thread Yuraeitha
On Friday, December 15, 2017 at 5:08:55 PM UTC, jer...@disroot.org wrote:
> I first used a konsole, using the guide on qubes's site "Using and Managing 
> USB Devices"
> 1. Enable sys-usb
> 
> using the command sudo qubesctl top.enable qvm.sys-usb
> 2. Apply the configuration:
> using the command sudo qubesctl state.highstate
> 
> then it froze, restarted system, and when in passphrase entering the 
> encryption code, keyboard didn't work, but when i press a button it 
> highlights the num button, and if i hold any button on keyboard the num 
> highlight is turned on, when i release the light is off...
> 
> i reinstalled qubes choosing manual partition (not the automatic), i'm 
> un-sure if i deleted or damaged my data.. (see note below)
> now it still doesn't boot qubes, keyboard works on passphrase encryption of 
> disk, but when it's loaded, it gets stuck, if i click alt+tab it counts some 
> numbers and says unlimited.
> 
> note: i still think i have the data, maybe, i have something like 
> luks-23232-f-sdf-saf-sad-sa-ds and also dom0-root-00 something (not accurate 
> name)

I believe a solution now that you already semi-reinstalled once, could be to go 
in and manually retrieve your VM's from a live media boot (if you didn't 
already delete them), i.e. using any other Linux live distribution. Salvage 
your '/var/lib/qubes/' folder, where all your VM data resides. I.e. copy it to 
another drive. 

But preferably another disconnectable drive or external drive, just in case the 
fedora bug that affects other partitions during install is still there in 
fedora 25 for Qubes 4 (I'm not sure if it is, I know it's present in fedora 23 
which Qubes 3.2 is based on). 

basically, make a fresh install after salvage, and then drag and drop the 
specific VM content img files, in new fresh created VM's for the specific 
purpose, overwriting the new empty img files with your old ones. Then it 
"should" work. Mind you, "should", as in, I believe so, but not certain.

Finally, you might want confirmation from someone who actually did this before, 
or someone who knows the system better than me. This is what I would do as a 
last resort, last ditch attempt to save my data, if I were in a situation that 
I could not recover from. I have not done it before my self, so I cannot 
confirm if it works. But hypothetically, it should. 

-- 
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/f4b48b06-175c-45d9-b24b-cc50849b71ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] HCL - Thinkpad X1 Carbon 5th gen - Qubes 4.0-rc3

2017-12-15 Thread Marek Marczykowski-Górecki
Hi,

I have some initial comments about Qubes 4.0rc3 on Lenovo Thinkpad X1
Carbon 5th gen. I'll dig further into issues listed below. But for now I
wouldn't call it "works out of the box", unfortunately :/

 - EFI installer do not boot - gets back into grub instantly, /noexitboot
   /mapbs do not help
 - legacy mode install works fine (although I've noticed small graphics
   glithes once or twice)
 - at next boot grub is horribly slow (you can see drawing each char)
 - system starts with default kernel (4.9.56)
 - trackpoint/touchpad do not work:
 
 psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
 psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
 psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
 psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
 psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
 psmouse serio1: issuing reconnect request
 psmouse serio1: synaptics: queried max coordinates: x [..5678], y [..4758]
 psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1094..]
 
 - suspend: hang on suspend (green light flash quickly)

Next step: upgrade dom0 (only!) kernel to 4.14.6
(https://github.com/QubesOS/qubes-linux-kernel/pull/13). You need to
build it yourself, there is no
binary package available, yet. 

Then add iwlmvm and iwlwifi to /rw/config/suspend-module-backlist in sys-net

 - this fixed suspend issue, wireless also works after suspend
 - touchpad/trackpoint still do not work

Other issues:
 - https://github.com/QubesOS/qubes-issues/issues/3108


Untested:
 - mic
 - camera
 - ethernet
 - thunderbolt (and do not plan to)
 - WiGig (does it even have Linux support?)
 - bluetooth
 - NFC
 - fingerprint reader (do not plan to test)

Attached hardware info.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

-- 
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/20171216005409.GH1935%40mail-itl.
For more options, visit https://groups.google.com/d/optout.
---
layout:
  'hcl'
type:
  'notebook'
hvm:
  'yes'
iommu:
  'yes'
slat:
  'yes'
tpm:
  'unknown'
remap:
  'yes'
brand: |
  LENOVO
model: |
  20HRS11400
bios: |
  N1MET37W (1.22 )
cpu: |
  Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz
cpu-short: |
  FIXME
chipset: |
  Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM 
Registers [8086:5904] (rev 02)
chipset-short: |
  FIXME
gpu: |
  Intel Corporation HD Graphics 620 [8086:5916] (rev 02) (prog-if 00 [VGA 
controller])
gpu-short: |
  FIXME
network: |
  Intel Corporation Ethernet Connection (4) I219-LM (rev 21)
  Intel Corporation Wireless 8265 / 8275 (rev 88)
memory: |
  15897
scsi: |

usb: |
  1
versions:

- works:
'FIXME:yes|no|partial'
  qubes: |
R4.0
  xen: |
4.8.2
  kernel: |
4.14.6-1
  remark: |
FIXME
  credit: |
FIXAUTHOR
  link: |
FIXLINK

---



signature.asc
Description: PGP signature


[qubes-users] Re: test, can u see this post?

2017-12-15 Thread Yuraeitha
On Friday, December 15, 2017 at 4:54:34 PM UTC, jer...@disroot.org wrote:
> ...

You might want to delete your post after confirming (and thereby this thread), 
so you help keeping the mail thread list cleaner.

-- 
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/59b1373b-8821-4f9d-80cf-c46fcfda7809%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Trying to get my head around a configuration for a VPN-Proxy VM and its firewall?

2017-12-15 Thread Chris Laprise

On 12/15/2017 05:58 PM, vel...@tutamail.com wrote:

Scenario #1
VM---sys-vpn\
 \
  \
VM-\sys-firewall---sys-net
   /
  /
VM---/



Scenario #2
VM--sys-vpn--sys-firewall---sys-net(Wireless and ethernet)
VM---sys-firewall---sys-net(Wireless and ethernet)
VM---sys-firewall---sys-net(Wireless and ethernet)



Scenario #3
VM--sys-vpn-sys-net(Wireless and ethernet)
VM--sys-firewallsys-net(Ethernet only)
VM--sys-firewallsys-net(Wireless only)


I am looking at configuring a VPN for 3.2 and I am trying to find the best 
configuration and firewall settings balancing usability, flexibility and 
security. My questions are:

1) If sys-net is not trustworthy do these scenarios matter from a security 
perspective regarding sys-net? Scenario #1 I assume consumes the least 
resources...


Number 3 doesn't look like a Qubes configuration as far as sys-net goes; 
that is assuming those lines denote parallel/simultaneous access.


The first two are essentially the same, though I'm not sure why #1 is 
just 'sys-net' while #2 shows sys-net with wifi & ethernet.




2) Regarding sys-vpn firewall...do these setting in effect create a kill switch 
in my firewall?(I only have a URL, not the IPs):
Address= *
Service= I enter the port number from my VPN provider
Protocol= I enter UDP or TCP depending on my VPN providers instructions?


There are two ingredients here you may not be aware of:

1. The Qubes VPN howto doc has a leak-prevention feature. This 
configuration can route packets only over the VPN tunnel.


2. Most subscription VPNs distribute validation certificates with their 
config files. Using a certificate, VPN software will reject connections 
with any impostor site.


So, as to the need for preventing the VPN VM from connecting with 
anything other than the VPN provider, a firewall setting shouldn't be 
necessary with a properly setup VPN client. Also, the Qubes firewall is 
limited when domain names are used; you could end up with the firewall 
trying to filter different addresses than what the VPN client is trying 
to use (that is, if your VPN provider has multiple addresses kept in 
rotation).


Finally, on Qubes 3.x it can make sense to use sys-firewall (or similar 
proxyVM) the other way: Put it between the appVMs and VPN VM if you wish 
to use "Deny except" mode in your appVM settings. The reason is this 
mode will trigger a Qubes bug if the appVM is connected directly to the 
VPN VM resulting in DNS blockage. However, the Qubes-vpn-support 
project[1] has a workaround for the bug, making the following 
arrangement perfectly fine even when using "Deny except" on the appVM:


appVM--->sys-vpn--->sys-net

If you're not using "Deny except" on appVMs this arrangement also works, 
no workaround required.


[1] https://github.com/tasket/Qubes-vpn-support

--

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/7ed27489-9e2c-ee30-d9b6-2b2122d4b853%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Trying to get my head around a configuration for a VPN-Proxy VM and its firewall?

2017-12-15 Thread velcro
I just wanted to clarify my questions...I made some edits:

> Scenario #1
> VM---sys-vpn--\
>\
> \
> VM-sys-firewall---sys-net
>  /
> /
> VM-/
> 
> 
> 
> Scenario #2
> VM--sys-vpn--sys-firewall---sys-net(Wireless and ethernet)
> VM---sys-firewall---sys-net(Wireless and ethernet)
> VM---sys-firewall---sys-net(Wireless and ethernet)
> 
> 
> 
> Scenario #3
> VM--sys-vpn-sys-net(Wireless and ethernet)
> VM--sys-firewallsys-net(Ethernet only)
> VM--sys-firewallsys-net(Wireless only)
> 
> 
> I am looking at configuring a VPN for 3.2 and I am trying to find the best 
> configuration and firewall settings balancing usability, efficiency and 
> security. My questions are:
> 
> 1) If sys-net is not trustworthy do these scenarios matter from a security 
> perspective regarding sys-net? Scenario #1 I assume consumes the least 
> resources...
> 
> 2) Regarding sys-vpn firewall...do these setting in effect create a kill 
> switch in my sys-vpn firewall?(I am only provided a URL from my VPN provider, 
> not the IPs), firewall settings in my sys-vpn firewall:
> Address= *
> Service= I enter the port number provided by my VPN provider
> Protocol= I enter UDP or TCP depending on my VPN providers instructions?
> 
> Thanks...any dialogue, options, opinions or answers are appreciated
> 
> Happy holiday and thanks again Qubes!
> 
> V

-- 
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/6969d994-fef0-4380-b1f4-daa42158e2aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Trying to get my head around a configuration for a VPN-Proxy VM and its firewall?

2017-12-15 Thread velcro
Scenario #1
VM---sys-vpn\
 \
  \
VM-\sys-firewall---sys-net
   /
  /
VM---/



Scenario #2
VM--sys-vpn--sys-firewall---sys-net(Wireless and ethernet)
VM---sys-firewall---sys-net(Wireless and ethernet)
VM---sys-firewall---sys-net(Wireless and ethernet)



Scenario #3
VM--sys-vpn-sys-net(Wireless and ethernet)
VM--sys-firewallsys-net(Ethernet only)
VM--sys-firewallsys-net(Wireless only)


I am looking at configuring a VPN for 3.2 and I am trying to find the best 
configuration and firewall settings balancing usability, flexibility and 
security. My questions are:

1) If sys-net is not trustworthy do these scenarios matter from a security 
perspective regarding sys-net? Scenario #1 I assume consumes the least 
resources...

2) Regarding sys-vpn firewall...do these setting in effect create a kill switch 
in my firewall?(I only have a URL, not the IPs):
Address= *
Service= I enter the port number from my VPN provider
Protocol= I enter UDP or TCP depending on my VPN providers instructions?

Thanks...any dialogue, options or answers are appreciated

Happy holiday and thanks again Qubes!

V


-- 
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/0c3cd2c1-1d8e-4915-b15f-28d80f3bf433%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] How to use wifi card with Kali ?

2017-12-15 Thread axel.schwoerer via qubes-users
Hello all. 
I've installed Kali Linux template on Qubes, and I want to know if it possible 
to use the wifi cards computer or to use an external wifi card (like AWUS036h) 
? 

Cheers. 

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


Re: [qubes-users] Installation Issues on Asus Zenbook UX303 - both 3.2 and 4.0 halting during first-run VM creation

2017-12-15 Thread 'awokd' via qubes-users
On Fri, December 15, 2017 1:54 pm, callumvi...@gmail.com wrote:

> The target stick then boots successfully and proceeds to 1st-time setup
> and VM creation, but hangs at a seemingly random point during this
> process (the panning progress bar freezes indefinitely).

Try letting it run overnight (seriously).

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


Re: [qubes-users] New HCL Entry: Lenovo ThinkPad T470 (20HDCTO1WW)

2017-12-15 Thread Josef Johansson
Sorry, I missed that part of your reply. I was answering both of you :)

I'll see if I can get Qubes 3.2 running on my T470p in the weekend if
there's time. My collegue ended up with 4.0 with legacy boot to get
everything working, so I just started from there. Using it for critical
work and so far it's quite stable.

Regards
Josef

On Fri, 15 Dec 2017, 16:20 ,  wrote:

> Thank you for your reply.
>
> Could you explain to me why using EFI would solve the problem of the X
> server not starting?
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "qubes-users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/qubes-users/TEmVIozLJh0/unsubscribe.
> To unsubscribe from this group and all its topics, 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/84284e0a-7269-44d7-ab95-98395b9330a8%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAOnYue_w-zHpgbM4ZE%3DY%3DW_f35Gk8yv%3DYN5Gq%3DEMLZ0KcEC%3D8w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] how to forward webcam to a VM?

2017-12-15 Thread evo


Am 15.12.2017 um 20:11 schrieb awokd:
> On Fri, December 15, 2017 11:13 am, evo wrote:
> 
>> so i've tried it, but i get this error by starting webcam-vm after adding
>> the usb-device to it: "libxenlight could not create a new domain
>> "webcam-vm"
>>
>>
>> if i try it one more time, i get: UnicodeDecodeError: ascii codec can't
>> decode byte 0xc3 in position 34: ordinal not in range(128).
>>
>> i've tried all three usb devices that are shown on sys-usb
> 
> You are running Qubes 3.2? Not sure what's going on then, that usually
> fixes it for me...
> 
> 


yes, the last version of 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/5d8311f3-4c24-340e-a77a-aaea9ce9b555%40aliaks.de.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] how to forward webcam to a VM?

2017-12-15 Thread 'awokd' via qubes-users
On Fri, December 15, 2017 11:13 am, evo wrote:

> so i've tried it, but i get this error by starting webcam-vm after adding
> the usb-device to it: "libxenlight could not create a new domain
> "webcam-vm"
>
>
> if i try it one more time, i get: UnicodeDecodeError: ascii codec can't
> decode byte 0xc3 in position 34: ordinal not in range(128).
>
> i've tried all three usb devices that are shown on sys-usb

You are running Qubes 3.2? Not sure what's going on then, that usually
fixes it for me...


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


[qubes-users] Re: Tips for running Tails in 4.0rc3 along with virtual USB storage

2017-12-15 Thread Yethal
W dniu piątek, 15 grudnia 2017 15:39:11 UTC+1 użytkownik Kushal Das napisał:
> Hi,
> 
> I am tryig to run Tails under 4.0rc3 along with virtual USB storage. I
> need the storage
> so that I can install Tails on it, and then do some work using the
> Persistence volume  (for development). Any tops if this can be done?
> 
> 
> Kushal
> -- 
> Staff, Freedom of the Press Foundation
> CPython Core Developer
> Director, Python Software Foundation
> https://kushaldas.in

Can't you just run a Whonix VM? Or, even better, a disposable Whonix VM?

-- 
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/24e1aac8-d141-480b-8eee-286263fe6915%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Dumping BIOS

2017-12-15 Thread Matteo

> I disagree when you say nooone is going to backdoor your bios.   I think its 
> very common nowadays. 
as far as i know there is computrace that is an anti theft system that
gain persistence over the os by dropping an exe that windows will load
at boot time but this works only over fat32 and ntfs (not encrypted).
i heard also about lenovo doing the same thing for ads or whatever. and
after people got angry they released a bios patch to opt-out.
but i wouldn't say "very common".

I don't think Qubes actually shields you from a buggy bios...
yes, Qubes "shield" you because bios is simply not visible from the vm
so for example a bug in S3 resume script that does not restore proper
spi flash write protection is not a problem (from what i have understood).
also see rutkovska:
https://twitter.com/rootkovska/status/934695078764974080

>   But I guess you are right not to worry about it
yes, and please anyone, focus your efforts on something more probable;
attackers always chose the cheapest path.
take a look at:
https://www.securityplanner.org/ (require javascript)

-- 
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/53f0da74-8526-c099-9a47-b1d3aac46442%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] how to use "Rescue a Qubes system" or save my data, won't boot

2017-12-15 Thread jerry57
I first used a konsole, using the guide on qubes's site "Using and Managing USB 
Devices"
1. Enable sys-usb

using the command sudo qubesctl top.enable qvm.sys-usb
2. Apply the configuration:
using the command sudo qubesctl state.highstate

then it froze, restarted system, and when in passphrase entering the encryption 
code, keyboard didn't work, but when i press a button it highlights the num 
button, and if i hold any button on keyboard the num highlight is turned on, 
when i release the light is off...

i reinstalled qubes choosing manual partition (not the automatic), i'm un-sure 
if i deleted or damaged my data.. (see note below)
now it still doesn't boot qubes, keyboard works on passphrase encryption of 
disk, but when it's loaded, it gets stuck, if i click alt+tab it counts some 
numbers and says unlimited.

note: i still think i have the data, maybe, i have something like 
luks-23232-f-sdf-saf-sad-sa-ds and also dom0-root-00 something (not accurate 
name)

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


[qubes-users] test, can u see this post?

2017-12-15 Thread jerry57
...

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


Re: [qubes-users] New HCL Entry: Lenovo ThinkPad T470 (20HDCTO1WW)

2017-12-15 Thread kototamo
Thank you for your reply.

Could you explain to me why using EFI would solve the problem of the X server 
not starting?

-- 
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/84284e0a-7269-44d7-ab95-98395b9330a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Dumping BIOS

2017-12-15 Thread cooloutac
On Wednesday, December 13, 2017 at 1:53:01 PM UTC-5, Matteo wrote:
> >> Can anyone give me the instructions necessaries to dump the bios of my PC. 
> >> So that I’m sure while using Qubes that I’m safe?
> >> Best regards 
> >> Leonardo
> > 
> > How exactly would dumping the bios make sure you're safe?
> > 
> 
> You don't need to dump it to be safe. Qubes "shields" you from buggy
> bios so you don't care if it has an exploitable vulnerability.
> you only need to worry about supply chain attacks (you buy a new pc with
> backdoored bios).
> but again you don't need to worry about that, instead focus your efforts
> in automatizing opening links and email attachments in the correct vm
> (micah flee has made a tutorial for that).
> 
> if you really want to dump the bios for fun or learn new things here is
> my expirence:
> you can use arduino or a raspberry pi (of course you can also buy a
> programmer but they cost more).
> 
> depending on the spi flash model and pc model you might need a power
> adapter:
> arduino is 5V
> raspberry is 3,3V
> spi flash are usually 3,3V but some are 1,8V (and you will burn them if
> you attach 3,3V)
> you might need to desolder the chip to be able to read it.
> again, i think you should focus on other things.
> 
> Qubes OS is a security oriented os but this doesn't mean that everyone
> must come out with the most strange attacks... think about simpler one
> and stop them, noone is going to backdoor your bios, and if it has
> unfixed bugs you don't care thanks to Qubes.
> 
> if you/someone wants more detailed info about bios dumping i'll be happy
> to help but i think it's a bit off topic and an overkill.

I disagree when you say nooone is going to backdoor your bios.   I think its 
very common nowadays.  I don't think Qubes actually shields you from a buggy 
bios but its actually very dependent on a proper working bios, like any O/S.  
Especially since qubes uses features of bios most os doesn't.

  But I guess you are right not to worry about it,  because there is not much 
you can do for a corrupted or buggy bios,  except to buy a new pc,  but it 
would be something most people would want to confirm before doing, or using it 
for sensitive tasks.

I agree dumping the bios to have a snapshot of it would be very complicated and 
not practical at all.  But I see nothing wrong with doing so if willing and 
able.  You can also look into using AEM to see if something changes during boot.

https://www.qubes-os.org/doc/anti-evil-maid/

-- 
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/3393425a-edea-4dae-94d8-c59cd242c3d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] New HCL Entry: Lenovo ThinkPad T470 (20HDCTO1WW)

2017-12-15 Thread Josef Johansson
Hi,

I would try my path, download rEFInd to another usb-stick and boot the
installer from there.

The only file you need is the EFI-file:
https://sourceforge.net/projects/refind/

Also, that is an interesting data point as well, the bootx64.efi loader on
the usb install works if it is started through rEFInd.

Cheers
Josef

On Fri, 15 Dec 2017, 05:00 ,  wrote:

> OK, here is (I hope) a *public* version of said screen shot:
>
> https://photos.google.com/share/AF1QipMRlHUC5EOV-PQD5kfWWfCp9BDroAHDXGAFdWcq_SrmJhfhnHHOF6ZvYU7-JenLOA?key=MlJxWFRyZm1OTHBnWXpHd1pfUXNVYzJjMmJsTlRR
>
> (Just learning Google Photo, Google+, gmail, etc., for purposes of this
> post.  Until now I've been able to avoid them :-/ )
>
>   - Eric
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "qubes-users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/qubes-users/TEmVIozLJh0/unsubscribe.
> To unsubscribe from this group and all its topics, 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/f44e144a-c45e-43a0-84f0-1ca61905bce8%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAOnYue_Rpr46xZqS6sdM7y9O-B5NGWXpbfzZLOoq2ctm-JJmyA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Tips for running Tails in 4.0rc3 along with virtual USB storage

2017-12-15 Thread Kushal Das
Hi,

I am tryig to run Tails under 4.0rc3 along with virtual USB storage. I
need the storage
so that I can install Tails on it, and then do some work using the
Persistence volume  (for development). Any tops if this can be done?


Kushal
-- 
Staff, Freedom of the Press Foundation
CPython Core Developer
Director, Python Software Foundation
https://kushaldas.in

-- 
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/CAAzeMbzgdxX%3D_y9NJ0mofOcETRCb-qy7PsirLmA9MkWEpHzgzA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Installation Issues on Asus Zenbook UX303 - both 3.2 and 4.0 halting during first-run VM creation

2017-12-15 Thread callumvib91
Dear qubes-users,

I've been trying to get a version of Qubes running on an Asus Zenbook UX303 
(albeit by installing to a large USB 3 stick). 

Having DD'd the latest image (after verification) to an installation stick 
using the latest Rufus the installer boots, recognises the target stick and 
appears to install successfully using default settings and automatic partition 
scheme. 

The target stick then boots successfully and proceeds to 1st-time setup and VM 
creation, but hangs at a seemingly random point during this process (the 
panning progress bar freezes indefinitely). 

I've tested with both 3.2 and 4.0, with the network card enabled and disabled, 
and with and without default VM creation.

The UX303 seems to be in a solid position in the HCL, so I'm wondering whether 
I'm making a rookie error somewhere or whether it's that I'm targeting a stick 
rather than the internal SSD that's causing the freezes (such as the USB going 
to sleep midway).

Any advice would be greatly appreciated.

Callum

-- 
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/624cde58-aebe-4e99-8f34-194e2db5d2dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] how to forward webcam to a VM?

2017-12-15 Thread evo


Am 26.11.2017 um 16:47 schrieb awokd:
> On Sun, November 26, 2017 15:13, evo wrote:
>>
>>
>> Am 26.11.2017 um 16:10 schrieb Unman:
>>> On Sun, Nov 26, 2017 at 01:04:39PM +0100, evo wrote:
> 
 Hey! Thanks!
 i installed qubes-usb-proxy on the webcam-VM and tried to attach it
 there, but i get this error: "device attach failed: Invalid speed
 received"

 find nothing about such error in the docs.
>>>
>>> Which Qubes version are you using?
>>>
>>> What's the device you are trying to use?
>>> Can you provde more information?
>>>
>>> This is an error that has been reported before and there's an open
>>> ticket on qubes issues.
>>> It seems to be device and circumstance dependent. (e.g an android in
>>> debug mode throws this error but the same device NOT in debug mode
>>> attaches properly.)
>>>
>>
>>
>> i use qubes 3.2
>> and i try to use logitech hd C920 webcam
>>
>> i found some postings to such kind of error, yes... and it seems to be a
>> bug, isn't it?
>>
>> So there is no chance to solve it?
> 
> Might be fixed in 4.0 or a future version, but as a temporary workaround
> for problem USB devices like that you can assign an entire USB controller
> to your webcam-VM. It's not as nice because you lose isolation for that
> controller but it should work. If you want to try it, unplug all
> unnecessary USB devices. Shutdown both webcam-VM and sys-usb. Look in
> sys-usb device list for a USB controller, note the number, remove from
> selected list. Add it to webcam-VM Devices, and uncheck Include in memory
> balancing in Advanced. You might also need to up the initial memory while
> you are in here, try 1024 MB.
> 
> Start webcam-VM. Each USB controller only handles some of the USB ports,
> so it might be trial and error to find one that handles the empty port you
> are plugging the webcam into. Once you figure out which USB port or ports
> are now assigned to the webcam-VM, try to avoid plugging anything else
> into them besides the webcam.
> 
> 

thank you!


sorry that i answer so late... had no time till now :-/

so i've tried it, but i get this error by starting webcam-vm after
adding the usb-device to it: "libxenlight could not create a new domain
"webcam-vm"

if i try it one more time, i get: UnicodeDecodeError: ascii codec can't
decode byte 0xc3 in position 34: ordinal not in range(128).

i've tried all three usb devices that are shown on 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/19d48dcf-9a91-09c6-62da-56a450cdff8c%40aliaks.de.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] New HCL Entry: Lenovo ThinkPad T470 (20HDCTO1WW)

2017-12-15 Thread kototamo
Hello everyone,

I tried to install Qubes 3.2 on a T470s without success. I have the version 
with the Intel graphics. I did everything in Legacy Mode (no EFI). It does boot 
but the X server cannot start. Text installation did not work.

Stephan Marwedel says in this thread he managed to install 3.2. How?

I cannot wait for version 4 to come in January or later and installing RC 
version is risky since I need the laptop for work and no migration path from RC 
to candidate is guaranteed by the Qubes OS team.

Any help will be highly appreciated!

-- 
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/ea610d39-36d7-4c0e-94c6-24fdf1be8d12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.