[qubes-users] Windows 10 on Qubes (freeRDP)

[3n7r0py1]

I noticed several folks looking for a way to use Windows 10 on Qubes. Since 
there is currently no ETA for Windows 10 support via `qubes-windows-tools`[1], 
I thought I'd share an alternative method. I don't have time for a full writeup 
at the moment but importantly, nothing in this post is really Qubes-specific, 
meaning you can find plenty of relevant resources elsewhere. 

Windows 10 / Server 2016 installs and runs without any issues as an HVM on 
Qubes 3.2 (4.0 not tested). Inter-VM functionality can be achieved using any 
remote desktop protocol, including X11, VNC and RDP. This post is about using 
the freeRDP client with Windows' built-in RDP server functionality.

The RDP protocol enables the following major features: seamless windows, shared 
clipboard, shared folders, and audio & usb redirection. GPU-accelerated VMs are 
possible if they are hosted on a separate Hyper-V machine. Keep in mind that 
all of these features are provided by the RDP protocol over standard networking 
interfaces. This is in contrast to `qubes-windows-tools` which provides similar 
functionality using Qubes' back-end. Determine if that risk is appropriate for 
you. QWT also provides access to qrexec and persistent profiles (that enable 
immutable root filesystems and simplified offline HVMs).

1. Install Windows 10 as a Standalone HVM or HVM Template (if you have the 
appropriate licenses). The template will have limited usage unless you can 
offload data you want to persist onto a separate volume (or you can use as a 
disposable vm). Also, make sure you setup a password. Enable Remote Desktop in 
Settings > System. Leave NLA enabled.

2. InterVM Communication: This will be the hardest step for those of you new to 
this. You'll need to allow one of your LinuxVMs (freeRDP client) to communicate 
with one of your Windows VMs (RDP server). Create or use a proxyVM to act as a 
router. 

Example of basic setup:

 win10   
   | 
   | 
 sys-net --- sys-firewall
   | 
   | 
 workVM  
 
Instructions are here: 
https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes
Don't proceed until you succeed with this step.
 
3. Install `freerdp` in workVM. Fedora-25 has v2.0.0 as does Debian 
stretch-backports.

4. Test with `xfreerdp /v::3389`. If server responds and you can log 
in, then you can pile on the options.

5. There are MANY options. See `man xfreerdp` and docs[2]. I haven't used a GUI 
but some exist, like Remmina. You may want to add the following:
```
  /v::3389
  /u:[domain\]
  /p:
  /w:
  /h:
  /network:lan # network speed
  /drive:myShare,/home/user/myShare   # share name, location
  /rfx # remote-fx works will all vm's; only hyperv for gpu
  /rfx-mode:
  /multimedia  # for sync'd audio/video, see docs
  /sound   # sound redirection
  /sound:latency:
  /microphone
  /usb:id,dev  # usb redirection, see docs
  /clipboard
  /fonts   # cleartype
  /app:"C:\Windows\explorer.exe"  # remote-apps (see below)
```

** Remote Apps **

For seamless windows, in RDP host > Group Policy:
`Computer Configuration/Administrative Templates/Windows Components/Remote 
Desktop Services/Remote Desktop Session Host/Connections/Allow remote start of 
unlisted programs`: Set to "Enabled"
Easiest way to use is to launch File Explorer (C:\Windows\explorer.exe) or 
Console (C:\Windows\System32\cmd.exe). Set up shortcuts and launch from these 
programs - then applications will open in their own seamless windows.


** Offline Windows **

The best feature of `qubes-windows-tools` is that you can use Windows offline 
with networking completely disabled. Without QWT, the best you can do is have 
strict firewalls everywhere but especially on your proxyVM.

The only traffic that is necessary for this setup (in proxyVM):
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i vif+ -s  -o vif+ -d  \
  -p tcp --dport 3389 -m state --state NEW -j ACCEPT

Drop all other windows outbound traffic entering proxyVM: 
iptables -A FORWARD -i vif+ -s  -j DROP
iptables -A INPUT -i vif+ -s  -j DROP

Some other ports that you may require:
WSUS: tcp 8530-8531
KMS: tcp 1688
Samba is a mess: tighten with -s and -d


** Torrified Windows ** 

Of questionable benefit since win10 is a leaky sieve, but for fun you can route 
traffic through `sys-whonix`.

# Redirect DNS to Whonix-Gateway
iptables -t nat -A PREROUTING -i 

[qubes-users] Re: whonix templates qubes 4

[3n7r0py1]

On Wednesday, October 18, 2017 at 8:01:50 PM UTC, Roy Bernat wrote:
> I am getting error download whonix regarding 
> 
> could not read file curl error (37)   NOKEY . 
> 
> any suggestions ? 
> 
> R

Please check:
https://forums.whonix.org/t/qubes-4-0-rc1-cant-find-the-whonix-template-package/4221
https://github.com/QubesOS/qubes-issues/issues/2954

-- 
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/8e0dbe9d-ed5f-474e-bd78-d26fb7b525b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Atheros ath9k wireless pci-e not functional in Fedora-24 template

[3n7r0py1]

On Friday, December 16, 2016 at 8:36:53 PM UTC, 3n7r...@gmail.com wrote:
> ath9k is a well supported driver in Linux. Present in kernel since 2.6. 
> (https://wireless.wiki.kernel.org/en/users/drivers/ath9k) Card is 5+ year old 
> implementation.
> 
> Tested and working in a Fedora-25 LiveCD without any additional 
> configuration. (Kernel 4.8)
> 
> In Qubes 3.1, added as PCI device to a Fedora-24 TemplateVM. (Kernel 4.1) 
> ath9k driver is correctly loaded but device does not show up in `iwconfig`.
> 
> 
> $ lspci -k | grep -A 3 -i network
> 00:00.0 Network controller: Qualcomm Atheros AR5418 Wireless Network Adapter 
> [AR5008E 802.11(a)bgn] (PCI-Express) (rev 01)
>   Kernel driver in use: ath9k
>   Kernel modules: ath9k
> 
> 
> $ iwconfig
> lono wireless extensions.
> 
> 
> [1.980648] pcifront pci-0: Installing PCI frontend
> [1.980706] pcifront pci-0: Creating PCI Frontend Bus :00
> [1.980732] pcifront pci-0: PCI host bridge to bus :00
> [1.980736] pci_bus :00: root bus resource [io  0x-0x]
> [1.980740] pci_bus :00: root bus resource [mem 0x-0xf]
> [1.980743] pci_bus :00: root bus resource [bus 00-ff]
> [1.980877] pci :00:00.0: [168c:0024] type 00 class 0x028000
> [1.981171] pci :00:00.0: reg 0x10: [mem 0xf7d0-0xf7d0 64bit]
> [1.983450] pci :00:00.0: supports D1
> [1.984459] pcifront pci-0: claiming resource :00:00.0/0
> [2.028350] alg: No test for crc32 (crc32-pclmul)
> [2.07] intel_rapl: Found RAPL domain package
> [2.033344] intel_rapl: Found RAPL domain core
> [2.131727] EXT4-fs (xvdb): mounted filesystem with ordered data mode. 
> Opts: discard
> [2.140627] cfg80211: Calling CRDA to update world regulatory domain
> [2.146866] cfg80211: World regulatory domain updated:
> [2.146873] cfg80211:  DFS Master region: unset
> [2.146875] cfg80211:   (start_freq - end_freq @ bandwidth), 
> (max_antenna_gain, max_eirp), (dfs_cac_time)
> [2.146898] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 
> 2000 mBm), (N/A)
> [2.146903] cfg80211:   (2457000 KHz - 2482000 KHz @ 2 KHz, 92000 KHz 
> AUTO), (N/A, 2000 mBm), (N/A)
> [2.146908] cfg80211:   (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 
> 2000 mBm), (N/A)
> [2.146912] cfg80211:   (517 KHz - 525 KHz @ 8 KHz, 16 KHz 
> AUTO), (N/A, 2000 mBm), (N/A)
> [2.146918] cfg80211:   (525 KHz - 533 KHz @ 8 KHz, 16 KHz 
> AUTO), (N/A, 2000 mBm), (0 s)
> [2.146923] cfg80211:   (549 KHz - 573 KHz @ 16 KHz), (N/A, 
> 2000 mBm), (0 s)
> [2.146927] cfg80211:   (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 
> 2000 mBm), (N/A)
> [2.146932] cfg80211:   (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 
> 0 mBm), (N/A)
> [2.176424] ath9k :00:00.0: Xen PCI mapped GSI17 to IRQ31
> *[2.314703] BUG: unable to handle kernel paging request at 
> c96c0040
> *[2.314712] IP: [] iowrite32+0x38/0x40
> [2.314718] PGD 3fdd1067 PUD 3fdd0067 PMD 3ade1067 PTE 8010f7d00075
> *[2.314723] Oops: 0003 [#1] SMP 
> [2.314726] Modules linked in: ath9k(+) ath9k_common ath9k_hw ath mac80211 
> cfg80211 rfkill intel_rapl iosf_mbi x86_pkg_temp_thermal coretemp 
> crct10dif_pclmul crc32_pclmul crc32c_intel pcspkr xen_pcifront xenfs 
> dummy_hcd udc_core xen_privcmd u2mfn(O) xen_blkback nf_conntrack_pptp 
> nf_conntrack_proto_gre nf_conntrack xen_blkfront
> *[2.314748] CPU: 0 PID: 214 Comm: systemd-udevd Tainted: G   O
> 4.1.24-10.pvops.qubes.x86_64 #1
> [2.314763] RSP: e02b:88003cab7870  EFLAGS: 00010296
> [2.314766] RAX:  RBX: 88003c2ed3a0 RCX: 
> 0004
> [2.314769] RDX: c96c0040 RSI: c96c0040 RDI: 
> 
> [2.314772] RBP: 88003cab78a8 R08: 000186a0 R09: 
> 88003d001800
> [2.314775] R10: 88003d001800 R11: 5dc5 R12: 
> 
> [2.314778] R13: 0100 R14: a027b550 R15: 
> 88003c910028
> [2.314783] FS:  7f502afb68c0() GS:88003f80() 
> knlGS:
> [2.314788] CS:  e033 DS:  ES:  CR0: 80050033
> [2.314791] CR2: c96c0040 CR3: 3c9a5000 CR4: 
> 00042660
> [2.314794] Stack:
> [2.314797]  a02910b5 8098  
> 88003c910028
> [2.314802]  88003c910078 0100 a027b550 
> 88003cab78c8
> [2.314807]  a0239de2 88003c910078 88003c910028 
> 88003cab78e8
> [2.314813] Call Trace:
> [2.314820]  [] ? ath9k_iowrite32+0x35/0x90 [ath9k]
> [2.314828]  [] ath9k_enable_mib_counters+0x52/0x90 
> [ath9k_hw]
> [2.314835]  [] ath9k_hw_ani_init+0xa6/0xe0 [ath9k_hw]
> [2.314841]  [] __ath9k_hw_init+0x5c9/0xb40 [ath9k_hw]
> [2.314846]  [] ath9k_hw_init+0x35/0x90 [ath9k_hw]
> [

[qubes-users] Atheros ath9k wireless pci-e not functional in Fedora-24 template

[3n7r0py1]

ath9k is a well supported driver in Linux. Present in kernel since 2.6. 
(https://wireless.wiki.kernel.org/en/users/drivers/ath9k) Card is 5+ year old 
implementation.

Tested and working in a Fedora-25 LiveCD without any additional configuration. 
(Kernel 4.8)

In Qubes 3.1, added as PCI device to a Fedora-24 TemplateVM. (Kernel 4.1) ath9k 
driver is correctly loaded but device does not show up in `iwconfig`.


$ lspci -k | grep -A 3 -i network
00:00.0 Network controller: Qualcomm Atheros AR5418 Wireless Network Adapter 
[AR5008E 802.11(a)bgn] (PCI-Express) (rev 01)
Kernel driver in use: ath9k
Kernel modules: ath9k


$ iwconfig
lono wireless extensions.


[1.980648] pcifront pci-0: Installing PCI frontend
[1.980706] pcifront pci-0: Creating PCI Frontend Bus :00
[1.980732] pcifront pci-0: PCI host bridge to bus :00
[1.980736] pci_bus :00: root bus resource [io  0x-0x]
[1.980740] pci_bus :00: root bus resource [mem 0x-0xf]
[1.980743] pci_bus :00: root bus resource [bus 00-ff]
[1.980877] pci :00:00.0: [168c:0024] type 00 class 0x028000
[1.981171] pci :00:00.0: reg 0x10: [mem 0xf7d0-0xf7d0 64bit]
[1.983450] pci :00:00.0: supports D1
[1.984459] pcifront pci-0: claiming resource :00:00.0/0
[2.028350] alg: No test for crc32 (crc32-pclmul)
[2.07] intel_rapl: Found RAPL domain package
[2.033344] intel_rapl: Found RAPL domain core
[2.131727] EXT4-fs (xvdb): mounted filesystem with ordered data mode. Opts: 
discard
[2.140627] cfg80211: Calling CRDA to update world regulatory domain
[2.146866] cfg80211: World regulatory domain updated:
[2.146873] cfg80211:  DFS Master region: unset
[2.146875] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp), (dfs_cac_time)
[2.146898] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 
mBm), (N/A)
[2.146903] cfg80211:   (2457000 KHz - 2482000 KHz @ 2 KHz, 92000 KHz 
AUTO), (N/A, 2000 mBm), (N/A)
[2.146908] cfg80211:   (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 
mBm), (N/A)
[2.146912] cfg80211:   (517 KHz - 525 KHz @ 8 KHz, 16 KHz 
AUTO), (N/A, 2000 mBm), (N/A)
[2.146918] cfg80211:   (525 KHz - 533 KHz @ 8 KHz, 16 KHz 
AUTO), (N/A, 2000 mBm), (0 s)
[2.146923] cfg80211:   (549 KHz - 573 KHz @ 16 KHz), (N/A, 2000 
mBm), (0 s)
[2.146927] cfg80211:   (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 2000 
mBm), (N/A)
[2.146932] cfg80211:   (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 0 
mBm), (N/A)
[2.176424] ath9k :00:00.0: Xen PCI mapped GSI17 to IRQ31
*[2.314703] BUG: unable to handle kernel paging request at c96c0040
*[2.314712] IP: [] iowrite32+0x38/0x40
[2.314718] PGD 3fdd1067 PUD 3fdd0067 PMD 3ade1067 PTE 8010f7d00075
*[2.314723] Oops: 0003 [#1] SMP 
[2.314726] Modules linked in: ath9k(+) ath9k_common ath9k_hw ath mac80211 
cfg80211 rfkill intel_rapl iosf_mbi x86_pkg_temp_thermal coretemp 
crct10dif_pclmul crc32_pclmul crc32c_intel pcspkr xen_pcifront xenfs dummy_hcd 
udc_core xen_privcmd u2mfn(O) xen_blkback nf_conntrack_pptp 
nf_conntrack_proto_gre nf_conntrack xen_blkfront
*[2.314748] CPU: 0 PID: 214 Comm: systemd-udevd Tainted: G   O
4.1.24-10.pvops.qubes.x86_64 #1
[2.314763] RSP: e02b:88003cab7870  EFLAGS: 00010296
[2.314766] RAX:  RBX: 88003c2ed3a0 RCX: 0004
[2.314769] RDX: c96c0040 RSI: c96c0040 RDI: 
[2.314772] RBP: 88003cab78a8 R08: 000186a0 R09: 88003d001800
[2.314775] R10: 88003d001800 R11: 5dc5 R12: 
[2.314778] R13: 0100 R14: a027b550 R15: 88003c910028
[2.314783] FS:  7f502afb68c0() GS:88003f80() 
knlGS:
[2.314788] CS:  e033 DS:  ES:  CR0: 80050033
[2.314791] CR2: c96c0040 CR3: 3c9a5000 CR4: 00042660
[2.314794] Stack:
[2.314797]  a02910b5 8098  
88003c910028
[2.314802]  88003c910078 0100 a027b550 
88003cab78c8
[2.314807]  a0239de2 88003c910078 88003c910028 
88003cab78e8
[2.314813] Call Trace:
[2.314820]  [] ? ath9k_iowrite32+0x35/0x90 [ath9k]
[2.314828]  [] ath9k_enable_mib_counters+0x52/0x90 
[ath9k_hw]
[2.314835]  [] ath9k_hw_ani_init+0xa6/0xe0 [ath9k_hw]
[2.314841]  [] __ath9k_hw_init+0x5c9/0xb40 [ath9k_hw]
[2.314846]  [] ath9k_hw_init+0x35/0x90 [ath9k_hw]
[2.314852]  [] ath9k_init_device+0x51b/0xdb0 [ath9k]
[2.314856]  [] ? request_threaded_irq+0xf4/0x1b0
[2.314862]  [] ath_pci_probe+0x248/0x340 [ath9k]
[2.314866]  [] ? kernfs_link_sibling+0x9d/0xc0
[2.314870]  [] ? _raw_spin_unlock_irqrestore+0x1f/0x50
[2.314875]  [] 

[qubes-users] Re: What is the best way to use i2p in Qubes? Wouldn't it be great if we had native i2p support?

[3n7r0py1]

5fxfc1+2ch7pcmy34te01rpv5qj0zj3h115fu90fwr3h7yl5u via qubes-users:
> Hi everyone!
> 
> I wanted to ask: What is the best way to use i2p in Qubes? Should I
> setup a NetVM or install i2p in a TemplateVM? 

This was my reply to the related Github issue[1] before I saw this post 
(clearly, this was the more appropriate venue for my reply). And with your main 
use case being torrenting, you might not want your traffic flowing over Tor 
(depending on what you're torrenting).

1. I2P in ProxyVM: As you found, this is challenging because you need routing 
and firewall rules to send the traffic to the right places. You can get an idea 
of how things work by following Qubes VPN guide[2] and watching Qubes SOCKS 
proxy issue[3].

2. I2P in AppVM: Easy (set it up like you would normally) but less secure 
(misbehaving apps might be able to bypass).

3. I2P in Whonix-Workstation AppVM: Slower (traffic flows through Tor, then 
I2P: user -> tor -> i2p -> internet) but secure in that any leakage goes 
through Tor. Also fully documented[4] and somewhat supported[5].


> Also since Java is not
> the most secure environment, I'm planning on using i2pd which is
> based on C++.

1. "Why do I hear about so many Java insecurities? Are other languages more 
secure?"[6]
2. I2P Devs are no slouches to intentionally use flawed language.
3. i2pd official wiki[7] claims many advantages but security is not one of 
them. (flexibility, speed, efficiency, footprint)

-
1 https://github.com/QubesOS/qubes-issues/issues/2503
2 https://www.qubes-os.org/doc/vpn/
3 https://github.com/QubesOS/qubes-issues/issues/1536#issuecomment-265714285
4 https://www.whonix.org/wiki/I2P
5 https://forums.whonix.org/search?q=i2p
6 
https://security.stackexchange.com/questions/57646/why-do-i-hear-about-so-many-java-insecurities-are-other-languages-more-secure
7 
https://github.com/PurpleI2P/i2pd/wiki/Differences-between-i2pd-and-Java-I2P-router

-- 
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/15481a46-5974-4ad3-a13b-eef7a867ab3e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] PAM errors after disabling password-less root

[3n7r0py1]

On Wednesday, November 16, 2016 at 1:22:43 PM UTC, Chris Laprise wrote:
> On 11/15/2016 04:04 PM, Unman wrote:
> > On Tue, Nov 15, 2016 at 02:26:12PM -0500, Chris Laprise wrote:
> >> On 11/15/2016 07:20 AM, Unman wrote:
> >>> On Tue, Nov 15, 2016 at 11:55:13AM +, Unman wrote:
>  On Tue, Nov 15, 2016 at 05:53:56AM -0500, Chris Laprise wrote:
> > Following the instructions for the 'vm-sudo' doc, I get the following 
> > error
> > in Debian 9:
> >
> > /usr/lib/qubes/qrexec-client-vm failed: exit code 1
> > sudo: PAM authentication error: System error
> >
> >
> > Also, in the Debian 8 template the instructions don't match, as there
> > appears to be no file '/etc/pam.d/common-auth'.
> >
> > Chris
> >
>  Where did you get that template? The file is present in the default 3.2,
>  and even in a minimal-no-recommends template for Debian-8.
> 
>  I'll look at the Debian-9 issue now.
> 
> >>> I'm afraid I don't see this issue in a Debian-9 template.
> >>> Can you check your editing?
> >>>
> >>> Also, try manually running the qrexec-client-vm dom0 qubes.VMAuth
> >>> command, and making sure you get the expected output.
> >>> You should see the prompt(from the policy) and then  output from dom0.
> >>>
> >>> unman
> >>>
> >> Thanks for checking. However, I triple-checked my editing in Debian 9 and
> >> Debian 8 template is 'stock' basically nothing added to it.
> >>
> >> The qubes.VMAuth request said 'Request refused'. The doc appears to have a
> >> typo for the second command in Step 1. "Adding Dom0 “VMAuth” service" that
> >> causes '$anyvm' to disappear from the output. This line should use single
> >> quotes instead.
> >>
> >> Chris
> > You're right about that typo. Once you fixed it what happened?
> 
> It works now for Debian 9, submitted PR to fix the doc. I don't know 
> what the issue is with the missing file in Debian 8... The template's 
> basic form may not have a necessary package.
> 
> Chris

FWIW, the instructions work when applied to Whonix-Debian-8.

If I may piggyback on this thread with a related issue... The instructions 
(pre-typo) worked fine for both Fedora & Whonix VMs. But while the Fedora VMs 
would spin up silently, each Whonix VM required 4 sudo authorizations at each 
boot. Do you have any idea what that might be or how I could trace it? I don't 
have any user scripts / rc.local configured. The authorization requests 
sometimes appear while the VM light is yellow and other times won't appear 
until it's green. I'm worried that they might need to be clicked in the proper 
order and there's not enough identifying information on the dialogue to know 
what I'm authorizing. Would it be possible to pass the name of the triggering 
command to the dom0 sudo prompt?

-- 
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/d88e219e-ded9-4f10-8e70-f7a86b5f9a00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Intel TXT advice

[3n7r0py1]

On Monday, November 14, 2016 at 11:55:09 PM UTC, tai...@gmx.com wrote:
> On 11/14/2016 04:50 PM, entr0py wrote:
> 
> > taii...@gmx.com:
> >> On 11/14/2016 03:12 PM, Eric wrote:
> >>> On Monday, November 14, 2016 at 11:58:32 AM UTC-8, entr0py wrote:
>  Eric:
> > On Sunday, November 13, 2016 at 10:44:33 PM UTC-8,
> > tai...@gmx.com wrote:
> >> Forgot to say: Purism is just an overpriced quanta/oem
> >> whitebox laptop, it takes 5mil+ of startup funds to do a
> >> small run of *just a motherboard* let alone an entire laptop
> >> computer including the fab for a fancy aluminum case - it is
> >> quite obvious that their components are not "hand selected"
> >> and that they just called up some chinese OEM and asked them
> >> what they had kicking around.
> >>
> >> I can't understand if they are scammers or just really
> >> naive, Instead of making an OpenPower or ARM laptop and
> >> having it be 100% libre from the start they instead do the
> >> dishonest "you'll go to disneyworld one day poor johnny" - If
> >> google can't convince intel to open up FSP/ME then nobody can
> >> - coreboot with FSP is just shimboot (black box FSP - 95% of
> >> the bios work)
> >>
> >> It bothers me quite a lot that they are on the list of
> >> approved vendors when they are a dishonest company.
> > Whoa. Ok, hold on a sec. I did not buy a Purism computer,
> > though not for those reasons - putting a 28W TDP proc in a
> > 15inch "workstation" is absurd to me. as is their lack of a
> > screen configuration. I hear your anger at the gap between what
> > they promise and what they deliver; I'm more displeased on the
> > hardware side of things (though I do like HW kill switches.
> > I've looked into what they promise and understand very well
> > that they don't actually have a very free computer at all,
> > especially on the bios/firmware side.
> >
> > What I actually ordered (and have now cancelled), was a Dell
> > XPS 15". There is no vPro option in the configure menu, though
> > it does support VT-d and SLAT. I've read all of Joanna's
> > papers, and understand the concerns about Intel ME very well.
> > However, on the Dell order, it claimed "ME Disabled." Perhaps
> > they simply meant that vPro/AMT/TXT was disabled, and that was
> > mine and Dell's fault for wishful thinking and false naming,
> > respectively. Please see linked photo: https://d.pr/Q0YZ
> >
>  Moral considerations aside, why not buy that Dell and pair it
>  with a portable router/firewall like this
>  (https://www.compulab.co.il/utilite-computer/web/products)?
>  Shouldn't that effectively block out any ME-related mischief or
>  do I have a fundamental misunderstanding? It doesn't seem
>  possible otherwise to get the type of processing power you're
>  looking for in a laptop form-factor.
> >>> Also, the concern for me is not ME shenanigans. I'm more concerned
> >>> about having TXT for AEM and measured boot, and the consumer Dell
> >>> model does not have that (the processor and chipset don't support
> >>> it). The other option aside from the Precision 5510, would be a
> >>> ThinkPad T460 or T460p, but the downside there is performance (only
> >>> SATA-3 SSD), and also the screen quality is terrible.
> >>>
> >>> Much as I dislike proprietary anything, I might take a second look
> >>> at the new MacBook Pros, and run things that need higher security
> >>> in a VM or in Whonix.
> >> Why would you buy a macbook? You realize those have regular intel 
> >> processors and ME too right?
> >>
> >> Lenovo is owned by the chinese, and dell business laptop (their consumer 
> >> line is garbage) is a way better choice than either.
> >>
> >> It seems you do have (as you said) a fundamental misunderstanding of how 
> >> security actually works, and how a router/firewall operates. - thus I 
> >> don't think that anyone would be targeting you specifically with a ME 
> >> exploit.
> > (top-posting fixed)
> >
> > Despite my "fundamental misunderstanding of how security actually works", I 
> > am able to read a thread and keep track of who said what - a skill you 
> > seemed to have misplaced in all your wizardry. Also, on your crusade to 
> > dismantle Intel and Google, it might behoove you to take a slightly less 
> > agressive tack with people who generally share your beliefs cause it seems 
> > you're significantly outnumbered as it is.
> >
> > Now if you'd like to respond without the obligatory disdain and actually 
> > explain something, my questions was: "Is Intel ME/AMT able to bypass 
> > firewalls that haven't been specifically configured to support those 
> > services?" This entry: 
> > https://en.wikipedia.org/wiki/Intel_Active_Management_Technology#Communication
> >  leads me to think that ME TCP/IP traffic isn't automatically 
> > passed-through, but like *I* said, I may have a 

[qubes-users] Re: Android-x86 on Qubes

[3n7r0py1]

On Monday, November 7, 2016 at 8:57:16 PM UTC, 3n7r...@gmail.com wrote:
> Using stock android-x86_64-6.0-r1.iso from android-x86.org (cm not tested)
> 
> Issues:
> 1. no boot
> 2. mouse support
> 3. wake from sleep
> 4. private storage
> 5. secure clipboard
> 
> 1. If HVM hangs priors to splash screen, try adding `vga=ask` to boot kernel 
> parameters. (1024x768x16 works for me)
> 
> 2. Mouse cursor needs to be dragged around inside vm. 
> Not aware of any workaround. 
> Previously reported: 
> https://groups.google.com/d/msg/qubes-users/2GAfjsltkmk/QY9fVetKKAAJ
> 
> 3. Can't figure out how to wake hvm from sleep. 
> Untested workaround: Disable sleep completely by adding: 
> "setprop sleep.state disabled" to /data/local.prop
> or "sleep.state=disabled" to /system/build.prop 
> (https://groups.google.com/d/msg/android-x86/8iSh5pVqv4U/Fz8Nh11UDwAJ)
> 
> 4. Is moving /home/ as simple as copying and editing fstab or are there 
> qubes-specific steps that need to be taken? If yes, would appreciate it if 
> someone could point me to qubes package that handles this.
> 
> 5. No clue. I hope someone is willing to work on this.

Forgot to mention that networking works out-of-the-box.

Also, it appears the mouse issue is solved here: 
https://groups.google.com/forum/#!searchin/android-x86/mouse$20issue|sort:date/android-x86/iFoKcvK2xNE/nYHoR6oSBgAJ

Will report back once I've had a chance to investigate.

-- 
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/e944b7b0-8058-4386-8db3-d26286221cbb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Android-x86 on Qubes

[3n7r0py1]

Using stock android-x86_64-6.0-r1.iso from android-x86.org (cm not tested)

Issues:
1. no boot
2. mouse support
3. wake from sleep
4. private storage
5. secure clipboard

1. If HVM hangs priors to splash screen, try adding `vga=ask` to boot kernel 
parameters. (1024x768x16 works for me)

2. Mouse cursor needs to be dragged around inside vm. 
Not aware of any workaround. 
Previously reported: 
https://groups.google.com/d/msg/qubes-users/2GAfjsltkmk/QY9fVetKKAAJ

3. Can't figure out how to wake hvm from sleep. 
Untested workaround: Disable sleep completely by adding: 
"setprop sleep.state disabled" to /data/local.prop
or "sleep.state=disabled" to /system/build.prop 
(https://groups.google.com/d/msg/android-x86/8iSh5pVqv4U/Fz8Nh11UDwAJ)

4. Is moving /home/ as simple as copying and editing fstab or are there 
qubes-specific steps that need to be taken? If yes, would appreciate it if 
someone could point me to qubes package that handles this.

5. No clue. I hope someone is willing to work on this.

-- 
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/8a849a2b-92e3-4be7-a54e-00290af811a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 3.2 - Whonix GW VM Update

[3n7r0py1]

On Saturday, October 29, 2016 at 2:18:35 AM UTC, Vincent Elliott wrote:
> Hi,
> 
> I am very new to Qubes.
> 
> In trying to update the Whonix GW VM, the updater reports that the file sizes 
> are different from what the server reports.  In every instance I have rolled 
> back the updates.
> 
> Is this normal?
> 
> Vincent

It's not normal in that it shouldn't be happenning. It is normal in that it is 
happening to everyone.
But no need for concern: 
https://forums.whonix.org/t/size-of-file-dists-jessie-main-binary-amd64-packages-gz-is-not-what-the-server-reported/3074/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/614722cd-e3ee-42f8-bc19-ad6ab154f18f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Creation of imsm container failes. Setting up Inter RST RAID array.

[3n7r0py1]

On Wednesday, September 14, 2016 at 3:42:02 PM UTC, Robert wrote:
> Hi!
> 
> I could use some help with setting up Intel hw raid array. I have two, 4 TB 
> drives that I want to use purely for storage (no booting) as a raid 1 array.
> I did manage to set them up as a software RAID using mdadm. However, I would 
> want the array to also be accessible from Windows 10 installation. AFAIK to 
> achieve this I need to use hardware RAID created in BIOS by Intel Rapid 
> Storage Technology (RST).
> 
> I tried to follow these instructions ([1] and [2]):
> $ sudo mdadm -C /dev/md/imsm /dev/sd[b-c] n 2 e imsm
> 
> It fails:
> mdadm: /dev/sdb is not suitable for this array
> mdadm: /dev/sdc is not suitable for this array
> mdadm: create aborted
> 
> Also this does not look good:
> $ sudo mdadm --detail-platform
> mdadm: imsm capabilities not found for controller: 
> /sys/devices/pci:00/:00:1f.2 (type SATA)
> 
> Some info about hardware:
> $ dmesg | grep 1f.2
> [2.677109] ahci 000:00:1j.2: version 3.0
> [2.677252] ahci 000:00:1j.2: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f 
> impl RAID mode
> [2.677254] ahci 000:00:1j.2: flags: 64bit ncq led clo pio slum part ems 
> apst
> 
> Controller is set to RAID mode in BIOS also, RAID array has been created 
> (VOLUME 1)
> 
> $ sudo mdadm --examine /dev/sdb
> 
> /dev/sdb:
> Magic : Intel Raid ISM Cfg Sig.
>   Version : 1.3.00
> Orig Family : 66247044
>Family : 66247044
>  Generation : 0002
>Attributes : All supported
>  UUID : e492be44:10b30ade:b642e816:dd60ca99
>  Checksum : 0f34c20c correct
>  MPB Sectors : 1
> Disks : 2
>  RAID Devices : 1
> 
>   Disk00 Serial : ***
>   State : active
>Id : 0002
> Usable Size : 7814031624 (3726.02 GiB 4000.78 GB)
> 
> [Volume1]:
>  UUID : 5d5fbe08:1c90e2f3:e7896bec:0c7ca70a
>  RAID Level : 1
>Members : 2
>  Slots : [UU]
>  Failed disk : none
> This Slot : 0
>  Array Size : 7814031360 (3726.02 GiB 4000.78 GB)
>   Per Dev Size : 7814031624 (3726.02 GiB 4000.78 GB)
>   Sector Offset : 0
>Num Stripes : 30523560
>  Chunk Size : 64 KiB
> Reserved : 0
>   Migrate State : idle
>   Map State : uninitialized
>  Dirty State : clean
> 
>   Disk01 Serial : ***
>   State : active
>Id : 0005
> Usable Size : 7814031624 (3726.02 GiB 4000.78 GB)
> 
> For /dev/sdc output of --examine is similar.
> 
> Hardware specs:
> mb: asrock z97 extreme4
> cpu: intel i5 4690
> 
> qubes-os: 3.2-rc3
> 
> Thanks in advance for all your help and suggestions on how to proceed.
> Robert
> 
> [1] 
> http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/rst-linux-paper.pdf
> [2] https://raid.wiki.kernel.org/index.php/RAID_setup#External_Metadata


IIUC you want to configure a raid device using your BIOS so it can be 
recognized by both Windows & Linux.

Read the intro here to confirm this is what you want:
https://help.ubuntu.com/community/FakeRaidHowto

Then go here to read all about Linux Raid (including a blistering critique of 
FakeRaid):
https://raid.wiki.kernel.org/index.php/Linux_Raid
(Another option that you may consider in the future is a separate file server.)

Fedora-23 should recognize Fake/BIOS-raid devices automatically. Sorry I don't 
have anything I can test with at the moment.

`sudo fdisk -l` should show /dev/sdb, /dev/sdc, as well as /dev/md[X].

If that's the case, you only need to configure partitions/volumes on your md 
device:

https://raid.wiki.kernel.org/index.php/Partitioning_RAID_/_LVM_on_RAID
https://www.howtoforge.com/linux_lvm

-- 
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/605456ba-6bb9-464b-8295-eb76b9bbcecb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Can't connect a VPN before Tor

[3n7r0py1]

On Tuesday, September 13, 2016 at 11:56:53 PM UTC, nishi...@gmail.com wrote:
> Le samedi 10 septembre 2016 20:36:38 UTC+2, 3n7r...@gmail.com a écrit :
> > [First, a rant. I hate mailing lists. How am I supposed to attribute quotes 
> > from earlier posts in the thread not contained in the previous post?]
> > 
> > nishi:
> > >Any advices on how to set up Qubes to have a VPN + sys-whonix working 
> > >together (or VPN + a TorVM proxy) in a good anonymous way would be really 
> > >appreciated :)
> > 
> > As you know, you can either connect to a VPN from a non-Whonix proxyVM or 
> > set up the VPN directly in the Whonix-Gateway. Both methods have the goal 
> > of preventing "unintentional" leaks and have the property of 
> > failing-closed. IMO, since you are using Qubes already, the proxyVM method 
> > is easier to configure and provides more flexibility. If you're short on 
> > RAM and/or need to operate multiple Whonix-Gateways with each having a 
> > separate VPN, you may be better off connecting to the VPN from within the 
> > Gateway. From a security/anonymity perspective, neither is obviously better 
> > than the other. A Gateway compromise would most likely be game-over in 
> > either scenario.
> > 
> > Speaking generally, you've got a whole bunch of moving parts. You need to 
> > troubleshoot by isolating each piece. 
> > 
> > **This step reveals that you use Tor. Only proceed if safe to do so.
> > 
> > 1. sys-net <- appVM: Do I have general connectivity?
> > 2. sys-net <- vpn-VM <- appVM: Does my VPN work?
> > 3.** sys-net <- appVM w/ Tor Browser Bundle: Does Tor work?
> > 4.** sys-net <- whonix-gateway: Run whonixcheck. Does Whonix-Gateway work?
> > 5. sys-net <- vpn-vm <- whonix-gateway
> > 
> > My suggestion is to start with a fresh proxyVM and follow Chris' Qubes VPN 
> > documentation step by step. (Or take a look at his [git 
> > repo](https://github.com/ttasket/Qubes-vpn-support) ). If the vpn-VM allows 
> > successful connections from the appVM, then it's simply a matter of 
> > assigning it to the Whonix-Gateway as its netVM. No Whonix-specific 
> > configuration is necessary since it's all transparent to Whonix.
> > 
> > * Make sure that the Qubes firewall (Qubes VM Manager) is open on the 
> > Whonix-Gateway. I don't remember what the default setting is.
> > 
> > * Both TCP and UDP are fine for upstream VPNs. Tor can not carry UDP but it 
> > can be carried on UDP, if that makes sense.
> > 
> > * Don't add any additional firewalls until you can get this working.
> > 
> > 
> > nishi:
> > >Which gives in Qubes something a pattern like this one below (I don't know 
> > >if all firewall VMs are really needed though) :
> > >
> > >AppVM => sys-vpn-firewall => sys-vpn => sys-whonix-firewall (or 
> > >TorVM-firewall) => sys-whonix (or TorVM) => sys-firewall => sys-net
> > 
> > Firewalls have limited usefulness as described here: 
> > https://www.qubes-os.org/doc/data-leaks/
> > 
> > rustybird's Corridor can ensure that all traffic goes to a Tor Entry Guard 
> > (but obviously, can't guarantee that the Entry Guard is trustworthy).
> > 
> > 
> > nishi:
> > >When I purchased a VPN subscription, I saw it as a way to improve 
> > >anonymity, now I feel it is more a tool to provide security.
> > 
> > VPNs don't necessarily improve anonymity OR security. They simply shift the 
> > trust that you place in your ISP to someone else. That may be good or bad.
> > 
> > 
> > Chris:
> > >Although its straightforward to get the opposite working (Tor -> VPN ->
> > Internet -- just follow the Qubes vpn doc and connect sys-whonix to the
> > vpn vm)
> > 
> > Just to clarify, to achieve user -> Tor -> VPN -> Internet, sys-whonix 
> > needs to be connected as the *netVM* for the vpn-vm. If vpn-vm is the netVM 
> > for sys-whonix, the resulting traffic is user -> VPN -> Tor -> Internet. I 
> > may be forgetting something, but I believe both configurations work out of 
> > the box.
> 
> Hello,
> 
> Thank you for your answer. Yes I agree with you, the proxyVM is easier to 
> configure and provide more flexibility. I don't know if you can make your VPN 
> autostart if you install it inside the whonix gateway, so I rather prefer to 
> have it directly installed in an AppVM, because I find it is a great Qubes 
> feature : )
> 
> Also as I said directly in the Whonix-forum site, I don't believe building a 
> fortress in a gateway that will become the main target for hackers is what 
> will necessarily will make us all more secure out there. Whonix or Qubes are 
> targets right now... You have too many hacking intrusion exploits nowadays to 
> build a fail-safe system for everyone. If you just type list in metasploit on 
> kali Linux you know what I mean... I feel like people working on Whonix would 
> be a really more usefull to random noobs like me and most of the internet 
> community by trying to act like hackers, idea being to create a code able to 
> send back nukes to people entering your own private space. I see 

[qubes-users] Re: Windows + QWT 3.2 on Qubes R3.1 Test Notes

[3n7r0py1]

On Tuesday, September 13, 2016 at 5:21:35 PM UTC, 3n7r...@gmail.com wrote:
> On Tuesday, September 13, 2016 at 5:16:48 PM UTC, 3n7r...@gmail.com wrote:
> > On Tuesday, September 13, 2016 at 12:23:15 AM UTC, 3n7r...@gmail.com wrote:
> > > On Sunday, September 11, 2016 at 12:30:42 PM UTC, Marek 
> > > Marczykowski-Górecki wrote:
> > > > I haven't tested this version on 3.1, but I think it should work. Just
> > > > uploaded to current-testing.
> > > 
> > > Thanks!
> > > 
> > > Everything I tested is flawless **until the #updates stage**.
> > > 
> > > =
> > > 
> > > installation: no issues (up to #updates - see below)
> > > 
> > > multi-monitor: not tested
> > > tested resolution: 4 megapixels
> > > seamless mode: working
> > > full desktop mode: working
> > > 
> > > secure clipboard: working
> > > private storage: working
> > > qvm-block: working
> > > qvm-run: working
> > > qvm-open-in-vm: working
> > > qvm-copy-to-vm: working
> > > auto-networking: working
> > > 
> > > =
> > > 
> > > Test Procedure
> > > 
> > > #install windows
> > > 
> > > QubesVMM: create templateHVM: "win-7"
> > > netVM: none; vCPU: 4; RAM: 4GB
> > > Private Storage: 10GB; System Storage: 40GB
> > > 
> > > qvm-start win-7 --cdrom=appVM:/path/to/iso
> > > iso=en_windows_7_professional_with_sp1_x64_dvd_u_676939.iso
> > > 
> > > disable UAC
> > > disable updates
> > > enable auto-logon
> > > bcdedit /set testsigning on
> > > shutdown
> > > 
> > > #install QWT
> > > 
> > > qubes-dom0-update --enablerepo=qubes-dom0-current-testing 
> > > qubes-windows-tools
> > > clone win-7 to win-7-qwt-1, win-7-qwt-2
> > > 
> > > for each qwt clone:
> > > qvm-prefs -s win-7-qwt-? qrexec_timeout 600
> > > qvm-start win-7-qwt-? --install-windows-tools
> > > 
> > > [note re: PV disk drivers. For my first test (with just 1 vm), I disabled 
> > > PV disk drivers and experienced 5-6 bsod's and/or permanent yellow hangs. 
> > > No idea if there is any causality there. Reason for enabling PV disk is 
> > > that installing .Net package required 30 minutes just to see any movement 
> > > in the progress bar. (Might not all be due to PV disk - slowness might be 
> > > causing other things to timeout?) With PV disk enabled, the update took 
> > > less than 10 secs. I might guess that many bug reports are due to the 
> > > INSANELY slow non-PV disk ops being mistaken for system hangs... To be 
> > > fair, Virtualbox similarly has bad disk performance prior to installing 
> > > Guest Additions. Surprisingly, no issues at all installing PV disk.]
> > > 
> > > #update Windows **Problems here**
> > > 
> > > wsusoffline update
> > > 
> > > [future steps:
> > >   enable netVM
> > >   windows activation
> > >   windows update
> > > ]
> > > 
> > > =
> > > 
> > > Made it to the end of the offline update process with 2 identical clones 
> > > following the exact same procedure. One boots and is ready to go. The 
> > > other received dom0 notice about outdated GUI protocol. Will not complete 
> > > boot after repeated attempts. I can't make any sense of the logs - can't 
> > > even figure out which ones are relevant. Just to rule out any difference 
> > > in procedure that I might have overlooked, I have trashed both clones and 
> > > brought 2 fresh clones to just prior to the update process. Please let me 
> > > know how to proceed, ie which logs to collect.
> > > 
> > > One oddity that I noticed was that the Qubes VM Window name doesn't 
> > > appear to be consistent. For example, with a Windows TemplateHVM named 
> > > "win-7" and a user/domain of user@host; the name of the Windows window 
> > > will alternate? between "[win-7] win-7" and "[win-7] host". Is this 
> > > noteworthy at all?
> > > 
> > > I don't envy you Rafał. Thanks for working on this.
> > 
> > 
> > So currently, I have 2 Windows HVM Templates, named win7-qwt1 & win7-qwt2. 
> > They were installed with networking off so they should be identical. QWT 
> > (complete install) was installed without any errors.
> > 
> > I've been starting and shutting down each of them repeatedly with these 
> > results (Qubes logs attached):
> > 
> > win7-qwt1-1-fail: no desktop loaded; hanging on yellow state
> > win7-qwt1-2-success: successful boot to desktop
> > win7-qwt1-3-fail: no desktop; qrexec error
> > win7-qwt1-4 success: successful boot to desktop
> > (no logs) #5: success; bsod on shutdown (max cpu) (named "win7-qwt1")
> > (no logs) #6: success (named "host")
> > (no logs) #7: success (named "host")
> > 
> > win7-qwt2-1-success
> > win7-qwt2-2-fail: hanging yellow
> > win7-qwt2-3-success
> > (no logs) #4: fail
> > (no logs) #5: fail
> > (no logs) #6: success (named "host")
> > (no logs) #7: fail
> > (no logs) #8: fail
> > (no logs) #9: success (named "win7-qwt2")
> > 
> > As stated before, the VM window title is unpredictable - sometimes, the 
> > window is named "[win7-qwt1] win7-qwt1" and sometimes it's "[win7-qwt1] 
> > 

[qubes-users] Re: Windows + QWT 3.2 on Qubes R3.1 Test Notes

[3n7r0py1]

On Tuesday, September 13, 2016 at 5:16:48 PM UTC, 3n7r...@gmail.com wrote:
> On Tuesday, September 13, 2016 at 12:23:15 AM UTC, 3n7r...@gmail.com wrote:
> > On Sunday, September 11, 2016 at 12:30:42 PM UTC, Marek 
> > Marczykowski-Górecki wrote:
> > > I haven't tested this version on 3.1, but I think it should work. Just
> > > uploaded to current-testing.
> > 
> > Thanks!
> > 
> > Everything I tested is flawless **until the #updates stage**.
> > 
> > =
> > 
> > installation: no issues (up to #updates - see below)
> > 
> > multi-monitor: not tested
> > tested resolution: 4 megapixels
> > seamless mode: working
> > full desktop mode: working
> > 
> > secure clipboard: working
> > private storage: working
> > qvm-block: working
> > qvm-run: working
> > qvm-open-in-vm: working
> > qvm-copy-to-vm: working
> > auto-networking: working
> > 
> > =
> > 
> > Test Procedure
> > 
> > #install windows
> > 
> > QubesVMM: create templateHVM: "win-7"
> > netVM: none; vCPU: 4; RAM: 4GB
> > Private Storage: 10GB; System Storage: 40GB
> > 
> > qvm-start win-7 --cdrom=appVM:/path/to/iso
> > iso=en_windows_7_professional_with_sp1_x64_dvd_u_676939.iso
> > 
> > disable UAC
> > disable updates
> > enable auto-logon
> > bcdedit /set testsigning on
> > shutdown
> > 
> > #install QWT
> > 
> > qubes-dom0-update --enablerepo=qubes-dom0-current-testing 
> > qubes-windows-tools
> > clone win-7 to win-7-qwt-1, win-7-qwt-2
> > 
> > for each qwt clone:
> > qvm-prefs -s win-7-qwt-? qrexec_timeout 600
> > qvm-start win-7-qwt-? --install-windows-tools
> > 
> > [note re: PV disk drivers. For my first test (with just 1 vm), I disabled 
> > PV disk drivers and experienced 5-6 bsod's and/or permanent yellow hangs. 
> > No idea if there is any causality there. Reason for enabling PV disk is 
> > that installing .Net package required 30 minutes just to see any movement 
> > in the progress bar. (Might not all be due to PV disk - slowness might be 
> > causing other things to timeout?) With PV disk enabled, the update took 
> > less than 10 secs. I might guess that many bug reports are due to the 
> > INSANELY slow non-PV disk ops being mistaken for system hangs... To be 
> > fair, Virtualbox similarly has bad disk performance prior to installing 
> > Guest Additions. Surprisingly, no issues at all installing PV disk.]
> > 
> > #update Windows **Problems here**
> > 
> > wsusoffline update
> > 
> > [future steps:
> >   enable netVM
> >   windows activation
> >   windows update
> > ]
> > 
> > =
> > 
> > Made it to the end of the offline update process with 2 identical clones 
> > following the exact same procedure. One boots and is ready to go. The other 
> > received dom0 notice about outdated GUI protocol. Will not complete boot 
> > after repeated attempts. I can't make any sense of the logs - can't even 
> > figure out which ones are relevant. Just to rule out any difference in 
> > procedure that I might have overlooked, I have trashed both clones and 
> > brought 2 fresh clones to just prior to the update process. Please let me 
> > know how to proceed, ie which logs to collect.
> > 
> > One oddity that I noticed was that the Qubes VM Window name doesn't appear 
> > to be consistent. For example, with a Windows TemplateHVM named "win-7" and 
> > a user/domain of user@host; the name of the Windows window will alternate? 
> > between "[win-7] win-7" and "[win-7] host". Is this noteworthy at all?
> > 
> > I don't envy you Rafał. Thanks for working on this.
> 
> 
> So currently, I have 2 Windows HVM Templates, named win7-qwt1 & win7-qwt2. 
> They were installed with networking off so they should be identical. QWT 
> (complete install) was installed without any errors.
> 
> I've been starting and shutting down each of them repeatedly with these 
> results (Qubes logs attached):
> 
> win7-qwt1-1-fail: no desktop loaded; hanging on yellow state
> win7-qwt1-2-success: successful boot to desktop
> win7-qwt1-3-fail: no desktop; qrexec error
> win7-qwt1-4 success: successful boot to desktop
> (no logs) #5: success; bsod on shutdown (max cpu) (named "win7-qwt1")
> (no logs) #6: success (named "host")
> (no logs) #7: success (named "host")
> 
> win7-qwt2-1-success
> win7-qwt2-2-fail: hanging yellow
> win7-qwt2-3-success
> (no logs) #4: fail
> (no logs) #5: fail
> (no logs) #6: success (named "host")
> (no logs) #7: fail
> (no logs) #8: fail
> (no logs) #9: success (named "win7-qwt2")
> 
> As stated before, the VM window title is unpredictable - sometimes, the 
> window is named "[win7-qwt1] win7-qwt1" and sometimes it's "[win7-qwt1] 
> host". This is true of both vm's. A race condition? I am inclined to suggest 
> that the VMs function more properly when they are named "host". Also, after 
> all the starts and stops, I've got a leftover VM window that wasn't cleaned 
> up properly and can't be closed.

-- 
You received this message because you are subscribed to 

[qubes-users] Re: Windows + QWT 3.2 on Qubes R3.1 Test Notes

[3n7r0py1]

On Tuesday, September 13, 2016 at 12:23:15 AM UTC, 3n7r...@gmail.com wrote:
> On Sunday, September 11, 2016 at 12:30:42 PM UTC, Marek Marczykowski-Górecki 
> wrote:
> > I haven't tested this version on 3.1, but I think it should work. Just
> > uploaded to current-testing.
> 
> Thanks!
> 
> Everything I tested is flawless **until the #updates stage**.
> 
> =
> 
> installation: no issues (up to #updates - see below)
> 
> multi-monitor: not tested
> tested resolution: 4 megapixels
> seamless mode: working
> full desktop mode: working
> 
> secure clipboard: working
> private storage: working
> qvm-block: working
> qvm-run: working
> qvm-open-in-vm: working
> qvm-copy-to-vm: working
> auto-networking: working
> 
> =
> 
> Test Procedure
> 
> #install windows
> 
> QubesVMM: create templateHVM: "win-7"
> netVM: none; vCPU: 4; RAM: 4GB
> Private Storage: 10GB; System Storage: 40GB
> 
> qvm-start win-7 --cdrom=appVM:/path/to/iso
> iso=en_windows_7_professional_with_sp1_x64_dvd_u_676939.iso
> 
> disable UAC
> disable updates
> enable auto-logon
> bcdedit /set testsigning on
> shutdown
> 
> #install QWT
> 
> qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools
> clone win-7 to win-7-qwt-1, win-7-qwt-2
> 
> for each qwt clone:
> qvm-prefs -s win-7-qwt-? qrexec_timeout 600
> qvm-start win-7-qwt-? --install-windows-tools
> 
> [note re: PV disk drivers. For my first test (with just 1 vm), I disabled PV 
> disk drivers and experienced 5-6 bsod's and/or permanent yellow hangs. No 
> idea if there is any causality there. Reason for enabling PV disk is that 
> installing .Net package required 30 minutes just to see any movement in the 
> progress bar. (Might not all be due to PV disk - slowness might be causing 
> other things to timeout?) With PV disk enabled, the update took less than 10 
> secs. I might guess that many bug reports are due to the INSANELY slow non-PV 
> disk ops being mistaken for system hangs... To be fair, Virtualbox similarly 
> has bad disk performance prior to installing Guest Additions. Surprisingly, 
> no issues at all installing PV disk.]
> 
> #update Windows **Problems here**
> 
> wsusoffline update
> 
> [future steps:
>   enable netVM
>   windows activation
>   windows update
> ]
> 
> =
> 
> Made it to the end of the offline update process with 2 identical clones 
> following the exact same procedure. One boots and is ready to go. The other 
> received dom0 notice about outdated GUI protocol. Will not complete boot 
> after repeated attempts. I can't make any sense of the logs - can't even 
> figure out which ones are relevant. Just to rule out any difference in 
> procedure that I might have overlooked, I have trashed both clones and 
> brought 2 fresh clones to just prior to the update process. Please let me 
> know how to proceed, ie which logs to collect.
> 
> One oddity that I noticed was that the Qubes VM Window name doesn't appear to 
> be consistent. For example, with a Windows TemplateHVM named "win-7" and a 
> user/domain of user@host; the name of the Windows window will alternate? 
> between "[win-7] win-7" and "[win-7] host". Is this noteworthy at all?
> 
> I don't envy you Rafał. Thanks for working on this.


So currently, I have 2 Windows HVM Templates, named win7-qwt1 & win7-qwt2. They 
were installed with networking off so they should be identical. QWT (complete 
install) was installed without any errors.

I've been starting and shutting down each of them repeatedly with these results 
(Qubes logs attached):

win7-qwt1-1-fail: no desktop loaded; hanging on yellow state
win7-qwt1-2-success: successful boot to desktop
win7-qwt1-3-fail: no desktop; qrexec error
win7-qwt1-4 success: successful boot to desktop
(no logs) #5: success; bsod on shutdown (max cpu) (named "win7-qwt1")
(no logs) #6: success (named "host")
(no logs) #7: success (named "host")

win7-qwt2-1-success
win7-qwt2-2-fail: hanging yellow
win7-qwt2-3-success
(no logs) #4: fail
(no logs) #5: fail
(no logs) #6: success (named "host")
(no logs) #7: fail
(no logs) #8: fail
(no logs) #9: success (named "win7-qwt2")

As stated before, the VM window title is unpredictable - sometimes, the window 
is named "[win7-qwt1] win7-qwt1" and sometimes it's "[win7-qwt1] host". This is 
true of both vm's. A race condition? I am inclined to suggest that the VMs 
function more properly when they are named "host". Also, after all the starts 
and stops, I've got a leftover VM window that wasn't cleaned up properly and 
can't be closed.

-- 
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] Current Windows instructions?

[3n7r0py1]

On Wednesday, August 17, 2016 at 12:43:27 AM UTC, Andrew David Wong wrote:
> 
> So, as Marek said, in this particular case, the updated package has already 
> been
> uploaded to the testing repo for 3.2. If you're on R3.2, and if you're willing
> to test this package (and you're certainly under no obligation to do so), then
> you can do so now by following the instructions here (under "Testing
> repositories"):
> 
> https://www.qubes-os.org/doc/software-update-dom0/#tocAnchor-1-1-3
> 
> I believe the correct repo is current-testing. If so, your command would be:
> 
> $ sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing 
> 
> If this is, indeed, the right place, then you can see a list of available
> packages here (or from the command line):
> 
> http://yum.qubes-os.org/r3.2/current-testing/dom0/fc23/rpm/
> 
> The only packages containing the word "windows" are different versions of
> qubes-windows-tools, so I gather this is what you want. If that's correct,
> then the command would be:
> 
> $ sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing \
> qubes-windows-tools
> 


Andrew, I don't see qubes-windows-tools 3.2.x in the R3.1-current-testing repo. 
Is that an oversight or is QWT 3.04 the last update for R3.1? I wouldn't expect 
R3.1 to get any new features but if QWT3.2 is improving stability, it'd be 
great to get it if possible.

-- 
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/c842d6f8-d14f-4dcb-8893-809d7f8d26dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Can't connect a VPN before Tor

[3n7r0py1]

[First, a rant. I hate mailing lists. How am I supposed to attribute quotes 
from earlier posts in the thread not contained in the previous post?]

nishi:
>Any advices on how to set up Qubes to have a VPN + sys-whonix working together 
>(or VPN + a TorVM proxy) in a good anonymous way would be really appreciated :)

As you know, you can either connect to a VPN from a non-Whonix proxyVM or set 
up the VPN directly in the Whonix-Gateway. Both methods have the goal of 
preventing "unintentional" leaks and have the property of failing-closed. IMO, 
since you are using Qubes already, the proxyVM method is easier to configure 
and provides more flexibility. If you're short on RAM and/or need to operate 
multiple Whonix-Gateways with each having a separate VPN, you may be better off 
connecting to the VPN from within the Gateway. From a security/anonymity 
perspective, neither is obviously better than the other. A Gateway compromise 
would most likely be game-over in either scenario.

Speaking generally, you've got a whole bunch of moving parts. You need to 
troubleshoot by isolating each piece. 

**This step reveals that you use Tor. Only proceed if safe to do so.

1. sys-net <- appVM: Do I have general connectivity?
2. sys-net <- vpn-VM <- appVM: Does my VPN work?
3.** sys-net <- appVM w/ Tor Browser Bundle: Does Tor work?
4.** sys-net <- whonix-gateway: Run whonixcheck. Does Whonix-Gateway work?
5. sys-net <- vpn-vm <- whonix-gateway

My suggestion is to start with a fresh proxyVM and follow Chris' Qubes VPN 
documentation step by step. (Or take a look at his [git 
repo](https://github.com/ttasket/Qubes-vpn-support) ). If the vpn-VM allows 
successful connections from the appVM, then it's simply a matter of assigning 
it to the Whonix-Gateway as its netVM. No Whonix-specific configuration is 
necessary since it's all transparent to Whonix.

* Make sure that the Qubes firewall (Qubes VM Manager) is open on the 
Whonix-Gateway. I don't remember what the default setting is.

* Both TCP and UDP are fine for upstream VPNs. Tor can not carry UDP but it can 
be carried on UDP, if that makes sense.

* Don't add any additional firewalls until you can get this working.


nishi:
>Which gives in Qubes something a pattern like this one below (I don't know if 
>all firewall VMs are really needed though) :
>
>AppVM => sys-vpn-firewall => sys-vpn => sys-whonix-firewall (or 
>TorVM-firewall) => sys-whonix (or TorVM) => sys-firewall => sys-net

Firewalls have limited usefulness as described here: 
https://www.qubes-os.org/doc/data-leaks/

rustybird's Corridor can ensure that all traffic goes to a Tor Entry Guard (but 
obviously, can't guarantee that the Entry Guard is trustworthy).


nishi:
>When I purchased a VPN subscription, I saw it as a way to improve anonymity, 
>now I feel it is more a tool to provide security.

VPNs don't necessarily improve anonymity OR security. They simply shift the 
trust that you place in your ISP to someone else. That may be good or bad.


Chris:
>Although its straightforward to get the opposite working (Tor -> VPN ->
Internet -- just follow the Qubes vpn doc and connect sys-whonix to the
vpn vm)

Just to clarify, to achieve user -> Tor -> VPN -> Internet, sys-whonix needs to 
be connected as the *netVM* for the vpn-vm. If vpn-vm is the netVM for 
sys-whonix, the resulting traffic is user -> VPN -> Tor -> Internet. I may be 
forgetting something, but I believe both configurations work out of the box.


-- 
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/8ab52f16-0a3a-4acf-bcc7-ed6153ded7c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Networking between Linux and Windows VMs

[3n7r0py1]

On Monday, September 5, 2016 at 10:23:42 PM UTC, Daniel Wilcox wrote:
> Hi Micah, you're taking the opposite the usual strategy I do on my extra 
> firewall vms -- by adding a rule rather than removing one.  Could you try on 
> the appropriate firewall vm:
> 
> iptables -D FORWARD 3  # where rule 3 should be the rule to drop all packets 
> between the vif interfaces
> 

Before opening up your firewallVM, please narrow down the issue to either the 
firewallVM or dev_win10 by completely disabling Windows Firewall. It's 
questionable whether you're gaining any protection from Windows Firewall anyway 
(wrt Qubes philosophy).

Go to Control Panel > Windows Firewall > Turn Windows Firewall on or off:

First, confirm that `Block all incoming connections` is unchecked! As a 
paranoid user, you might have set this and then forgotten.

Then, `Turn off Windows Firewall` for *both* profiles. No reboot. Initiate RDP 
session from dev.


> This should be equivalent to what you're doing but might be worth a check.  
> Also I'm sure you've noticed whenever the firewall vm has a change to its 
> rules, it'll reload and we have to re-execute this (anyone have ideas for 
> that btw?).

https://www.qubes-os.org/doc/qubes-firewall/#tocAnchor-1-1-4
(see "qubes-firewall-user-script")

-- 
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/7d0c4c13-3460-4fdc-b206-bd754d5cafb8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[3n7r0py1]

On Saturday, August 27, 2016 at 2:49:52 PM UTC, johny...@sigaint.org wrote:
> >> Whether using an "isolating proxy" (multiple machines) or not, using a
> >> white-listing proxy like Corridor can help ensure all of your traffic
> >> passes through Tor (Entry Guard, at least).
> >>
> >
> > That's right. Also, using Firefox with those extensions is *not* the same
> > as
> > using Tor Browser:
> 
> Understood.  I do take a few more precautions (with iptables, bridges,
> etc.) but Torbrowser certainly does take care of a lot of important things
> for you.
> 
> > https://www.torproject.org/projects/torbrowser/design/
> 
> Wow, that's a great resource, thanks!
> 
> I think I still prefer to "roll my own" versus using TBB.  (And that link
> is great for tips on doing that.)
> 
> There are four (probably reasonable and legitimate) things about TBB (and
> tails) that are red flags to my overly-paranoid mind:
> 
> 1) Not a problem in Tails (being a bit "read-only), but the normal
> Torbrowser Bundle is very stubborn about doing an update check every time
> it starts.  I understand the reasoning behind it, keeping up with 0days as
> they're discovered, and at least one exploit in the past would have been
> avoided by anybody who stayed updated.
> 
> Sure, notify me, but forcing that "phone home" on every start is a bit too
> much like MS-style tracking to me.
> 
> I could be wrong (I often am), but even turning off the update check in
> settings didn't seem to work for me.  Although I might have screwed up
> somehow or it might have been an artifact of non-persistence in an AppVM.
> Having that update check/download on by default, I don't like.
> 
> Finding the actual tor browser binary to launch is a major pain.  It
> almost seems intentionally hidden.  :)
> 
> 2) JavaScript on by default.  I understand the convenience for the general
> public, but TBB isn't really for the general public but the
> security-conscious.  And the security-conscious shouldn't turn on JS
> unless necessary.  (And with Qubes, one can keep their JS-dependant sites
> to a separate VM, whoohoo!)
> 
> In Tails, having JS on plus automatically loading Tails home page (which
> could be subverted by someone with CA ability) is a bit of a risk, IMO.
> To avoid having a JS-enabled load of the Tails home page, you have to
> start it without networking, disable things, then enable networking.
> Blah.
> 
> 3) Default search engine set to Disconnect.me.  And disconnect.me seems to
> do nothing but redirect your search to duckduckgo.  Why are they even in
> the loop then?  Supposedly they financially support the tor project.  So a
> company founded by a former NSA person paid money to be able to capture
> all the searches that are eventually done by DDG in TBB/Tails.  Oky...
> 
> Whenever I do launch Torbrowser, the first two things I do is disable
> global javascript, and change the default search provider.
> 
> 4) It's not really fair to include this one, as I have nothing to back it
> up with, but I remember something in the past that made me a bit uneasy
> about Torbutton.  I'll follow up if I can remember/find my concern.
> 
> Interested in hearing others opinions on those points.
> 
> Cheers.
> 
> JJ


Those are fair points. In fact, I deal with those complaints every time I 
install a new Tor Browser.

1. Automated updates: I set it to notify only - just because I don't want to be 
interrupted / surprised - not because I don't trust TPO or the update process. 
If you're worried about eavesdropping or metadata scavenging, this is not the 
same as MS phoning home because you can check the source and build it yourself.

2. Javascript on by default. I turn it off or set security to 'high'.

3. Disconnect.me default search. I change it to something else.

4. Not sure if this is your concern but TorButton works through Tor's Control 
Port. There exists a Tor control command called GETINFO that will retrieve the 
real public IP of your Tor client. In Whonix, these commands are filtered by 
the Control Port Filter Proxy. The control port can optionally be disabled 
entirely. This approach is much safer than using the Tor Browser Bundle on its 
own. I don't know how Tails addresses this.

As to your inclination to "roll your own" privacy browser, there are 2 things 
you might want to consider:

1. In general, security software (and anything involving cryptography) is best 
tackled as a community. No matter how brilliant you might be, one error is all 
it takes to render the whole solution dangerous. More eyes the better.

2. Unless you replicate Tor Browser *exactly* (why roll your own if you're 
going to do that?), you will likely have a fantastically unique fingerprint 
that will identify you anywhere you go on the Internet, regardless of however 
many anonymous proxies you sit behind. Browser fingerprints can not be 
eliminated completely. Instead of trying to hide, Tor Browser sets a public 
fingerprint that all users can share. As in #1, having a 

Re: [qubes-users] Unable to Remove Template / Preun: Domain not found

[3n7r0py1]

> > Maybe better question is, why was the template installed to begin with when
> > I opted out of any initial configuration?
> > 
> 
> That's a known bug, recently fixed:
> 
> https://github.com/QubesOS/qubes-issues/issues/2105

I'm getting quite good at finding bugs - six months after the fact. :/

-- 
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/4b602ae6-2d62-4216-8d11-1dd8cd9a85de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Unable to Remove Template / Preun: Domain not found

[3n7r0py1]

On Thursday, August 18, 2016 at 7:04:01 PM UTC, 3n7r...@gmail.com wrote:
> On Thursday, August 18, 2016 at 5:41:58 AM UTC, Andrew David Wong wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > On 2016-08-17 12:17, entr0py wrote:
> > > New Qubes 3.1 installation with Advanced (No Configuration)
> > > option.
> > > 
> > > After restoring dom0 + serviceVMs + serviceTemplates, tried to 
> > > `sudo yum remove qubes-template-fedora-23`
> > > 
> > > Received: Error in PREUN scriptlet in rpm package... 
> > > libvirt.libvirtError: Domain not found [from libvirt.py line 4066
> > > lookupByName]
> > > 
> > > `sudo yum list qubes-template-fedora-23` shows template installed
> > > from @anaconda/R3.1 repo.
> > > 
> > > `sudo qubes-dom0-update qubes-template-fedora-23` returns "No Match
> > > for argument qubes-template-fedora-23"
> > > 
> > > Thanks for help.
> > > 
> > 
> > Just a quick check: If you do "qvm-prefs -l fedora-23" (in dom0), is
> > the value for installed_by_rpm "True"?
> > 
> > - -- 
> > Andrew David Wong (Axon)
> > Community Manager, Qubes OS
> > https://www.qubes-os.org
> > -BEGIN PGP SIGNATURE-
> > 
> > iQIcBAEBCgAGBQJXtUqHAAoJENtN07w5UDAwelUQALeJbgBQc/IHuqOldGA4P3kS
> > Cq8fsWe9pqQiTWDWUP2HMPEcONXkxEHbq3PdZofYkiyBkDlBLu58F1a7cTFgGpfU
> > ToS+DK2od1Cax9rKKLnUef2LYE5BpMGsNn7QEdOt6xZPCeluRlANIm4kMDWkLTFP
> > xzgWpjZ1SwhQF1ahv6vMGq0V+NjMujP8ecvR85P5JVTABvEQSnhhasu5qB/qUl7e
> > PtRuR3KncS2dURBxLEiUew+I+nWkW65lARX5X/OB2lYu2TeOT9CWSkjzfllacTtH
> > KVDJE9nL3TnKpYt0h2e2qrka5XjeGkzi1K1cxcBXZqWkz5gd397W0Xcz5fBn3Vgl
> > aYs53VnvM5aAZemqa5+vYEATCRHB1ourRSddWYTIDKEI2gtfEu0j4eDwG8ZTL8gR
> > CdTxzEGHrZLEoxNdata8L/p4FiCgW8YHFOQg1n5H6n6PTQwYr3jJty1nYMfvXWr0
> > +Tbv5uQTPFa22oiOVEHJQ3yrHjeSv85KPf/8S25WhffPMImn0oMMOUUDcioG28c5
> > jw9037MWER0c5fsjrBOewvlUnyldXILhPa+3ZQvWJvTKtFpsUoucM7skDej8Ugn3
> > TLoShOqcpsq8UQiOTB5NtkhwTbfnBwWVHsSpGaiMzC9zZclCGv2p8w2J6rvjJVlh
> > 5HNY970p/HtWs1JTNpOa
> > =CQ+x
> > -END PGP SIGNATURE-
> 
> 
> Yes, `installed_by_rpm : True`
> 
> Does this have to do with the fact that the template was installed by the 
> installer without any pre-configuration?
> 
> Is the preun script necessary? Can't find the thread where Marek suggested 
> --no-script...
> 
> Or maybe some way to reset rpm?

Duh. Issue resolved.

The template needs to be updated! before it can be removed... Seems odd, but 
given the interplay between templates & dom0, I guess it's not that surprising. 

Maybe better question is, why was the template installed to begin with when I 
opted out of any initial configuration?

-- 
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/b7e9584d-89ea-40f1-af9b-d0dade1035c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Unable to Remove Template / Preun: Domain not found

[3n7r0py1]

On Thursday, August 18, 2016 at 5:41:58 AM UTC, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2016-08-17 12:17, entr0py wrote:
> > New Qubes 3.1 installation with Advanced (No Configuration)
> > option.
> > 
> > After restoring dom0 + serviceVMs + serviceTemplates, tried to 
> > `sudo yum remove qubes-template-fedora-23`
> > 
> > Received: Error in PREUN scriptlet in rpm package... 
> > libvirt.libvirtError: Domain not found [from libvirt.py line 4066
> > lookupByName]
> > 
> > `sudo yum list qubes-template-fedora-23` shows template installed
> > from @anaconda/R3.1 repo.
> > 
> > `sudo qubes-dom0-update qubes-template-fedora-23` returns "No Match
> > for argument qubes-template-fedora-23"
> > 
> > Thanks for help.
> > 
> 
> Just a quick check: If you do "qvm-prefs -l fedora-23" (in dom0), is
> the value for installed_by_rpm "True"?
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> -BEGIN PGP SIGNATURE-
> 
> iQIcBAEBCgAGBQJXtUqHAAoJENtN07w5UDAwelUQALeJbgBQc/IHuqOldGA4P3kS
> Cq8fsWe9pqQiTWDWUP2HMPEcONXkxEHbq3PdZofYkiyBkDlBLu58F1a7cTFgGpfU
> ToS+DK2od1Cax9rKKLnUef2LYE5BpMGsNn7QEdOt6xZPCeluRlANIm4kMDWkLTFP
> xzgWpjZ1SwhQF1ahv6vMGq0V+NjMujP8ecvR85P5JVTABvEQSnhhasu5qB/qUl7e
> PtRuR3KncS2dURBxLEiUew+I+nWkW65lARX5X/OB2lYu2TeOT9CWSkjzfllacTtH
> KVDJE9nL3TnKpYt0h2e2qrka5XjeGkzi1K1cxcBXZqWkz5gd397W0Xcz5fBn3Vgl
> aYs53VnvM5aAZemqa5+vYEATCRHB1ourRSddWYTIDKEI2gtfEu0j4eDwG8ZTL8gR
> CdTxzEGHrZLEoxNdata8L/p4FiCgW8YHFOQg1n5H6n6PTQwYr3jJty1nYMfvXWr0
> +Tbv5uQTPFa22oiOVEHJQ3yrHjeSv85KPf/8S25WhffPMImn0oMMOUUDcioG28c5
> jw9037MWER0c5fsjrBOewvlUnyldXILhPa+3ZQvWJvTKtFpsUoucM7skDej8Ugn3
> TLoShOqcpsq8UQiOTB5NtkhwTbfnBwWVHsSpGaiMzC9zZclCGv2p8w2J6rvjJVlh
> 5HNY970p/HtWs1JTNpOa
> =CQ+x
> -END PGP SIGNATURE-


Yes, `installed_by_rpm : True`

Does this have to do with the fact that the template was installed by the 
installer without any pre-configuration?

Is the preun script necessary? Can't find the thread where Marek suggested 
--no-script...

Or maybe some way to reset rpm?


-- 
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/4472a3cf-4a4c-4456-972b-be2ed01871d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Missing config files after Backup / Restore

[3n7r0py1]

> So I took kwinrulesrc from the old system and copied it right into the new 
> system manually with no issues. No idea why restoring dom0 wasn't able to do 
> so. Now I gotta wade through all the other config files... Hopefully, not 
> missing anything else.

Mystery is partially solved. Upon reboot, the entries in the good kwinrulesrc 
file were mostly cleared and replaced with references. Window Rules must use 
some type of unique identifiers that aren't carried over... Maybe an 
export/import would work. The important thing is that Qubes Restore doesn't 
appear to have an issue.

-- 
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/1ec95ba0-83a9-4729-bdd4-8e4a686d9482%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Missing config files after Backup / Restore

[3n7r0py1]

On Thursday, August 18, 2016 at 12:41:16 AM UTC, Chris Laprise wrote:
> On 08/17/2016 06:41 PM, entr0py wrote:
> >> On 08/17/2016 03:20 PM, entr0py wrote:
> >>> Just migrated my Qubes 3.1 system to new hardware and it went 
> >>> surprisingly smoothly :)
> >>>
> >>> I noticed however that my KDE Window Rules did not get backed up / 
> >>> restored (not sure which).
> >>>
> >>> It's kind of irrelevant at this point since we're moving away from KDE 
> >>> but I'd still like to know why that happened and if there are other 
> >>> config files that I need to copy over manually.
> >>>
> >>> Most of the files in ~/.kde/share/config/ have permissions user:user 600 
> >>> so it shouldn't be a problem to back up. Is a KDE lock on those files 
> >>> preventing them from being overwritten on the restore? Any other files I 
> >>> should bring back manually? (Just noticed some keybindings not working...)
> >>>
> >>> Thanks.
> >> If the KDE version stayed the same (4.x) then I'd expect the dom0
> >> restore to include window rules and keybindings.
> >>
> >> Did you restart the system after the restore?
> >>
> >> Chris
> > Yes, more details:
> >
> > 1. Backed up the entire system (all up-to-date): dom0, all templates, all 
> > vms;
> > 2. Installed fresh Qubes 3.1 with no pre-configuration (seems fedora-23 was 
> > installed anyway)
> > 3. Did an incremental restore as follows:
> > a. restored dom0 - noticed that the following did not restore: desktop 
> > background, sound prefs,
> >application menu settings (application menu entries were correct)
> > b. reboot
> > c. restored service templates & service vms
> > d. updated dom0 - noticed window rules were not restored
> > e. reboot
> > f. restored dom0 AGAIN - thinking that dom0 update might have some 
> > effect
> >window rules did not restore BUT desktop background did.
> > g. restored all other templates & vms
> > h. noticed that keybindings did not restore
> >
> > I think all of these KDE settings are stored in ~/.kde/share/config/. 
> > Specifically, the window rules are located in kwinrulesrc. I guess I could 
> > reconnect backup drive and go find out if files were backed up to begin 
> > with. My hunch is that the problem is on the restore end. How can I tell if 
> > files are locked? And if locked can Qubes restore overwrite them?
> >
> 
> Doesn't dom0 restore move the current home dir into a subdir, then write 
> the restored files to the correct locations?
> 
> The only way I can think of that failing is if the initial move was 
> piecemeal and didn't catch everything.
> 
> Another explanation for the problem is that KDE might store some 
> settings elsewhere, such as /etc or /usr/share.
> 
> FWIW, although I prefer using KDE I have never relied on a restore 
> process to get my desktop settings back. I think its better to have a 
> written checklist of customizations that need to be done after an 
> installation.
> 
> Chris

Yes, that's the approach I usually take when performing upgrades. Thought I 
would be lazy this time since everything was remaining constant. Plus, I was 
anticipating having to do it all over again for 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/9b5cc523-ae38-43d0-b923-67c62d47452a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Missing config files after Backup / Restore

[3n7r0py1]

On Wednesday, August 17, 2016 at 10:42:29 PM UTC, entr0py wrote:
> > On 08/17/2016 03:20 PM, entr0py wrote:
> >> Just migrated my Qubes 3.1 system to new hardware and it went surprisingly 
> >> smoothly :)
> >>
> >> I noticed however that my KDE Window Rules did not get backed up / 
> >> restored (not sure which).
> >>
> >> It's kind of irrelevant at this point since we're moving away from KDE but 
> >> I'd still like to know why that happened and if there are other config 
> >> files that I need to copy over manually.
> >>
> >> Most of the files in ~/.kde/share/config/ have permissions user:user 600 
> >> so it shouldn't be a problem to back up. Is a KDE lock on those files 
> >> preventing them from being overwritten on the restore? Any other files I 
> >> should bring back manually? (Just noticed some keybindings not working...)
> >>
> >> Thanks.
> > 
> > If the KDE version stayed the same (4.x) then I'd expect the dom0
> > restore to include window rules and keybindings.
> > 
> > Did you restart the system after the restore?
> > 
> > Chris 
> 
> Yes, more details:
> 
> 1. Backed up the entire system (all up-to-date): dom0, all templates, all vms;
> 2. Installed fresh Qubes 3.1 with no pre-configuration (seems fedora-23 was 
> installed anyway)
> 3. Did an incremental restore as follows:
>a. restored dom0 - noticed that the following did not restore: desktop 
> background, sound prefs, 
>   application menu settings (application menu entries were correct)
>b. reboot
>c. restored service templates & service vms
>d. updated dom0 - noticed window rules were not restored
>e. reboot
>f. restored dom0 AGAIN - thinking that dom0 update might have some effect
>   window rules did not restore BUT desktop background did.
>g. restored all other templates & vms
>h. noticed that keybindings did not restore
> 
> I think all of these KDE settings are stored in ~/.kde/share/config/. 
> Specifically, the window rules are located in kwinrulesrc. I guess I could 
> reconnect backup drive and go find out if files were backed up to begin with. 
> My hunch is that the problem is on the restore end. How can I tell if files 
> are locked? And if locked can Qubes restore overwrite them?
> 

So I took kwinrulesrc from the old system and copied it right into the new 
system manually with no issues. No idea why restoring dom0 wasn't able to do 
so. Now I gotta wade through all the other config files... Hopefully, not 
missing anything else.

-- 
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/7e47ff2c-3adb-42fd-b41b-8e9c68cbb202%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Windows7 issue with Dom0 GUI Daemon

[3n7r0py1]

On Monday, August 15, 2016 at 4:51:13 PM UTC, 3n7r...@gmail.com wrote:
> On Monday, August 15, 2016 at 2:35:45 PM UTC, 3n7r...@gmail.com wrote:
> > On Monday, August 15, 2016 at 1:33:35 PM UTC, 3n7r...@gmail.com wrote:
> > > Qubes 3.1
> > > Windows7 Pro x64
> > > Windows Tools 3.0.4-1
> > > 
> > > Without Debug mode, VM does not produce any windows and ends in an 
> > > unresponsive Yellow state.
> > > 
> > > With Debug mode, VM appears to hang after Windows logo boot screen. In F8 
> > > Low-Resolution Mode, VM boots to desktop and is fully functional.
> > > 
> > > Increasing resolution while in Low-Resolution Mode sends VM into 
> > > unresponsive Yellow state.
> > > 
> > > Any workarounds? Existing threads seem to have been patched.
> > 
> > * Multi-monitor setup
> > 
> > * This error presented itself on one boot but has gone away.
> > [Dom0] Sorry - KDialog: The Dom0 GUI daemon do not support protocol version 
> > 107:0, requested by the VM 'win7'.
> 
> Disabled all additional monitors.
> Everything works great - including Seamless GUI.

Duplicate of Unresolved Issue: 
https://groups.google.com/forum/#!searchin/qubes-users/windows$20multi$20monitor/qubes-users/lG6ynmOkIgY/1Nu4sT9XCwAJ

-- 
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/cf36a4c4-90d9-4f7b-adf3-4186524af13f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Windows7 issue with Dom0 GUI Daemon

[3n7r0py1]

On Monday, August 15, 2016 at 2:35:45 PM UTC, 3n7r...@gmail.com wrote:
> On Monday, August 15, 2016 at 1:33:35 PM UTC, 3n7r...@gmail.com wrote:
> > Qubes 3.1
> > Windows7 Pro x64
> > Windows Tools 3.0.4-1
> > 
> > Without Debug mode, VM does not produce any windows and ends in an 
> > unresponsive Yellow state.
> > 
> > With Debug mode, VM appears to hang after Windows logo boot screen. In F8 
> > Low-Resolution Mode, VM boots to desktop and is fully functional.
> > 
> > Increasing resolution while in Low-Resolution Mode sends VM into 
> > unresponsive Yellow state.
> > 
> > Any workarounds? Existing threads seem to have been patched.
> 
> * Multi-monitor setup
> 
> * This error presented itself on one boot but has gone away.
> [Dom0] Sorry - KDialog: The Dom0 GUI daemon do not support protocol version 
> 107:0, requested by the VM 'win7'.

Disabled all additional monitors.
Everything works great - including Seamless GUI.

-- 
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/a300bf78-56e8-4097-9914-705553e58638%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Windows7 issue with Dom0 GUI Daemon

[3n7r0py1]

Qubes 3.1
Windows7 Pro x64
Windows Tools 3.0.4-1

Without Debug mode, VM does not produce any windows and ends in an unresponsive 
Yellow state.

With Debug mode, VM appears to hang after Windows logo boot screen. In F8 
Low-Resolution Mode, VM boots to desktop and is fully functional.

Increasing resolution while in Low-Resolution Mode sends VM into unresponsive 
Yellow state.

Any workarounds? Existing threads seem to have been patched.

-- 
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/d4f7b66d-ca9a-4cba-9be5-fd864800013f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: PulseAudio Connection Terminated

[3n7r0py1]

On Friday, July 29, 2016 at 10:51:31 PM UTC, Marek Marczykowski-Górecki wrote:
> 
> Check kernel messages - maybe this is out of memory condition?
> 

No kernel error messages.
Machine has 16GB RAM - dom0 has 4GB.
No changes in hardware since last successful boot.

Really need some help with this.
Machine is locking up every 5 secs. Plus I need audio.
Thanks!

(For a few minutes I thought the issue might have resolved itself, but when I 
launched PulseAudio Volume Control, it went haywire again. No idea if those 
events are related.)

-- 
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/e4c24264-c23b-47a3-b722-4f010215a043%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: PulseAudio Connection Terminated

[3n7r0py1]

1. Deleting config files `~/.pulse`, `~/.config/pulse` did not resolve. 

2. PulseAudio Manager Client Information says:
Linked to Library 5.0.0
Compiled with Library 4.0.0
Is that a problem?

3. pulseaudio -:
I: [pulseaudio] main.c: Daemon startup complete.
D: [pulseaudio] module-udev-detect.c: /dev/snd/controlC1 is accessible: yes
D: [pulseaudio] module-udev-detect.c: Resuming all sinks and sources of card 
alsa_card.pci-_01_00.1.
D: [pulseaudio] module-udev-detect.c: /dev/snd/controlC0 is accessible: yes
D: [pulseaudio] module-udev-detect.c: Resuming all sinks and sources of card 
alsa_card.pci-_00_1b.0.
I: [pulseaudio] module-suspend-on-idle.c: Source 
alsa_input.pci-_00_1b.0.analog-stereo idle for too long, suspending ...
D: [pulseaudio] source.c: Suspend cause of source 
alsa_input.pci-_00_1b.0.analog-stereo is 0x0004, suspending
I: [alsa-source-ALC898 Analog] alsa-source.c: Device suspended...
D: [pulseaudio] core.c: Hmm, no streams around, trying to vacuum.
I: [pulseaudio] module-suspend-on-idle.c: Sink 
alsa_output.pci-_00_1b.0.analog-stereo idle for too long, suspending ...
D: [pulseaudio] sink.c: Suspend cause of sink 
alsa_output.pci-_00_1b.0.analog-stereo is 0x0004, suspending
I: [alsa-sink-ALC898 Analog] alsa-sink.c: Device suspended...
D: [pulseaudio] core.c: Hmm, no streams around, trying to vacuum.
I: [pulseaudio] module-suspend-on-idle.c: Sink 
alsa_output.pci-_01_00.1.hdmi-stereo idle for too long, suspending ...
D: [pulseaudio] sink.c: Suspend cause of sink 
alsa_output.pci-_01_00.1.hdmi-stereo is 0x0004, suspending
Killed

-- 
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/842acec0-a494-49f4-90b4-9aef9af512b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: What do you think about the idea of a FileVM?

[3n7r0py1]

On Friday, July 29, 2016 at 1:42:07 AM UTC, epic...@gmail.com wrote:
> A fileVM would be a mountable filesystem that 2 or more AppVMs can share.

You don't need a VM, just a Drive (physical, network, or image).

Here's how I moved my data off of my appVM using a disk image:

https://groups.google.com/d/msg/qubes-users/c-XQTfa_l-Y/IkY8x3u6BwAJ

This is for dedicated use by one appVM at a time. You'll need to research 
implications of concurrent access by multiple VMs.

-- 
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/69dfdb76-f061-46f2-b5f5-f61b7946d466%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.