Re: [qubes-users] Clone qubes machine - any options other than backup and build again?

[dumbcyber]

On Thursday, 15 December 2016 01:07:12 UTC+11, Andrew David Wong  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2016-12-14 03:19, dumbcyber wrote:
> > Hello, I am running Qubes from a 64Gb USB stick.
> > 
> > I am running R3.2 on my Macbook 11,1, and have built several 
> > template VMs, for example Windows.
> > 
> > What I want to do now is clone the entire USB stick to another USB 
> > external SSD drive. In other words I want to be able to stop using 
> > the USB stick and move to the SSD drive without building Qubes from
> > again scratch and then performing backup/restore all my VMs.
> > 
> > Is this even possible? Am i dreaming?
> > 
> > Thanks in advance.
> > 
> 
> I reckon there's nothing to lose by trying, as long as you keep the
> original USB stick. You can try with dd or any program that makes a
> bitwise identical image from the USB stick and faithfully writes it
> onto the SDD drive.
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> -BEGIN PGP SIGNATURE-
> 
> iQIcBAEBCgAGBQJYUVIDAAoJENtN07w5UDAwzAwP/0w1+2cu9qFizHAVfApng01g
> SPwqL9Gt+lNdYRoUUjSIsBHe2bpY1DDllpiZnTVc1EmK6daq9XjSMs1dVlceUNeV
> 01uJ2mN68vY6PqZZ0DrREdmK3EteFRo/761qwr+gvQ1A7BqT3gJZjIACauizQ1EC
> Jlk0Mr5BO34j9b3zj4bv43M+7fM2tL1kB0i1ISELCeiRF8IHcqd3IQMwF8GD7OfC
> iCAXiVj+pBbp7FojUhqrzHYmBj6YK35MmX6BAzwc6L/Zh3XcQsGuBy2SzPPmodgM
> kWJ6uRsKCY7k7hCM3nauDfrIeweOr0d4vhOUivx7CjdayCh/W1Z47A1hbId7E+i7
> RqSqx/l3ZgEWkgnj5XOM/Pv3CrKIRnBr55fe5EDpgFeAasluGd4XFWHhx/Sx73mt
> iqVsk7KzBvvWL7AjThBWLqbwfk2FU0ajE0DJw3/XsGyJxscap8BXiGCPkTi4NaRd
> Z4Iy/VJ6RRVTSBbqZ87B28qZmZ/dYYJX7Rll//5OZcEI2XzSGopE882rdmaYG62v
> M6fQgpjsBh1QMC36Fe0nlFAN1FPoe2Aneg73wziA1+XKoZRo7iK/rQSb+vL3h9vq
> 2vZfBDbYkplWonJ6LhukGK4LozpuuaL2AK1Q4xhF8b/LZZII7/MWvkhHUDCMAY6t
> nDiTseM0toT5Gp48rPJw
> =GoBG
> -END PGP SIGNATURE-

Quick update:  On a Kali Linux machine, I managed to format and partition the 
destination disk as per the Qubes USB stick. I've used DD command to copy the 
contents of the two partitions. I get a success message at the end.

When I boot I get the option to boot from this new disk but nothing else 
happens. I've noticed using fdisk and gparted on linux that while the DD 
command is successful the second partition is actually empty. The first 
partition is fine - looks exactly like the source disk.

Any ideas 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/fe8712a9-14d7-4a4a-bce9-aabe269d2d62%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 3.2 Install hangs in GRUB on Mac OS X 10.10 - USB Install

[dumbcyber]

On Saturday, 17 December 2016 07:09:50 UTC+11, Sam Johnson  wrote:
> I have installed Qubes 3.2 on a USB flash drive as follows:
> 
> sudo dd if=Qubes-R3.2-x86_64.iso of=/dev/rdisk2 bs=1m
> 
> When rebooting I hold down Alt and enter the Qubes installation menu. Any 
> selected option starts processing but quickly ends and returns me to the 
> menu; no installation is made.
> 
> This page seems to be relevant: 
> https://www.qubes-os.org/doc/uefi-troubleshooting/
> 
> But I have no way of actually using vi to edit the file mentioned in the 
> section of 3.2
> 
> (I did find an article with a work around to Ctrl-x not working on some 
> systems:  bugzilla.redhat.com/show_bug.cgi?id=1253637 )
> 
> 
> Suggestions with any step of this process are welcome and appreciated.
> 
> 
> 
> 
> 
> 
> Sent with ProtonMail Secure Email.

I run Qubes R3.2 on a Macbook Pro 11,1 but had to run the installer on another 
machine. I used a Lenovo to  boot into Qubes and complete the installation. The 
resulting disk works fine on the MacBook. Some people have had success creating 
a EFI folder on the disk and copying the necessary file manually.

-- 
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/417579ef-bd47-4dfd-a7bf-e6fd14c215e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes Laptop

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-12-17 20:03, Andrew David Wong wrote:
> On 2016-12-17 15:25, RFJW wrote:
>> Hi Andrew,
> 
>> I am looking to purchase or build a new laptop that is the most 
>> qubes supported. I first thought of buying a libreboot t400 but 
>> they are not supported by qubes and the old hardware may be a 
>> disappointment. My other option was the purism librem 13 but they 
>> have had mixed reviews and the hardware is also becoming dated 
>> compared to the price. What laptop can you recommend 
>> buying/building that is most supported?
> 
>> Kind regards,
> 
>> Ross
> 
> 
> Hi Ross,
> 
> - From first-hand experience, the ThinkPad T450s supports Qubes very
> well, with the exception of AEM. [1] I'm afraid I can't offer any
> other personal recommendations, because I don't have first-hand
> experience with running Qubes on other laptops. However, I've heard
> good things about the x220 and x230 models, and Michael has suggested
> adding them as Qubes-certified laptops. [2]
> 
> Best,
> Andrew
> 

By the way, you may want to take a look at our HCL [3] and system
requirements [4] if you haven't already. It's also worth reading the
updated requirements for Qubes-certified hardware for 4.x. [5]

> [1] https://github.com/QubesOS/qubes-issues/issues/2155
> [2] https://github.com/QubesOS/qubes-issues/issues/1771
[3] https://www.qubes-os.org/hcl/
[4] https://www.qubes-os.org/doc/system-requirements/
[5] https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/

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

iQIcBAEBCgAGBQJYVgs2AAoJENtN07w5UDAwD3EQALIvdBjOptl/ASevbPz8yr1S
R1MTdPUP+ygtHEzgK3enCbWXpXe2z141HAmdJe3EuwZbomV+/sltOFKgtz4ZYgG3
Qsoa7VRVLy4MpcUQ3yMkh/aLUe01WZ6/e3WLTmrgb0V206O9h9XBtMLveoK1bdTt
kP4R7d6hsvsRudVL4D7cjFh9y/Dubf9vwP6ZCu2v3k8sNJ/VX3yWOcI0C1lNqqdm
etcCgk212tQoRi6pTwihAMI6hRSDD+/4RrrG06ZI38nZPTuOS24kTvK4YatTwoxS
BZUjLxsONX7QSOZNTEVIFGicTs38aJM0GnwuiW4Iz2FB6UCFWwFafqhKKDItcOlZ
LlnHgoqWYo+pyelCU9c9rNeA1SJTlFD2yW5eSy8+tWvs1dXKUGIQ6UJ4chZRMHkJ
lq0aKd74nd2MMWzYBNBDTtMpiBe82YU97qdWQ3PiamHj2VO5ThBUjgydliGdG3tG
rlY3jrATPSIerksLSMXIxf08cwPwukIv2aF+dOstkstdBikiAAJy4Y0idXUozNJ/
6Qaq+Tr5mooKu5+hh2qMp4FFqdvIWpEl8IzW6tAR7sti1DlhJ8u70XReumb32BJc
j81KePLF+jWhzJ9bp6SONHitHLJAlqtgdfwAyrGkH1Mab9wRV5LGkinZ4AYYJRTI
Wo4iEGMJFx/r2kEPa1nN
=3/aQ
-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/97060512-b1d0-a5a3-0609-50631945c56e%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes Laptop

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-12-17 15:25, RFJW wrote:
> Hi Andrew,
> 
> I am looking to purchase or build a new laptop that is the most 
> qubes supported. I first thought of buying a libreboot t400 but 
> they are not supported by qubes and the old hardware may be a 
> disappointment. My other option was the purism librem 13 but they 
> have had mixed reviews and the hardware is also becoming dated 
> compared to the price. What laptop can you recommend 
> buying/building that is most supported?
> 
> Kind regards,
> 
> Ross
> 

Hi Ross,

- From first-hand experience, the ThinkPad T450s supports Qubes very
well, with the exception of AEM. [1] I'm afraid I can't offer any
other personal recommendations, because I don't have first-hand
experience with running Qubes on other laptops. However, I've heard
good things about the x220 and x230 models, and Michael has suggested
adding them as Qubes-certified laptops. [2]

Best,
Andrew

[1] https://github.com/QubesOS/qubes-issues/issues/2155
[2] https://github.com/QubesOS/qubes-issues/issues/1771

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

iQIcBAEBCgAGBQJYVgqSAAoJENtN07w5UDAw4tQQAIQXAkM4Wppe8r7tCwrbxc3H
RIo2QKPBfvcwoRQAdgA3aW1604PaiADgRTlsHj/cY6mj6QD9eNl5MoPc+mpM3UMg
SqRyvxIZRfHKWy5ddL1l44EJt73DVCRr9I/GyqyXBM1eeAkZw+wK5Cug5DltoH9U
Xp84nGIPzMnW+GBYDZEvRleX7c4RMR94iYlXklt+wSrakpxyiyAcfV80zk0MQLcl
HO9Cdr78uEsAeoOKA7+5Ju2Ht8tm18g5Kp7g8oKOSwKDBps3WWrZML8Mif0XDgtn
8Nqhr6QSEszXdWAnLiv70Hk1sQkOiSeX19RdqJPUZUn3boh9l46kiMAjGlZp3j9y
swqcQ/UBMzXgQINqJqhVjHRE6zJfscocBda4KUfLvn/kkjJmv7QJZX6jxtnNmZN9
PjTjDtFEL4LzdfX6qlQy+LolEmk4xvvPz0uDxwSQ/280lE4jjImmRf6wgXX9LRL6
fuxmh9KjWbZGRfguSbkZmaBY0IMdx4paM0w+7J30NfPmHndxhF9ir3EXxoGIokb6
v4ZTKtt9OfFduN7G5wcFEFm7ZSSlUWEIsIKbSS62c98aiVjEnpUyPL/OZgNUKUCo
Fvj+61B4p+oxLztkbaF0KviHjPrpE0Hw+ShZyxbdTRDsp3o/AQZUnx9i2Fn+lVTJ
+Xr2mZvgjAjHMYDHmxZr
=mU++
-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/0fe1f1ff-7065-c19f-3584-df6865ec0dd6%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes using Cloudflare - Why?

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-12-17 18:33, taii...@gmx.com wrote:
> How come you guys use cloudflare?

The main reasons are:

1. A core tenet of the Qubes philosophy is "Distrust the
   infrastructure," where "the infrastructure" refers to things like
   hosting providers, CDNs, DNS services, package repositories, email
   servers, PGP keyservers, etc. (This includes Cloudflare, of course.)
   We focus on securing the endpoints instead of attempting to secure
   "the middle" (i.e., the infrastructure), since one of our goals is
   for users to have to entrust their security to as few entities as
   possible (ideally, only themselves).

   Users can never fully control all the infrastructure they rely
   upon, and they can never fully trust all the entities who do control
   it. Therefore, we believe the best solution is not to attempt to
   make the infrastructure trustworthy, but instead to concentrate on
   solutions that obviate the need to do so. We believe that many
   attempts to make the infrastructure appear trustworthy actually
   provide only the illusion of security and are ultimately a
   disservice to real users. Since we don't want to encourage or
   endorse this, we make our distrust of the infrastructure explicit.

2. It's free (as in beer). We'd have to spend either time or money to
   implement a solution ourselves or pay someone to do so, and we can't
   spare either one right now.

3. It has low admin/overhead requirements, which is very important,
   given how little time we have to spare.

> They have a dangerous monopoly on internet services and 
> discriminate against people using VPN's and the like, by insisting 
> that you enable javascript and perform a captcha even for simply 
> viewing a website and by subverting them a hostile actor would 
> effectively own most of the internet.

I'm not sure about VPNs, but we explicitly whitelist Tor exit nodes in
Cloudflare, so there should be minimal (if any) CAPTCHAs if you browse
our website over Tor (which is much better for strong privacy than
using a VPN).

As for enabling Javascript, this shouldn't be much of a problem for
Qubes users, since they can simply use a DispVM, or have a dedicated
VM for untrusted browsing.

In general, though, I agree that Cloudflare has some undesirable
qualities. If you're aware of a similar solution that doesn't suffer
from these drawbacks (and that satisfies the three requirements listed
above), then by all means, please let us know.

> They also have a curious policy in regards to protecting terrorist
>  websites, I do not think that that is done out of some want for 
> total freedom of speech as that reasoning wouldn't mesh with the 
> other decisions they make.

I don't know anything about this, but if it's true, it's certainly
troubling. Again, if you're aware of a similar solution that doesn't
have such problems (and that satisfies the three requirements listed
above), then by all means, please let us know.

> Pre-emptive q/a: "it is okay because we have gpg key verified 
> downloads" Which is fine, until someone changes the signature
> files and the key id that users should fetch.

This is why users are explicitly instructed to verify key fingerprints
using out-of-band (i.e., multiple) channels:

https://www.qubes-os.org/doc/verifying-signatures/

> "web of trust key signing protects you" Which again, is fine,
> until the key server you use runs cloudflare as well,

We don't really rely on WoT so much as verifying key fingerprints, but
isn't the point of WoT that it doesn't have to assume trustworthy
keyservers?

> or you're stuck at the catch-22 of verification with trusting
> trust and besides most users don't check that anyway.

Are you referring to the classic "Reflections on Trusting Trust"
paper? It's not clear to me what you have in mind here.

> "without cloudflare someone could just get a corrupt CA to issue a 
> fake cert so hey it doesn't matter" And that would be detected
> with certificate patrol.

There are still a lot of infrastructure-related problems (i.e., attack
vectors) that this doesn't rule out, like an attacker gaining access
to the server itself.

> "butyou ask for a change that may only provide minor 
> protection!" Security isn't about 100%, it is about layering until 
> you are not the path of least resistance - 99.9%

True, but it's also about the cost-benefit analysis, and in our case,
the costs of implementing and maintaining a solution ourselves are too
high right now.

> https://en.wikipedia.org/wiki/Cloudflare#Criticism_.26_Controversies
> If that hacker didn't use the exploit for a super petty reason we
> probably would have never known.

I can't tell which incident this is referring to, but, in general, I
think the principle of distrusting the infrastructure applies here.

> Other associated problems: * The qubes-os.org site certificates
> are only 2048bit, not good enough.

My impression is that many reputable cryptographers 

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

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Dec 17, 2016 at 10:56:12AM -0800, 3n7r0...@gmail.com wrote:
> 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:
> > [   

[qubes-users] Qubes using Cloudflare - Why?

[taii...@gmx.com]

How come you guys use cloudflare?

They have a dangerous monopoly on internet services and discriminate 
against people using VPN's and the like, by insisting that you enable 
javascript and perform a captcha even for simply viewing a website and 
by subverting them a hostile actor would effectively own most of the 
internet.


They also have a curious policy in regards to protecting terrorist 
websites, I do not think that that is done out of some want for total 
freedom of speech as that reasoning wouldn't mesh with the other 
decisions they make.


Pre-emptive q/a:
"it is okay because we have gpg key verified downloads"
Which is fine, until someone changes the signature files and the key id 
that users should fetch.

"web of trust key signing protects you"
Which again, is fine, until the key server you use runs cloudflare as 
well, or you're stuck at the catch-22 of verification with trusting 
trust and besides most users don't check that anyway.
"without cloudflare someone could just get a corrupt CA to issue a fake 
cert so hey it doesn't matter"

And that would be detected with certificate patrol.
"butyou ask for a change that may only provide minor protection!"
Security isn't about 100%, it is about layering until you are not the 
path of least resistance - 99.9%


-
https://en.wikipedia.org/wiki/Cloudflare#Criticism_.26_Controversies
If that hacker didn't use the exploit for a super petty reason we 
probably would have never known.

-

Other associated problems:
* The qubes-os.org site certificates are only 2048bit, not good enough.
* The mailing list uses google groups, instead of better self-hosting 
that doesn't give google whatever it is they're getting from it.


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/baf81cfd-f174-eb8a-f067-65d5485ec43c%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Updates, security

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/17/16 17:50, Unman wrote:
> On Sat, Dec 17, 2016 at 06:18:41PM -, johnyju...@sigaint.org wrote:
>> While updates are signed, so even if they come over the wire in cleartext,
>> the fact that they often are sent in the clear (even from debian.net)
>> allows a snooper to know what packages your scanning for metadata or
>> installing.  It reveals a lot about the state of your system.
>>
>> Updating over Tor or a VPN helps a bit.  Updating to debian's hidden
>> service is even more ideal, no https in between with
>> state-actor/CA-forgeable certificates possible, etc..
>>
>> However, Qubes updates aren't available via Tor.
>>
>> I do notice, however, that the qubes repository will allow changing the
>> "http" to "https" in the qubes entry /etc/apt/sources.list.d/.  (You'd
>> have to install "apt-transport-https" too.)
>>
>> Do the Qubes folks have a problem with this?  It'd put extra load on the
>> servers, so I thought I'd ask.
>>
>> I might suggest it would make a good default, if the load wouldn't be
>> unacceptable.
>>
>> Cheers,
>>
>> -d
>>
> This has been under discussion in qubes-issues for some time.
> apt-transport-https is installed by default, so you can change that if
> you want.
> 
> There was a proposal to make debian updates use https by default. It
> wasnt accepted. Debian security updates aren't available by https so
> that part will always come plain.
> You can change the rest to use https.
> The benefits of doing this are almost entirely illusory. It's pretty
> trivial to identify packages being transferred under https, so a
> competent snooper wouldn't be hampered.
> 
> I assume you mean that Qubes updates aren't available as an onion
> service.

Indeed, it is already possible to download all updates (dom0 + templates)
over Tor, but there are no onion services yet for most parts. Nonetheless,
the main benefits of downloading updates over Tor still hold:

1. Network attackers can't target you with malicious updates or
   selectively block you from receiving certain updates. Instead, they're
   forced to either block everyone or serve everyone with the same malicious
   update in the hope that you're among those affected. This makes it much
   more likely that someone will spot the attack.

2. Downloading all updates through Tor preserves your privacy, since it
   prevents your ISP and package repositories from tracking which packages
   you install.

> I offered to set this up some time back but it wasnt thought a
> priority.

Since one of the core tenets of Qubes is that we distrust the
infrastructure,  (i.e., we focus on securing the endpoints before securing
the middle), it makes sense that this would be a lower priority.
Nonetheless, I think it would be fantastic to have this.

> There used to be such a service but it's long out of date
> now.

We had an onion service (back then a "hidden service") mirror of the
website, but I don't think we ever had an onion service package repo
(at least, not that I'm aware of).

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

iQIcBAEBCgAGBQJYVe/jAAoJENtN07w5UDAwVGsP/R+bwiXp01nhuVE6TDHE1Rdc
bWd074Lw6V87qiDf2LpAOTZ1BKPqAtWNr7zRuWIjfQwbhl1iCiOlFTPWohEULkDf
HvmWUzsOlMokiVPKnydzEVJ+ehMJ/uXdm6s6jbqbCE7Zo6ivdybyMdExNk9igKIJ
lfgvIM5kBUxnHuecS74S0/VZn5f9XOe/IITX2RyWAB478ze7S8SCMIKfnb3wOAey
knOOtSN22vooB3fKZ2y+T6R1mS6beP5TLsqHA7f63r983llP8ttduM8hZBu98g75
+pP7btNgC1DBUJYQcAmZnW7VXlk33atlZanl+3i3Kf6QBY9XXAqrVQ01htrKFmKc
Ac58JFK5JSw6johyZuxoyuHYA/Uaq7SoG//qV6jt28Db6fwUNIdLQ1A6buUjj17G
zJlnk2ihQAotPPVYICqO440gjwfGtkF2ourBqJA1CPheBozDvyyqjNJZNBueuePj
RN30f3X0Zx/HJIcje+SWglm7Vc4TpG4G/pKM+4xD1ODUE0ozZEj1HQJzCdrOfqWl
2A3wDOHpIPuXomEK++l5XZ7vviOCx9cmWdHR3Y5K3bKYqodA/YJVA0dZWe8vEoXf
mLjQfSBeB5ZAGsnPvX6R/Z6blHMvAl6dTUhhkoc5jwf2An/BXFdcOdVZxCbgf9cX
1Tz3X5KDxR7My05U8JWT
=PAw/
-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/52e5fb3c-df2c-065b-cf92-b9134aaaf754%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Updates, security

[Unman]

On Sat, Dec 17, 2016 at 06:18:41PM -, johnyju...@sigaint.org wrote:
> While updates are signed, so even if they come over the wire in cleartext,
> the fact that they often are sent in the clear (even from debian.net)
> allows a snooper to know what packages your scanning for metadata or
> installing.  It reveals a lot about the state of your system.
> 
> Updating over Tor or a VPN helps a bit.  Updating to debian's hidden
> service is even more ideal, no https in between with
> state-actor/CA-forgeable certificates possible, etc..
> 
> However, Qubes updates aren't available via Tor.
> 
> I do notice, however, that the qubes repository will allow changing the
> "http" to "https" in the qubes entry /etc/apt/sources.list.d/.  (You'd
> have to install "apt-transport-https" too.)
> 
> Do the Qubes folks have a problem with this?  It'd put extra load on the
> servers, so I thought I'd ask.
> 
> I might suggest it would make a good default, if the load wouldn't be
> unacceptable.
> 
> Cheers,
> 
> -d
> 
This has been under discussion in qubes-issues for some time.
apt-transport-https is installed by default, so you can change that if
you want.

There was a proposal to make debian updates use https by default. It
wasnt accepted. Debian security updates aren't available by https so
that part will always come plain.
You can change the rest to use https.
The benefits of doing this are almost entirely illusory. It's pretty
trivial to identify packages being transferred under https, so a
competent snooper wouldn't be hampered.

I assume you mean that Qubes updates aren't available as an onion
service. I offered to set this up some time back but it wasnt thought a
priority. There used to be such a service but it's long out of date
now.

unman

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

Re: [qubes-users] building ubuntu14 template

[Unman]

On Sat, Dec 17, 2016 at 01:09:38PM -0600, j...@vfemail.net wrote:
> hi.
> i am trying to build an ubuntu14 template:
> 
> From the doc: 'Ubuntu 14.4 LTS (Trusty) can be built with little effort.'
> So i assume it should work.
> 
> When executing `make qubes-vm` i get following error:
> 
> Ign http://ppa.launchpad.net trusty/main Translation-en
> Reading package lists...
> # Parse debian/control for Build-Depends and install
> /home/user/qubes-builder/qubes-src/builder-debian//scripts/debian-parser
> control --build-depends
> /home/user/qubes-builder/chroot-trusty//home/user/qubes-src/vmm-xen/debian-vm/debian/control
> |\
>     xargs sudo chroot /home/user/qubes-builder/chroot-trusty apt-get 
> install -y
> Reading package lists...
> Building dependency tree...
> Reading state information...
> E: Unable to locate package libsystemd-dev
> E: Unable to locate package libsystemd-dev
> /home/user/qubes-builder/qubes-src/builder-debian/Makefile.qubuntu:167:
> recipe for target 'dist-build-dep' failed
> make[2]: *** [dist-build-dep] Error 123
> Makefile.generic:139: recipe for target 'packages' failed
> make[1]: *** [packages] Error 1
> Makefile:209: recipe for target 'vmm-xen-vm' failed
> make: *** [vmm-xen-vm] Error 1
> 
> what can i do to fix this?
> 
> -joe
> 
> 

The error is in building vmm-xen.
I see there was a patch back in July that added libsystemd-dev under
Build-Depends. Clearly this isn't going to work under Trusty as that
package isn't available.
You could try removing those lines from debian/control and seeing if
vmm-xen-vm builds. I'm pretty sure it wont, but don't have time to test
that.
I'll have a look shortly to get Trusty working again.

It isn't yet in the docs but you could also try a 16.4 build. Feedback
would be useful.

unman

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

Re: [qubes-users] OpenVPN and debian-8

[Chris Laprise]

On 12/17/2016 01:27 PM, johnyju...@sigaint.org wrote:

I've finished my conversion of all VM's to debian-8 (and isolating USB,
the sound card, etc.).  (Next is dom0, and maybe the replacing the
hypervisor, but that's another story. :) )

The last hiccup was getting OpenVPN working in debian-8 in a ProxyVM.  It
would connect, but then get stupid and hangup.

Turns out the problem is that OpenVPN 2.3.4 included with Debian-8, will
fail to add a default static route to the VPN provider ("route add w.x.y.z
gw 10.137.2.1 eth0" kinda thing) if the netmask of the WAN interface is
255.255.255.255.  (There's some bug post out there related to this.)



I've not had this routing problem using either Debian 8 or 9/testing 
(the latter has openvpn 2.3.11). There may be a quirk in the way your 
VPN service specifies routing info (if it does at all) which triggered 
the bug.


Chris

--
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/4b4f3f45-6bf2-632e-7ce5-3c10cea90e37%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] VmCL for Coldkernel Debian 8 Qubes R3.2

[podmo]

Reporting success with Coldkernel on Qubes R3.2 with Debian 8 template.
Followed the steps in
https://coldhak.ca/blog/2016/12/12/coldkernel-qubes-1.html and worked
first try. I did some further tweaking afterwards to allow me to lock it
down a bit more in the future with TPE and keep my template minimal.

In the linux-4.8.13 directory structure:
Copied u2mfn.c to drivers/misc and set up references in Kconfig and Makefile
make menuconfig

GRKERNSEC_TPE_ALL=y [kernel.grsecurity.tpe_restrict_all]
GRKERNSEC_TPE_INVERT=y  [kernel.grsecurity.tpe_invert]
PAX_MEMORY_SANITIZE=y   [not sure if Xen sanitizes freed memory within 
the
VM, appears to only be on shutdown]
PAX_MEMORY_STACKLEAK=y
CONFIG_XEN_BLKDEV_BACKEND=m [believe this is necessary for the USB VM,
crashed Qubes Manager on attaching USB device to other VM without it]
CONFIG_XEN_NETDEV_BACKEND=m [and this for Net VM]
CONFIG_U2MFN=y  [to let me avoid DKMS]

fakeroot make bindeb-pkg -j 4 LOCALVERSION=-coldkernel-grsec-1
KDEB_PKGVERSION=4.8.13-coldkernel-grsec-1

Then, copied the following to minimal template:
linux-image-4.8.13-coldkernel-grsec-amd64.deb
paxctld_1.2.1-1_amd64.deb
paxctld.conf
/usr/share/initramfs-tools/hooks/qubes_vm
/usr/share/initramfs-tools/scripts/local-top/qubes_cow_setup

Added the following file on minimal:
/etc/sysctl.d/81-grsec.conf
  kernel.grsecurity.deny_new_usb = 0
  kernel.grsecurity.tpe_invert = 1
  kernel.grsecurity.tpe_restrict_all = 1

And ran on it:

sudo dpkg -i paxctld_1.2.1-1_amd64.deb [or use one from testing repository]
sudo apt install grub2-common

sudo groupadd -g 9001 grsecproc
sudo groupadd -g 9002 tpeuntrusted
sudo groupadd -g 9003 denysockets
sudo cp paxctld.conf /etc/paxctld.conf
sudo paxctld -d
sudo systemctl enable paxctld
sudo dpkg -i linux-image-4.8.13-coldkernel-grsec-amd64.deb
sudo mkdir /boot/grub
sudo update-grub2

sudo shutdown -h now

Changed it to use PVGRUB2 and minimal template worked too. Applied it to
sys-net, sys-firewall, sys-usb and all function (after adding some
packages I missed, etc.) except with two issues so far:
1. qvm-copy-to-vm completes successfully but throws an error to the
console at the end about failed to open /proc: permission denied.
2. On full reboot, all sys-VMs start automatically but networking doesn't
work right until I shut down whonix and firewall, then start them back up
in the proper order. Not sure if it's because they are just booting too
fast or if some trigger isn't getting communicated properly.


-- 
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/08e45f82fa9d42b6d8229113c3ee6fba.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ssh keys gui not working / password no longer stored (deb8)

[raahelps]

On Tuesday, December 13, 2016 at 9:35:40 PM UTC-5, Marek Marczykowski-Górecki 
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Tue, Dec 13, 2016 at 12:11:43AM +, Unman wrote:
> > On Mon, Dec 12, 2016 at 11:53:25PM +0100, cubit wrote:
> > > Heia
> > > 
> > > Since using Qubes (debian 8 template) back to R3.1 when ever I used ssh I 
> > > would get a gui prompt asking for my key password and it would be 
> > > remembered for all subsequent ssh sessions until I restart the AppVM.
> > > 
> > > With a recent template update this has broken, now what happens is in the 
> > > terminal window I am asked for the keys password but the password is no 
> > > longer stored and I must retype for every new session.
> > > 
> > > Is there an easy way to get the gui / password managed option back?
> > > 
> > > Cubit
> > > 
> > >
> > 
> > Debian uses ssh-agent by default. Just use ssh-add to store the key
> > before opening the ssh session.
> 
> For the record, this was intended change, reasoning here:
> https://github.com/QubesOS/qubes-issues/issues/2351
> And this discussion:
> https://groups.google.com/d/msgid/qubes-devel/2016110829.GS22572%40mail-itl
> 
> If you want to restore old behaviour, add to your ~/.profile in
> appropriate AppVM:
> 
> eval `gnome-keyring-daemon -c ssh`
> export SSH_AUTH_SOCK
> 
> - -- 
> 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
> 
> iQEcBAEBCAAGBQJYUK/4AAoJENuP0xzK19csGGIH/0zsGswJ1Xa4uiJ25wyrvHcw
> TBCiOgJAiune4+o89p5A2WuaDstoIK9B91QfNxGRip3V8yoDFKKPExMSdAip6sVI
> +4HHJZOMJjPdvRNSgVYfIAsjbqcMlApDEeWbQzuFc5S0pzKYYyFUnKxngfygg1sg
> 4Lr4xFQ1XK/z2nlAJTzCD+YSCcdnx+YQixHpT0NGDteY591UWqc5QHtAVr9OGRcp
> x2ZqJzcs+A8t4/nh9rgMZe+LO1iIIXcC4bV79LS2VvK/kmLX1PFtomPwpMbBJovF
> gS84AJFUP4wNNh+K2iD/a8R02XaLe/gwGKYWY9wYO5UoZINhgqjKq7oIGg6I9Q0=
> =zPOt
> -END PGP SIGNATURE-

I noticed this change too.   I never stored the password.  but I stopped 
getting the popup bubble to enter it past couple weeks.  glad to know it wasn't 
just me lol. no big deal though.  I'm sure forcing me to use terminal is more 
secure.  I was thinking that all along anyways.

-- 
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/d45e9279-5f22-4322-8fe4-7c3c7c097a09%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HP PRINTER PROBLEM

[raahelps]

On Wednesday, December 14, 2016 at 8:04:07 AM UTC-5, higgin...@gmail.com wrote:
> Have finally managed to get it working! 
> 
> Fedora (which I had not used before) was OK but Debian(my normal OS) was a 
> problem! An issue for me was that the relevant drivers were in HPLIP version 
> 3.15.11 onwards. Standard Fedora in Qubes uses 3.16.3 whereas Debian in QUBES 
> uses 3.14.6. This in itself was not a major issue in that I've installed a 
> newer version of HPLIP in my normal Debian setup - but replicating that here 
> caused problems. I won't summarise endless failures but try and summarise how 
> I eventually succeeded.
> 
> Started with ETHERNET connection from ROUTER to PRINTER.
>  With Fedora I installed yumex-dnf and system-config-printer. A look at yumex 
> showed that HPLIP was already there - v 3.16.3. Then in terminal i used 
> system-config-printer which opened up the add printer menu. Went for the 
> network option and entered Network Connected IP from Printer in host field. 
> This gave sub -menu where I think JetDirect and App Socket/HP Jetdirect 
> fields were needed. A list of all HP printers appeared from where I could 
> select Colorjet MFP M477fdw. Enter a couple of times and it all worked.
> 
> With Debian, i installed SYNAPTIC - a check there shows no HPLIP installed 
> and offers 3.14.6. I then googled HP LINUX IMAGING AND PRINTING . Followed 
> steps 1 to 7 - but not step 8. Latter worked fine on normal Debian setup - 
> but didn't seem to work here - this was the major frustration.
> Instead I keyed "sudo hp-setup -i PRINTERIP" in terminal. Interactive process 
> installed additional plugin - but this was straightforward - basically just 
> accepting defaults. The process recognised my printer and everything worked. 
> However when trying to get access to printer in a new VM I had problems and 
> got in a mess with references to "shared", "enabled" in printer dialogue box 
> on PC screen. Printer IP keeps changing - which maybe the problem or not . At 
> this stage I was still happy because at least I'd seen something print. THEN 
> went for another option - went back to USB connection between printer and PC. 
> On printer screen I went to SETUP/NETWORK SETUP/ IP4 CONFIG METHOD and chose 
> MANUAL option - and went with the default offered - 192.169.xxx.xxx.Having 
> done the 1st 7 steps of the HP LINUX IMAGING AND PRINTING NOTE already with 
> DEBIAN QUBES, I simply had to key "sudo hp-setup -i 192.168.xxx.xxx" in 
> terminal.
> It all flowed through again to successful conclusion.
> EVERYTHING APPEARS TO WORK 
> 
> Presumably my printer IP ADDRESS is now static. Whether or not I opened up 
> any security weakness in QUBES I'm not sure but at the moment I don't care 
> -my printer is working! Intend to do more reading from an old UBUNTU manual - 
> on networking and PRINTING WITH CUPS - the experience of the last few days 
> might enable me to understand the relevant chapters a bit better. As a 
> pensioner I have a bit time on my hands - so I can experiment endlessly on 
> the spare hard drive I'm using - before committing to moving to QUBES 
> completely. Am likely to do this - but want to get to feel at ease with QUBES 
> in a test environment first - so will probably convert in NEW YEAR. Hope this 
> note is useful for anyone else with PRINTER problems and THANKS AGAIN FOR 
> COMMENTS.

sorry I should of mentioned I use fedora for printing.   I actually use a  
disposable vm to print everything based on a cloned fedora template.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4d895ae7-2c79-4c1c-b32a-d51f313e6458%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: XFCE Application menu

[raahelps]

On Friday, December 16, 2016 at 7:14:27 AM UTC-5, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2016-12-16 04:00, cubit wrote:
> > 21. Oct 2016 16:14 by cu...@tutanota.com:
> >> I tried menulibre and it did not go so well, moving the "Qubes VM
> >> Manager" shortcut in the app menu from the middle of off the
> >> templates and  appvm's to the top along side "run program" and
> >> "terminal emulator"  had the very bad side effect of deleting all
> >> the shortcuts under "system tools".
> >> 
> >> 
> >> Has anyone played around and found a way to --safely-- organize
> >> the application menu?
> >> 
> > Looping back to this has anyone had any success in managing the
> > xfce menu expecially grouping the templates?
> > 
> 
> No, but a good alternative is to use Xfce4 "Launchers," which can be
> added to any panel from the right-click menu.
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> -BEGIN PGP SIGNATURE-
> 
> iQIcBAEBCgAGBQJYU9qVAAoJENtN07w5UDAwWyUP/1jOU8byjH+45KtLnaTK2jYk
> 63aZ7P5uLLUEAoDmNRzPziQQbMgCzOTWQPcQOLGRK0trMj4oafCAzHoZf4JCpiCa
> aj6M9tqArV9xioXwTMdR4xikp8VtENI7YFhfhflPpxQuBMRlt16O7zCdpQJuMlI0
> jjDYHd1lQBc86tGcBBBkyKn6HTPr9qAYJN0kK9Bc1B1EzHM+Io0uBy8pdDAVUKeV
> 8VV42GMDjGYoDO1WRJJHshTyrsVwgC9dGYRglTDRTZk2TIXQNEqAr/1AqGkCEZ7I
> r8SKMj6FH/I8K8vqZtE6JAK4yiNCof1YgRBVvyOcUhzfjxsQzgzH5AB9isjWW9EJ
> KhVEYyaOINRXc09wJDgzSz5o1lisREjZQHR8HlL4G2YwbMCuOkCxSr5YK9yq5lfu
> DQMqdkR6EXHenoBH6AOdWty9Q+1CMkOWK5cFosmPcKDKA5EMV/kvXURD2fOl+Iz7
> F+R1JmEMVJ2+sDxtEWK6xaqApVodePG1FwJj2qwA6myMdzgNTKy7GssJZXH64V0K
> HLvKv43siTLh+mgf9pdARUyu8pjVyOPZ4/FB9nsy3BjGElC1ljblMi56HG9HMKlh
> Dn51WdQ5WpSbLZmXfL5u65nBTQ+U93X9VKk1Qrq6ofoa2Mn34a5wib8AJBpRqRLL
> w1qmypkpMiqW8PahQSHH
> =mUiS
> -END PGP SIGNATURE-

oh I see you are saying the panel not the start menu.  Start menu is just less 
confusing.  There are 3rd party addons to manage it,  but I woudln't want to 
install one to dom0.

-- 
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/e90af914-f839-4683-9581-e02922c61cc5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: FYI: Experimental Qubes coldkernel support now available

[Colin Childs]

On 17/12/16 01:42 PM, Reg Tiangha wrote:
> On 12/17/2016 11:47 AM, Foppe de Haan wrote:
>> On Saturday, December 17, 2016 at 7:40:25 PM UTC+1, Reg Tiangha wrote:
>>> On 12/17/2016 10:36 AM, Foppe de Haan wrote:
 I also built the fedora kernel according to Reg's recipe, same issue.
 Comparing boot logs, the problem seems to start here:

 [0.765662] BUG: unable to handle kernel paging request at 
 87ff95a17300
 [0.765671] IP: [] delay_mwaitx+0x49/0x90
 [0.765682] PGD 0 
 [0.765688] Oops:  [#1] SMP
 [0.765693] Modules linked in:
 [0.765701] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
 4.8.13-coldkernel-grsec-1 #1
 [0.765709] task: 8800136bf540 task.stack: c9e38000
 [0.765714] RIP: e030:[]  [] 
 delay_mwaitx+0x49/0x90
 [0.765724] RSP: e02b:c9e3be50  EFLAGS: 00010087
 [0.765729] RAX: 87ff95a17300 RBX: 0001 RCX: 
 
 [0.765735] RDX:  RSI: 00039262adda8fdb RDI: 
 0002a4e4
 [0.765740] RBP: 81c17300 R08:  R09: 
 
 [0.765745] R10: 0002 R11: 000f R12: 
 0200
 [0.765749] R13: c9e3bea7 R14: 824055e8 R15: 
 607e4ce58fa6249c
 [0.765758] FS:  () GS:880013e0() 
 knlGS:
 [0.765765] CS:  e033 DS:  ES:  CR0: 80050033
 [0.765770] CR2: 87ff95a17300 CR3: 020c2000 CR4: 
 00040660
 [0.765775] Stack:
 [0.765779]  0001 10d1 814956a5 
 95fa1589597478a1
 [0.765788]  814960d0 95fa1589597478a1 c9e3bec8 
 06937a89d974aa7d
 [0.765797]  ffed 8236af42 df7e4ce58fa6249c 
 
 [0.765807] Call Trace:
 [0.765815]  [] ? i8042_wait_write+0x25/0x70
 [0.765822]  [] ? i8042_command+0x30/0x80
 [0.765829]  [] ? i8042_init+0x606/0x6f8
 [0.765835]  [] ? i8042_probe+0xa41/0xa41
 [0.765842]  [] ? do_one_initcall+0x4d/0x170
 [0.765849]  [] ? kernel_init_freeable+0x202/0x2ff
 [0.765856]  [] ? kernel_init+0x5/0x118
 [0.765861]  [] ? ret_from_fork+0x1e/0x40
 [0.765867]  [] ? rest_init+0x88/0x88
 [0.765871] Code: 41 b8 ff ff ff ff 48 09 c6 41 ba 02 00 00 00 eb 09 48 
 29 c6 48 01 f7 48 89 c6 48 89 e8 65 48 03 05 25 25 cf 7e 4c 89 c9 4c 89 ca 
 <0f> 01 fa 4c 39 c7 4c 89 c3 4c 89 d8 48 0f 46 df 4c 89 d1 0f 01 
 [0.765920] RIP  [] delay_mwaitx+0x49/0x90
 [0.765927]  RSP 
 [0.765931] CR2: 87ff95a17300
 [0.765939] ---[ end trace 84bc057c0ef01aab ]---
 [0.765946] Kernel panic - not syncing: grsec: halting the system due 
 to suspicious kernel crash caused by root

 (Same error in both VMs.)

>>> Did you try passing along the "nopat" kernel option through grub to see
>>> if that made a difference?
>> Yes, but it didn't make a difference.
>>
> 
> Does it work when the VM has the entire compile environment? As in, if
> you follow the coldhak instructions directly, does it work? Or does it
> never work?
> 
> 
> 
Hi everyone,

Please be aware that there are a number of issues with using coldkernel
in the Fedora templates currently. Our goal is to push out 0.9b over the
holidays to address this.

For the time being, the Fedora instructions have been entirely removed
from the master git branch, and progress will be made on the 0.9b
branch, along with Whonix support.

Happy Holidays!

-- 
Colin Childs
Coldhak
https://coldhak.ca
Twitter: @coldhakca

-- 
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/e004ad67-8d69-f4fb-a040-5927e9157172%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: FYI: Experimental Qubes coldkernel support now available

[Foppe de Haan]

On Saturday, December 17, 2016 at 8:42:19 PM UTC+1, Reg Tiangha wrote:
> On 12/17/2016 11:47 AM, Foppe de Haan wrote:
> > On Saturday, December 17, 2016 at 7:40:25 PM UTC+1, Reg Tiangha wrote:
> >> On 12/17/2016 10:36 AM, Foppe de Haan wrote:
> >>> I also built the fedora kernel according to Reg's recipe, same issue.
> >>> Comparing boot logs, the problem seems to start here:
> >>>
> >>> [0.765662] BUG: unable to handle kernel paging request at 
> >>> 87ff95a17300
> >>> [0.765671] IP: [] delay_mwaitx+0x49/0x90
> >>> [0.765682] PGD 0 
> >>> [0.765688] Oops:  [#1] SMP
> >>> [0.765693] Modules linked in:
> >>> [0.765701] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> >>> 4.8.13-coldkernel-grsec-1 #1
> >>> [0.765709] task: 8800136bf540 task.stack: c9e38000
> >>> [0.765714] RIP: e030:[]  [] 
> >>> delay_mwaitx+0x49/0x90
> >>> [0.765724] RSP: e02b:c9e3be50  EFLAGS: 00010087
> >>> [0.765729] RAX: 87ff95a17300 RBX: 0001 RCX: 
> >>> 
> >>> [0.765735] RDX:  RSI: 00039262adda8fdb RDI: 
> >>> 0002a4e4
> >>> [0.765740] RBP: 81c17300 R08:  R09: 
> >>> 
> >>> [0.765745] R10: 0002 R11: 000f R12: 
> >>> 0200
> >>> [0.765749] R13: c9e3bea7 R14: 824055e8 R15: 
> >>> 607e4ce58fa6249c
> >>> [0.765758] FS:  () GS:880013e0() 
> >>> knlGS:
> >>> [0.765765] CS:  e033 DS:  ES:  CR0: 80050033
> >>> [0.765770] CR2: 87ff95a17300 CR3: 020c2000 CR4: 
> >>> 00040660
> >>> [0.765775] Stack:
> >>> [0.765779]  0001 10d1 814956a5 
> >>> 95fa1589597478a1
> >>> [0.765788]  814960d0 95fa1589597478a1 c9e3bec8 
> >>> 06937a89d974aa7d
> >>> [0.765797]  ffed 8236af42 df7e4ce58fa6249c 
> >>> 
> >>> [0.765807] Call Trace:
> >>> [0.765815]  [] ? i8042_wait_write+0x25/0x70
> >>> [0.765822]  [] ? i8042_command+0x30/0x80
> >>> [0.765829]  [] ? i8042_init+0x606/0x6f8
> >>> [0.765835]  [] ? i8042_probe+0xa41/0xa41
> >>> [0.765842]  [] ? do_one_initcall+0x4d/0x170
> >>> [0.765849]  [] ? kernel_init_freeable+0x202/0x2ff
> >>> [0.765856]  [] ? kernel_init+0x5/0x118
> >>> [0.765861]  [] ? ret_from_fork+0x1e/0x40
> >>> [0.765867]  [] ? rest_init+0x88/0x88
> >>> [0.765871] Code: 41 b8 ff ff ff ff 48 09 c6 41 ba 02 00 00 00 eb 09 
> >>> 48 29 c6 48 01 f7 48 89 c6 48 89 e8 65 48 03 05 25 25 cf 7e 4c 89 c9 4c 
> >>> 89 ca <0f> 01 fa 4c 39 c7 4c 89 c3 4c 89 d8 48 0f 46 df 4c 89 d1 0f 01 
> >>> [0.765920] RIP  [] delay_mwaitx+0x49/0x90
> >>> [0.765927]  RSP 
> >>> [0.765931] CR2: 87ff95a17300
> >>> [0.765939] ---[ end trace 84bc057c0ef01aab ]---
> >>> [0.765946] Kernel panic - not syncing: grsec: halting the system due 
> >>> to suspicious kernel crash caused by root
> >>>
> >>> (Same error in both VMs.)
> >>>
> >> Did you try passing along the "nopat" kernel option through grub to see
> >> if that made a difference?
> > Yes, but it didn't make a difference.
> >
> 
> Does it work when the VM has the entire compile environment? As in, if
> you follow the coldhak instructions directly, does it work? Or does it
> never work?

Never. I compiled the d8/9 kernels in their respective (cloned) templates, but 
got nowhere.

-- 
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/81402c97-b403-4d1d-a805-a507ce21db0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: FYI: Experimental Qubes coldkernel support now available

[Reg Tiangha]

On 12/17/2016 11:47 AM, Foppe de Haan wrote:
> On Saturday, December 17, 2016 at 7:40:25 PM UTC+1, Reg Tiangha wrote:
>> On 12/17/2016 10:36 AM, Foppe de Haan wrote:
>>> I also built the fedora kernel according to Reg's recipe, same issue.
>>> Comparing boot logs, the problem seems to start here:
>>>
>>> [0.765662] BUG: unable to handle kernel paging request at 
>>> 87ff95a17300
>>> [0.765671] IP: [] delay_mwaitx+0x49/0x90
>>> [0.765682] PGD 0 
>>> [0.765688] Oops:  [#1] SMP
>>> [0.765693] Modules linked in:
>>> [0.765701] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
>>> 4.8.13-coldkernel-grsec-1 #1
>>> [0.765709] task: 8800136bf540 task.stack: c9e38000
>>> [0.765714] RIP: e030:[]  [] 
>>> delay_mwaitx+0x49/0x90
>>> [0.765724] RSP: e02b:c9e3be50  EFLAGS: 00010087
>>> [0.765729] RAX: 87ff95a17300 RBX: 0001 RCX: 
>>> 
>>> [0.765735] RDX:  RSI: 00039262adda8fdb RDI: 
>>> 0002a4e4
>>> [0.765740] RBP: 81c17300 R08:  R09: 
>>> 
>>> [0.765745] R10: 0002 R11: 000f R12: 
>>> 0200
>>> [0.765749] R13: c9e3bea7 R14: 824055e8 R15: 
>>> 607e4ce58fa6249c
>>> [0.765758] FS:  () GS:880013e0() 
>>> knlGS:
>>> [0.765765] CS:  e033 DS:  ES:  CR0: 80050033
>>> [0.765770] CR2: 87ff95a17300 CR3: 020c2000 CR4: 
>>> 00040660
>>> [0.765775] Stack:
>>> [0.765779]  0001 10d1 814956a5 
>>> 95fa1589597478a1
>>> [0.765788]  814960d0 95fa1589597478a1 c9e3bec8 
>>> 06937a89d974aa7d
>>> [0.765797]  ffed 8236af42 df7e4ce58fa6249c 
>>> 
>>> [0.765807] Call Trace:
>>> [0.765815]  [] ? i8042_wait_write+0x25/0x70
>>> [0.765822]  [] ? i8042_command+0x30/0x80
>>> [0.765829]  [] ? i8042_init+0x606/0x6f8
>>> [0.765835]  [] ? i8042_probe+0xa41/0xa41
>>> [0.765842]  [] ? do_one_initcall+0x4d/0x170
>>> [0.765849]  [] ? kernel_init_freeable+0x202/0x2ff
>>> [0.765856]  [] ? kernel_init+0x5/0x118
>>> [0.765861]  [] ? ret_from_fork+0x1e/0x40
>>> [0.765867]  [] ? rest_init+0x88/0x88
>>> [0.765871] Code: 41 b8 ff ff ff ff 48 09 c6 41 ba 02 00 00 00 eb 09 48 
>>> 29 c6 48 01 f7 48 89 c6 48 89 e8 65 48 03 05 25 25 cf 7e 4c 89 c9 4c 89 ca 
>>> <0f> 01 fa 4c 39 c7 4c 89 c3 4c 89 d8 48 0f 46 df 4c 89 d1 0f 01 
>>> [0.765920] RIP  [] delay_mwaitx+0x49/0x90
>>> [0.765927]  RSP 
>>> [0.765931] CR2: 87ff95a17300
>>> [0.765939] ---[ end trace 84bc057c0ef01aab ]---
>>> [0.765946] Kernel panic - not syncing: grsec: halting the system due to 
>>> suspicious kernel crash caused by root
>>>
>>> (Same error in both VMs.)
>>>
>> Did you try passing along the "nopat" kernel option through grub to see
>> if that made a difference?
> Yes, but it didn't make a difference.
>

Does it work when the VM has the entire compile environment? As in, if
you follow the coldhak instructions directly, does it work? Or does it
never work?



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

[qubes-users] building ubuntu14 template

[jd87]

hi.
i am trying to build an ubuntu14 template:

From the doc: 'Ubuntu 14.4 LTS (Trusty) can be built with little effort.'
So i assume it should work.

When executing `make qubes-vm` i get following error:

Ign http://ppa.launchpad.net trusty/main Translation-en
Reading package lists...
# Parse debian/control for Build-Depends and install
/home/user/qubes-builder/qubes-src/builder-debian//scripts/debian-parser
control --build-depends
/home/user/qubes-builder/chroot-trusty//home/user/qubes-src/vmm-xen/debian-vm/debian/control
|\
    xargs sudo chroot /home/user/qubes-builder/chroot-trusty apt-get 
install -y
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package libsystemd-dev
E: Unable to locate package libsystemd-dev
/home/user/qubes-builder/qubes-src/builder-debian/Makefile.qubuntu:167:
recipe for target 'dist-build-dep' failed
make[2]: *** [dist-build-dep] Error 123
Makefile.generic:139: recipe for target 'packages' failed
make[1]: *** [packages] Error 1
Makefile:209: recipe for target 'vmm-xen-vm' failed
make: *** [vmm-xen-vm] Error 1

what can i do to fix this?

-joe


-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  


--
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/20161217130938.Horde.iQXn3rJsqiEb4cnlyw_ZGg1%40www.vfemail.net.
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] Re: FYI: Experimental Qubes coldkernel support now available

[Foppe de Haan]

On Saturday, December 17, 2016 at 7:40:25 PM UTC+1, Reg Tiangha wrote:
> On 12/17/2016 10:36 AM, Foppe de Haan wrote:
> > I also built the fedora kernel according to Reg's recipe, same issue.
> > Comparing boot logs, the problem seems to start here:
> >
> > [0.765662] BUG: unable to handle kernel paging request at 
> > 87ff95a17300
> > [0.765671] IP: [] delay_mwaitx+0x49/0x90
> > [0.765682] PGD 0 
> > [0.765688] Oops:  [#1] SMP
> > [0.765693] Modules linked in:
> > [0.765701] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> > 4.8.13-coldkernel-grsec-1 #1
> > [0.765709] task: 8800136bf540 task.stack: c9e38000
> > [0.765714] RIP: e030:[]  [] 
> > delay_mwaitx+0x49/0x90
> > [0.765724] RSP: e02b:c9e3be50  EFLAGS: 00010087
> > [0.765729] RAX: 87ff95a17300 RBX: 0001 RCX: 
> > 
> > [0.765735] RDX:  RSI: 00039262adda8fdb RDI: 
> > 0002a4e4
> > [0.765740] RBP: 81c17300 R08:  R09: 
> > 
> > [0.765745] R10: 0002 R11: 000f R12: 
> > 0200
> > [0.765749] R13: c9e3bea7 R14: 824055e8 R15: 
> > 607e4ce58fa6249c
> > [0.765758] FS:  () GS:880013e0() 
> > knlGS:
> > [0.765765] CS:  e033 DS:  ES:  CR0: 80050033
> > [0.765770] CR2: 87ff95a17300 CR3: 020c2000 CR4: 
> > 00040660
> > [0.765775] Stack:
> > [0.765779]  0001 10d1 814956a5 
> > 95fa1589597478a1
> > [0.765788]  814960d0 95fa1589597478a1 c9e3bec8 
> > 06937a89d974aa7d
> > [0.765797]  ffed 8236af42 df7e4ce58fa6249c 
> > 
> > [0.765807] Call Trace:
> > [0.765815]  [] ? i8042_wait_write+0x25/0x70
> > [0.765822]  [] ? i8042_command+0x30/0x80
> > [0.765829]  [] ? i8042_init+0x606/0x6f8
> > [0.765835]  [] ? i8042_probe+0xa41/0xa41
> > [0.765842]  [] ? do_one_initcall+0x4d/0x170
> > [0.765849]  [] ? kernel_init_freeable+0x202/0x2ff
> > [0.765856]  [] ? kernel_init+0x5/0x118
> > [0.765861]  [] ? ret_from_fork+0x1e/0x40
> > [0.765867]  [] ? rest_init+0x88/0x88
> > [0.765871] Code: 41 b8 ff ff ff ff 48 09 c6 41 ba 02 00 00 00 eb 09 48 
> > 29 c6 48 01 f7 48 89 c6 48 89 e8 65 48 03 05 25 25 cf 7e 4c 89 c9 4c 89 ca 
> > <0f> 01 fa 4c 39 c7 4c 89 c3 4c 89 d8 48 0f 46 df 4c 89 d1 0f 01 
> > [0.765920] RIP  [] delay_mwaitx+0x49/0x90
> > [0.765927]  RSP 
> > [0.765931] CR2: 87ff95a17300
> > [0.765939] ---[ end trace 84bc057c0ef01aab ]---
> > [0.765946] Kernel panic - not syncing: grsec: halting the system due to 
> > suspicious kernel crash caused by root
> >
> > (Same error in both VMs.)
> >
> 
> Did you try passing along the "nopat" kernel option through grub to see
> if that made a difference?

Yes, but it didn't make a difference.

-- 
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/e8b03b6d-5604-48e9-9c4a-40118e3783a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: JeOS?

[J. Eppler]

Hello,

have you thought about Unikernel Operating Systems. They offer really just the 
bare minimum for one single application. MirageOS is the one for Xen.

regards
  J. Eppler

-- 
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/cef0dc2d-2ed7-4fc1-8b9f-c7e3f50b00ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Updates, security

[entr0py]

johnyju...@sigaint.org:
> While updates are signed, so even if they come over the wire in cleartext,
> the fact that they often are sent in the clear (even from debian.net)
> allows a snooper to know what packages your scanning for metadata or
> installing.  It reveals a lot about the state of your system.
> 
> Updating over Tor or a VPN helps a bit.  Updating to debian's hidden
> service is even more ideal, no https in between with
> state-actor/CA-forgeable certificates possible, etc..
> 
> However, Qubes updates aren't available via Tor.
> 

WIP: https://forums.whonix.org/t/onionizing-qubes-whonix-repositories/3265

-- 
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/cfa5428c-74d2-9933-ad7c-ef62ce4f5bc1%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] JeOS?

[johnyjukya]

I've converted all my VM's to debian-8, and I'm continuing the
never-ending process to trim down the service vm's to the bare minimum
underlying template.

No sense having cups, pulseaudio, libreoffice, etc, lurking around in a
dedicated packet-flinger VM.  Especially with the dozens of processes that
might just wake up and phone home unexpectedly (like going to MS for a
samba name resolution, or whatever).

(I was thinking that a highly restrictive apparmor process might be an
interesting way to use a common fully-loaded template both for work
AppVMs, and (using the restrictive apparmor configuration) the
net/firewall VM's.  But I don't want to add more complexity, and more
trust in apparmor.)

In this process, I stumbled across a new acronym to me, a JeOS:

https://en.wikipedia.org/wiki/Just_enough_operating_system

They looks like they might be well-suited to being a great virtual device
for the various service vms.  They're also typically tuned to run in VM's.

I'm going to give a couple of them a try, maybe CoreOS and the Ubuntu one.
 CoreOS is gentoo based, so the Ubuntu one might be a bit closer to
debian-8.

Will report back any fun and excitement that results.

-j

-- 
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/10bd300c7647cf73eb292d5ede21b064.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: FYI: Experimental Qubes coldkernel support now available

[Reg Tiangha]

On 12/17/2016 10:36 AM, Foppe de Haan wrote:
> I also built the fedora kernel according to Reg's recipe, same issue.
> Comparing boot logs, the problem seems to start here:
>
> [0.765662] BUG: unable to handle kernel paging request at 87ff95a17300
> [0.765671] IP: [] delay_mwaitx+0x49/0x90
> [0.765682] PGD 0 
> [0.765688] Oops:  [#1] SMP
> [0.765693] Modules linked in:
> [0.765701] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> 4.8.13-coldkernel-grsec-1 #1
> [0.765709] task: 8800136bf540 task.stack: c9e38000
> [0.765714] RIP: e030:[]  [] 
> delay_mwaitx+0x49/0x90
> [0.765724] RSP: e02b:c9e3be50  EFLAGS: 00010087
> [0.765729] RAX: 87ff95a17300 RBX: 0001 RCX: 
> 
> [0.765735] RDX:  RSI: 00039262adda8fdb RDI: 
> 0002a4e4
> [0.765740] RBP: 81c17300 R08:  R09: 
> 
> [0.765745] R10: 0002 R11: 000f R12: 
> 0200
> [0.765749] R13: c9e3bea7 R14: 824055e8 R15: 
> 607e4ce58fa6249c
> [0.765758] FS:  () GS:880013e0() 
> knlGS:
> [0.765765] CS:  e033 DS:  ES:  CR0: 80050033
> [0.765770] CR2: 87ff95a17300 CR3: 020c2000 CR4: 
> 00040660
> [0.765775] Stack:
> [0.765779]  0001 10d1 814956a5 
> 95fa1589597478a1
> [0.765788]  814960d0 95fa1589597478a1 c9e3bec8 
> 06937a89d974aa7d
> [0.765797]  ffed 8236af42 df7e4ce58fa6249c 
> 
> [0.765807] Call Trace:
> [0.765815]  [] ? i8042_wait_write+0x25/0x70
> [0.765822]  [] ? i8042_command+0x30/0x80
> [0.765829]  [] ? i8042_init+0x606/0x6f8
> [0.765835]  [] ? i8042_probe+0xa41/0xa41
> [0.765842]  [] ? do_one_initcall+0x4d/0x170
> [0.765849]  [] ? kernel_init_freeable+0x202/0x2ff
> [0.765856]  [] ? kernel_init+0x5/0x118
> [0.765861]  [] ? ret_from_fork+0x1e/0x40
> [0.765867]  [] ? rest_init+0x88/0x88
> [0.765871] Code: 41 b8 ff ff ff ff 48 09 c6 41 ba 02 00 00 00 eb 09 48 29 
> c6 48 01 f7 48 89 c6 48 89 e8 65 48 03 05 25 25 cf 7e 4c 89 c9 4c 89 ca <0f> 
> 01 fa 4c 39 c7 4c 89 c3 4c 89 d8 48 0f 46 df 4c 89 d1 0f 01 
> [0.765920] RIP  [] delay_mwaitx+0x49/0x90
> [0.765927]  RSP 
> [0.765931] CR2: 87ff95a17300
> [0.765939] ---[ end trace 84bc057c0ef01aab ]---
> [0.765946] Kernel panic - not syncing: grsec: halting the system due to 
> suspicious kernel crash caused by root
>
> (Same error in both VMs.)
>

Did you try passing along the "nopat" kernel option through grub to see
if that made a difference?



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

[qubes-users] OpenVPN and debian-8

[johnyjukya]

I've finished my conversion of all VM's to debian-8 (and isolating USB,
the sound card, etc.).  (Next is dom0, and maybe the replacing the
hypervisor, but that's another story. :) )

The last hiccup was getting OpenVPN working in debian-8 in a ProxyVM.  It
would connect, but then get stupid and hangup.

Turns out the problem is that OpenVPN 2.3.4 included with Debian-8, will
fail to add a default static route to the VPN provider ("route add w.x.y.z
gw 10.137.2.1 eth0" kinda thing) if the netmask of the WAN interface is
255.255.255.255.  (There's some bug post out there related to this.)

Without the route, all traffic, including traffic intended to the VPN
provider, gets stuff into the tun0 VPN pipe, which wedges it.

If you're quick, you can add the route at the right time to save the
connection.  But the right solution is fixing the netmask.

If you change the wan IP netmask to 255.255.255.0, then when OpenVPN
connects, the static route gets added, and the VPN connection stays up.

However, the default seems to get changed back on next AppVM boot.  I
think the qubes Vm startup code is grabbing the netmask from qubesdb
(qubesdb-read /qubes-netmask), and I think dom0 is setting that statically
in the code.  (I don't see it in qvm-prefs, qubesdb, xenstore, and haven't
had time to dig further.)

I can see why Qubes would choose 255.255.255.255, since VM link adapters
can't access others on their subnet directly, but have to bounce through
their netvm (a good thing, security-wise).

However, using 255.255.255.0 should be harmless, since you can still only
directly access 10.137.*.1 anyway; and it would avoid messing up Debian's
OpenVPN connections.  (Admittedly working around an OpenVPN but, but an
easy and harmless fix.)

fedora23 uses OpenVM 2.3.13 which doesn't seem to suffer from this problem.

I tried grabbing an OpenVM from backports, but there wasn't anything newer.

Cheers,

-d

-- 
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/8d42cf40f8974d4b57c871890262a7a5.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Updates, security

[johnyjukya]

While updates are signed, so even if they come over the wire in cleartext,
the fact that they often are sent in the clear (even from debian.net)
allows a snooper to know what packages your scanning for metadata or
installing.  It reveals a lot about the state of your system.

Updating over Tor or a VPN helps a bit.  Updating to debian's hidden
service is even more ideal, no https in between with
state-actor/CA-forgeable certificates possible, etc..

However, Qubes updates aren't available via Tor.

I do notice, however, that the qubes repository will allow changing the
"http" to "https" in the qubes entry /etc/apt/sources.list.d/.  (You'd
have to install "apt-transport-https" too.)

Do the Qubes folks have a problem with this?  It'd put extra load on the
servers, so I thought I'd ask.

I might suggest it would make a good default, if the load wouldn't be
unacceptable.

Cheers,

-d

-- 
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/617051ede5374543bb82e5f406e1cee9.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes Windows 7 HVM & Windows update

[entr0py]

Andrew David Wong:
> On 2016-12-17 03:44, Swâmi Petaramesh wrote:
>> Hi there,
> 
>> I have attempted several installations of Windows-7 in a HVM (32 or
>> 64 bits, with or without Qubes Windows tools for the 64-bit
>> version...) and it "basically works", which means that Windows
>> starts, I can use the explorer, I have Internet access, etc.
> 
>> BUT, on *ALL* installations I attempted, Windows cannot use
>> "Windows Update" : When starting Windows update, the Win7 VM will
>> stay at the "Checking for updates" phase forever, without any
>> visible progress, until the VM eventually crashes.

Make sure you have enough RAM. Min 2 GB but I'd go with 4 GB until upgrades are 
done. You can lower it back afterwards.
And disk space. 7 GB initial install can balloon to 30 GB during upgrade 
process before settling in around 20 GB.


> 
> This is a longstanding Windows problem:
> 
> https://superuser.com/questions/951960/windows-7-sp1-windows-update-stuck-checking-for-updates
> 
> 

Fixed! (for now)

https://answers.microsoft.com/en-us/windows/forum/windows_7-update/windows-7-update-solution/f39a65fa-9d10-42e7-9bc0-7f5096b36d0c

Windows downloads full list of needed upgrades in minutes. Only one (or two) 
patches needed.

-- 
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/4caa6572-9657-743d-5fc3-34a5c3b65ac3%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: disk passphrase failing with error message "luks_open failed for /dev/sda2 with errno -1"

[Hello Mister]

On Saturday, December 17, 2016 at 5:19:10 PM UTC+5:30, Swâmi Petaramesh wrote:
> Le 17/12/2016 à 12:22, Hello Mister a écrit :
> >> When you attempt to boot this installation normally, what happens? The
> >> same LUKS error as above?
> > 
> > == >> Same error after a long wait both in GUI & CLI
> 
> I'm afraid that you may have, by starting a reinstallation over a
> previous installation, already somewhat destroyed or reformatted your
> LUKS partition, thus irremediably destroying all of its contents.
> 
> I would advise you to boot from a live distro such as Partition Magic
> (Or an Ubuntu or Mint live CD), and WITHOUT starting any installer, try
> to manually
> 
> # cryptsetup luksOpen /dev/sda2 open_sda2
> 
> ...If your passphrase works that's good. if it doesn't, that's probably
> dead.
> 
> Good luck !
> 
> ॐ
> 
> -- 
> Swâmi Petaramesh  PGP 9076E32E

Luks error started way before I even thought of reinstallation attempt.

-- 
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/e3a7c452-7c91-4358-ad6a-2fcf887a567f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: FYI: Experimental Qubes coldkernel support now available

[Foppe de Haan]

I also built the fedora kernel according to Reg's recipe, same issue.
Comparing boot logs, the problem seems to start here:

[0.765662] BUG: unable to handle kernel paging request at 87ff95a17300
[0.765671] IP: [] delay_mwaitx+0x49/0x90
[0.765682] PGD 0 
[0.765688] Oops:  [#1] SMP
[0.765693] Modules linked in:
[0.765701] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.8.13-coldkernel-grsec-1 #1
[0.765709] task: 8800136bf540 task.stack: c9e38000
[0.765714] RIP: e030:[]  [] 
delay_mwaitx+0x49/0x90
[0.765724] RSP: e02b:c9e3be50  EFLAGS: 00010087
[0.765729] RAX: 87ff95a17300 RBX: 0001 RCX: 
[0.765735] RDX:  RSI: 00039262adda8fdb RDI: 0002a4e4
[0.765740] RBP: 81c17300 R08:  R09: 
[0.765745] R10: 0002 R11: 000f R12: 0200
[0.765749] R13: c9e3bea7 R14: 824055e8 R15: 607e4ce58fa6249c
[0.765758] FS:  () GS:880013e0() 
knlGS:
[0.765765] CS:  e033 DS:  ES:  CR0: 80050033
[0.765770] CR2: 87ff95a17300 CR3: 020c2000 CR4: 00040660
[0.765775] Stack:
[0.765779]  0001 10d1 814956a5 
95fa1589597478a1
[0.765788]  814960d0 95fa1589597478a1 c9e3bec8 
06937a89d974aa7d
[0.765797]  ffed 8236af42 df7e4ce58fa6249c 

[0.765807] Call Trace:
[0.765815]  [] ? i8042_wait_write+0x25/0x70
[0.765822]  [] ? i8042_command+0x30/0x80
[0.765829]  [] ? i8042_init+0x606/0x6f8
[0.765835]  [] ? i8042_probe+0xa41/0xa41
[0.765842]  [] ? do_one_initcall+0x4d/0x170
[0.765849]  [] ? kernel_init_freeable+0x202/0x2ff
[0.765856]  [] ? kernel_init+0x5/0x118
[0.765861]  [] ? ret_from_fork+0x1e/0x40
[0.765867]  [] ? rest_init+0x88/0x88
[0.765871] Code: 41 b8 ff ff ff ff 48 09 c6 41 ba 02 00 00 00 eb 09 48 29 
c6 48 01 f7 48 89 c6 48 89 e8 65 48 03 05 25 25 cf 7e 4c 89 c9 4c 89 ca <0f> 01 
fa 4c 39 c7 4c 89 c3 4c 89 d8 48 0f 46 df 4c 89 d1 0f 01 
[0.765920] RIP  [] delay_mwaitx+0x49/0x90
[0.765927]  RSP 
[0.765931] CR2: 87ff95a17300
[0.765939] ---[ end trace 84bc057c0ef01aab ]---
[0.765946] Kernel panic - not syncing: grsec: halting the system due to 
suspicious kernel crash caused by root

(Same error in both 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/019a7c03-8ffd-444f-9267-ae4bd8db1b50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: is kaby lake too new?

[Krasi]

On Friday, December 16, 2016 at 7:11:22 PM UTC-6, pixel fairy wrote:
> On Friday, December 16, 2016 at 4:42:30 PM UTC-8, pixel fairy wrote:
> > tried installing qubes-3.2 on an i7 kaby lake laptop. efi mode gave the 
> > reboot issue noted in the troubleshooting efi page, but neither solution 
> > helped. should i try building a newer version?
> 
> the laptop is a system76 lemur7


I just installed it on Core i7-7500U, I was able to install it in EFI mode but 
was unable to boot to it and had to edit the EFI partition. As far as I 
understand Qubes does not install grub when installed in EFI mode, you might 
have to boot from a live USB, mount the EFI partition and make changes to the 
xen.cfg file.

After that you should be able to boot into Qubes or select your OS from BIOS if 
you are dual-booting.

I hope this helps :)

-- 
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/b4a3f898-825f-42df-9cb5-a1f57a95f3d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Full Screen

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-12-17 07:18, Loren Rogers wrote:
> Perfect! Thanks for pointing that out. It may also be useful to 
> mention the ALT+SPACE XFCE shortcut.
> 
> Loren
> 

Thanks. Updated.

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

iQIcBAEBCgAGBQJYVWHwAAoJENtN07w5UDAwzjQP/0XDn2OJGqhY1Z4T1fZEtI28
f3PRsKH4pY2WOtVmMJinIHNpRIC6paLuyAw3TACqcSAEdubCbFFQMJstxJnzvsRQ
+48RzgWHdEUl0Fqy5qq1/pmq5/NJv2Ro84zmlL23IV51jzo7ESLu7bMfMQVkuXy0
gqszQIRlA9dqGkTm5KYyosFf+vWnN/Ihrk2xo7AwO4z4Q6gsdj0SzexdeKBDd3gd
rJzZkdoUuHssWroC97LZJwLxU+6kVWLgtOO9yrProsu9il7rEr7gl3CnAljhN0nU
BAh1qiTvrc7QjPGpAGuCjrbbkrnNzbbPezyLNnynDwrOZjKswfluXvP+S3eTw0tN
Dy5itl/knpyd9TiTTE9ALZExRp4u16iJy54ccVwdjYnCnVlhEm+e/8qsYrGXvACm
BLI+JLZaFsa9mY+6kH69b1ukPFce2JbJzoOVKEgM2ToMhLm++EAkDiOTgYs1HM4V
8JMDqm4I8R44NFKGOL231MICtlxSAl0osUr079pjAhRz7rWfMpJo90FHoBPyMkJT
uUTzgv5N9TNHXK2j3/3F1oLcF/4R0rokziP++/N+7fI6REjGzlxlP3AEoTkXQIhK
573yt8/+XKlx2IFmnI5pK9KU1HU+txOd53smAGiC7mbY5WZl108ufeRnfF/ApH14
5SOj1xTDwbfdiIVE6IUs
=LGWW
-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/252f880b-bc78-d7e2-d400-9e7fb7a749ad%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Full Screen

['Loren Rogers' via qubes-users]

 Original Message 
Subject: Re: [qubes-users] Full Screen
Local Time: December 17, 2016 10:15 AM
UTC Time: December 17, 2016 3:15 PM
From: a...@qubes-os.org
To: Unman , Loren Rogers 

qubes-users 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-12-17 06:00, Unman wrote:
> On Sat, Dec 17, 2016 at 08:51:37AM -0500, 'Loren Rogers' via
> qubes-users wrote:
>> Hi all,
>>
>> I'm not sure how I do it, but sometimes my applications go into
>> full-screen mode. This usually happens when I press a shortcut by
>> accident, so I'm not sure what the shortcut actually is. (I'm
>> usually trying to do something else, and I bump the wrong key.)
>> But, I know that I can make a window full-screen by
>> right-clicking the top bar of the window and selecting
>> Fullscreen.
>>
>> How do I get out of this?
>>
>> So far, my only solution has been to close the window or
>> otherwise quit out of the application. Although not the end of
>> the world, it's super annoying. [The docs say]
>> (https://www.qubes-os.org/doc/full-screen-mode/)that full screen
>> needs to be enabled for a VM to use it, but is this no longer
>> the case? Is it enabled by default?
>>
>> Thanks in advance, Loren
>>
>
> Yes, you are right about the docs.
>
> No need to close the application. In the window, try ALT+SPACE -
> this will show you the window menu and you can "Leave Fullscreen".
> That's an Xfce thing.
>
> unman
>

Looks like this was documented on this page:

https://www.qubes-os.org/doc/config-files/

But not on the fullscreen mode page. I've updated the latter.

Here's the relevant portion:

"Regardless of the settings [in /etc/qubes/guid.conf], you can always
put a window into fullscreen mode using the trusted window manager by
right-clicking on a window’s title bar and selecting 'Fullscreen'."

The new functionality should still be considered safe, since a VM
window still can't voluntarily enter fullscreen mode. The user has to
select this option from the trusted window manager in dom0.

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

iQIcBAEBCgAGBQJYVVaUAAoJENtN07w5UDAwhdQP/ik+7oig/RwBEupeI3WgR5nM
giZbfIWkK4MrY9/D+FE8XPshNyjv7r75avwvA2W2Kfs+7jheUl/HT6s80zC7yp/f
/WQJNMRlNcTbhV9nvc5cGnS5bb/vB24X7jwJeBM75xf1Em0DI44KwAOiS0ofiND1
0x0BVzLlQuMsPoPp9sc5CJjfqnX1IIeYzzXClDImw6AZRSfUwbP0hXHppLl6UbH4
65/hGmMQqNbB5lSVh4SwLaw9S3N5/LCqkJkQs6XDuGLE0b+8jETuOZ1ezC0sY4k6
MZt+B/EiIkAv3WXHZJ/HOhhDe5C4tsw7AfYQcwDW0ivoMQP7J93IarhcrcSs6WaZ
xS6YJPsW30CTlw8App67oOC6zf5phhornCXqVq2hHzMQawSUsAA6+vscoZUxGBJJ
sMB4WlpWavQL9BihMnNaN//qUb8Az8yXEgrGDhQXo17CNjGciLkMh5OupdJHrNH2
xY5J9PbvTcs7FRjdGxdQrB2bpa5o/OaE42gNbePYRFAVp3/gPBKY2ibMEZchu83c
53ssDVlEL3YQQpDzFkEonbRHykrycv2fuQGpFtLSI4ubkog7tW4CkipJyIT8Fm3k
pZfsHOQ7IgEG4e7pA9udmpmohWeOIOZvINk2MoB1Lb31/aNX9j1eZx7QobGFas2j
TyzOWBsVrpJ6p59GN25V
=6W48
-END PGP SIGNATURE-

Perfect! Thanks for pointing that out. It may also be useful to mention the 
ALT+SPACE XFCE shortcut.

Loren

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

Re: [qubes-users] Full Screen

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-12-17 06:00, Unman wrote:
> On Sat, Dec 17, 2016 at 08:51:37AM -0500, 'Loren Rogers' via 
> qubes-users wrote:
>> Hi all,
>> 
>> I'm not sure how I do it, but sometimes my applications go into 
>> full-screen mode. This usually happens when I press a shortcut by
>> accident, so I'm not sure what the shortcut actually is. (I'm 
>> usually trying to do something else, and I bump the wrong key.) 
>> But, I know that I can make a window full-screen by 
>> right-clicking the top bar of the window and selecting 
>> Fullscreen.
>> 
>> How do I get out of this?
>> 
>> So far, my only solution has been to close the window or 
>> otherwise quit out of the application. Although not the end of 
>> the world, it's super annoying. [The docs say] 
>> (https://www.qubes-os.org/doc/full-screen-mode/)that full screen
>>  needs to be enabled for a VM to use it, but is this no longer 
>> the case? Is it enabled by default?
>> 
>> Thanks in advance, Loren
>> 
> 
> Yes, you are right about the docs.
> 
> No need to close the application. In the window, try ALT+SPACE - 
> this will show you the window menu and you can "Leave Fullscreen". 
> That's an Xfce thing.
> 
> unman
> 

Looks like this was documented on this page:

https://www.qubes-os.org/doc/config-files/

But not on the fullscreen mode page. I've updated the latter.

Here's the relevant portion:

"Regardless of the settings [in /etc/qubes/guid.conf], you can always
put a window into fullscreen mode using the trusted window manager by
right-clicking on a window’s title bar and selecting 'Fullscreen'."

The new functionality should still be considered safe, since a VM
window still can't voluntarily enter fullscreen mode. The user has to
select this option from the trusted window manager in dom0.

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

iQIcBAEBCgAGBQJYVVaUAAoJENtN07w5UDAwhdQP/ik+7oig/RwBEupeI3WgR5nM
giZbfIWkK4MrY9/D+FE8XPshNyjv7r75avwvA2W2Kfs+7jheUl/HT6s80zC7yp/f
/WQJNMRlNcTbhV9nvc5cGnS5bb/vB24X7jwJeBM75xf1Em0DI44KwAOiS0ofiND1
0x0BVzLlQuMsPoPp9sc5CJjfqnX1IIeYzzXClDImw6AZRSfUwbP0hXHppLl6UbH4
65/hGmMQqNbB5lSVh4SwLaw9S3N5/LCqkJkQs6XDuGLE0b+8jETuOZ1ezC0sY4k6
MZt+B/EiIkAv3WXHZJ/HOhhDe5C4tsw7AfYQcwDW0ivoMQP7J93IarhcrcSs6WaZ
xS6YJPsW30CTlw8App67oOC6zf5phhornCXqVq2hHzMQawSUsAA6+vscoZUxGBJJ
sMB4WlpWavQL9BihMnNaN//qUb8Az8yXEgrGDhQXo17CNjGciLkMh5OupdJHrNH2
xY5J9PbvTcs7FRjdGxdQrB2bpa5o/OaE42gNbePYRFAVp3/gPBKY2ibMEZchu83c
53ssDVlEL3YQQpDzFkEonbRHykrycv2fuQGpFtLSI4ubkog7tW4CkipJyIT8Fm3k
pZfsHOQ7IgEG4e7pA9udmpmohWeOIOZvINk2MoB1Lb31/aNX9j1eZx7QobGFas2j
TyzOWBsVrpJ6p59GN25V
=6W48
-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/c0469212-c00f-8740-097a-963a51a06c19%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Networking & firewall

[Unman]

On Sat, Dec 17, 2016 at 11:01:59AM +0100, Marc de Bruin wrote:
> Hi Jos,
> 
> > 
> > Can anyone point out some more reading material? If any?
> > 
> > Cheers!
> > Jos
> > 
> 
> I would like to know this as well! 
> 
> Anybody that would like to join and share? 
> 
> Thnx,
> 
> Greetz,
> Marc.
> 
> -- 

There isn't any additional reading material other than the pages Jos has
referenced, and list archives
But it is (relatively) straightforward,

- how much NATting is going on?

It's all NAT.
Look at the basic iptables rules in a netvm and you will see that all
downstream traffic is subject to NAT by MASQUERADE in the postrouting
table.

iptables -L -nv -t nat:
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
0 0 ACCEPT all  --  *  vif+0.0.0.0/0 0.0.0.0/0   
0 0 ACCEPT all  --  *  lo  0.0.0.0/0 0.0.0.0/0   
7   424 MASQUERADE  all  --  *  *   0.0.0.0/0 0.0.0.0/0 


- what role does proxy arp play? Is it still used in 3.2?
Yes, proxy arp has been re-enabled in 3.2. It isn't essential in most
use cases. 


To get to Jos's question re the chromecast:
There are two elements to this: getting the qube to see the chromecast
and allowing return traffic inbound.

You need to allow UDP traffic on high ports from the qube
You need to allow TCP outbound to (I think) 8008:8009
You need to allow UDP outbound to port 1900 on multicast
You need to allow  UDP traffic on high ports from the Chromecast to the
qube, so you will need to follow the guide on routing inbound traffic to
a qube.

There's no problem in using tcpdump and iptables on the firewall to see
what's going on. I tend to dump the traffic and then parse it on a
separate qube.
Judicious use of logging in iptables will help you see what's going on,
but there's enough here to get started I hope.

unman

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

Re: [qubes-users] Full Screen

[Unman]

On Sat, Dec 17, 2016 at 08:51:37AM -0500, 'Loren Rogers' via qubes-users wrote:
> Hi all,
> 
> I'm not sure how I do it, but sometimes my applications go into full-screen 
> mode. This usually happens when I press a shortcut by accident, so I'm not 
> sure what the shortcut actually is. (I'm usually trying to do something else, 
> and I bump the wrong key.) But, I know that I can make a window full-screen 
> by right-clicking the top bar of the window and selecting Fullscreen.
> 
> How do I get out of this?
> 
> So far, my only solution has been to close the window or otherwise quit out 
> of the application. Although not the end of the world, it's super annoying. 
> [The docs say ](https://www.qubes-os.org/doc/full-screen-mode/)that full 
> screen needs to be enabled for a VM to use it, but is this no longer the 
> case? Is it enabled by default?
> 
> Thanks in advance,
> Loren
> 

Yes, you are right about the docs.

No need to close the application.
In the window, try ALT+SPACE - this will show you the window menu and
you can "Leave Fullscreen". That's an Xfce thing.

unman  

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

[qubes-users] Full Screen

['Loren Rogers' via qubes-users]

Hi all,

I'm not sure how I do it, but sometimes my applications go into full-screen 
mode. This usually happens when I press a shortcut by accident, so I'm not sure 
what the shortcut actually is. (I'm usually trying to do something else, and I 
bump the wrong key.) But, I know that I can make a window full-screen by 
right-clicking the top bar of the window and selecting Fullscreen.

How do I get out of this?

So far, my only solution has been to close the window or otherwise quit out of 
the application. Although not the end of the world, it's super annoying. [The 
docs say ](https://www.qubes-os.org/doc/full-screen-mode/)that full screen 
needs to be enabled for a VM to use it, but is this no longer the case? Is it 
enabled by default?

Thanks in advance,
Loren

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

[qubes-users] HCL - Lenovo Thinkpad Edge E560

[Wojciech Gustowski]

Hi,
Today I installed QUBES on my E560. Everything seems to work without issues. 
Only problem is with TPM - it is not recognized. I am not sure why. I didn't 
test AMD Radeon R7 M370 card.

Thank You.

Wojtek

-- 
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/091980ab-c4d0-4f8a-99a7-8be168d0fcc4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-LENOVO-20EV0011PB-20161217-133207.yml
Description: Binary data

[qubes-users] Re: Hardware acceleration in Chrome (or "make google maps great again!")

[cyrinux]

Le dimanche 11 décembre 2016 07:52:29 UTC+1, Jean-Philippe Ouellet a écrit :
> Hello,
> 
> Google Chrome disabled the chrome://flags mechanism to disable WebGL
> some time ago, but now it appears that it is back as "Use hardware
> acceleration when available" at the bottom of the Advanced section of
> chrome://settings.
> 
> Disabling this makes google maps not lag/crash for me! :)
> 
> Perhaps everyone has already done this and I'm just late to the party,
> but I don't remember seeing it discussed in a capacity other than
> "yeah... this is a problem", so I figured I'd share.
> 
> Cheers,
> Jean-Philippe

Thanks!!!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0430a091-0329-4762-bc60-e4a2487eb431%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: disk passphrase failing with error message "luks_open failed for /dev/sda2 with errno -1"

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-12-17 04:22, Swâmi Petaramesh wrote:
> Le 17/12/2016 à 13:07, Andrew David Wong a écrit :
>> 
>>> # cryptsetup luksOpen /dev/sda2 open_sda2
>> 
>>> ...If your passphrase works that's good. if it doesn't, that's 
>>> probably dead.
>> 
>> 
>> Yes, this is the third thing I was asking about. However, it's
>> not necessary to use a live OS to do this. (You can if you want,
>> of course.) As I mentioned above, the Qubes installer will work
>> fine for this purpose if you switch over to a virtual console
>> (e.g., ctrl + alt + F2). (Of course, you don't want to actually
>> try to run the installer in this situation!)
> 
> My point was that some distros have live version (or even ISOs that
> are especially meant to be used as a live tool such as Partition
> Magic), that will be much more comfortable using in a clean GUI,
> than an ISO which is meant as a bare installer - And you'll be less
> prone to starting it by mistake if the installer isn't there ;-)
> 

Well, yes, but if all you're doing is

> # cryptsetup luksOpen /dev/sda2 open_sda2

as you suggested, then those extra features aren't in play, and it'll
probably be more convenient to use the Qubes installation medium you
already have on hand. At any rate, I think we agree that both ways
will work. Whichever you prefer is fine.

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

iQIcBAEBCgAGBQJYVTPGAAoJENtN07w5UDAwHMQP/Ayu7ZHbIYYXQvTqkejXsL/I
weneyP8zYyae0VOSSCmYoT/DHWbq//8DE5OYQgEGo3kelbqzogTrXhZYUsjoGcj5
sQWQr2K711xy6bU4aGjFDaApub5a88bTIGSMEl3JMrTQKnBu/KAqG+RAiEw392AO
k4Sa0bPVrmCND1U9nCFpyaNf4gs0iaAdLPrfy4bjSUFjozd5p6vaMgXgl5oNwEQR
8uXCWJsGtLum+EHmRS2vh0WHr6T9GF/Cx811nOIjru1x16lSk+q9tMjAnxXr3mXJ
fuQ7pBXgbs3kFHW7KV4W63t57cDxXqtz79/T/IewlvZApSGKNOxnlru9cz+vxMv8
r7yuPYBtHdDQVWXdDogVwvD0RUpUOCvYc/ZJjQrjeBLHTq2UU7py5IZbfaaH74/z
LhV4jLl7cCdyD83mCtGnjUApaeEDrJWJ8yE0XXvf7lhqqD77QHsbKu4FzqmWG4yO
o2nmmDrcA7MKcaJ9obQl7x1hqIzLvBRUfADuVY8BvvINlxlB7vsSFmWvOHuQRiRw
5iStm0rqSj+knpKoY5vR3gyRWxkSuYHb59LQrG1ElWlfxHpiqj8gaIeE+uKmYAnn
87uOXp9GgT6Gozdw4hQDWRxuwXhdZKZMvvQTS13NE9rSxYmfKAGV1KS9mtmaDlpo
ld4wW1SjiY9c5+f4vrtm
=LSip
-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/19ad4407-2512-e0ef-bfcc-afe8f5243361%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: disk passphrase failing with error message "luks_open failed for /dev/sda2 with errno -1"

[Swâmi Petaramesh]

Le 17/12/2016 à 13:07, Andrew David Wong a écrit :
> 
>> # cryptsetup luksOpen /dev/sda2 open_sda2
> 
>> ...If your passphrase works that's good. if it doesn't, that's
>> probably dead.
> 
> 
> Yes, this is the third thing I was asking about. However, it's not
> necessary to use a live OS to do this. (You can if you want, of
> course.) As I mentioned above, the Qubes installer will work fine for
> this purpose if you switch over to a virtual console (e.g., ctrl + alt
> + F2). (Of course, you don't want to actually try to run the installer
> in this situation!)

My point was that some distros have live version (or even ISOs that are
especially meant to be used as a live tool such as Partition Magic),
that will be much more comfortable using in a clean GUI, than an ISO
which is meant as a bare installer - And you'll be less prone to
starting it by mistake if the installer isn't there ;-)

Kind regards.

ॐ

-- 
Swâmi Petaramesh  PGP 9076E32E

-- 
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/14fb729c-93aa-48b6-4ae3-8f643bc1fa1d%40petaramesh.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] Re: disk passphrase failing with error message "luks_open failed for /dev/sda2 with errno -1"

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-12-17 03:49, Swâmi Petaramesh wrote:
> Le 17/12/2016 à 12:22, Hello Mister a écrit :
>>> When you attempt to boot this installation normally, what
>>> happens? The same LUKS error as above?
>> 
>> == >> Same error after a long wait both in GUI & CLI
> 
> I'm afraid that you may have, by starting a reinstallation over a 
> previous installation, already somewhat destroyed or reformatted
> your LUKS partition, thus irremediably destroying all of its
> contents.
> 
> I would advise you to boot from a live distro such as Partition
> Magic (Or an Ubuntu or Mint live CD), and WITHOUT starting any
> installer, try to manually
> 
> # cryptsetup luksOpen /dev/sda2 open_sda2
> 
> ...If your passphrase works that's good. if it doesn't, that's
> probably dead.
> 

Yes, this is the third thing I was asking about. However, it's not
necessary to use a live OS to do this. (You can if you want, of
course.) As I mentioned above, the Qubes installer will work fine for
this purpose if you switch over to a virtual console (e.g., ctrl + alt
+ F2). (Of course, you don't want to actually try to run the installer
in this situation!)

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

iQIcBAEBCgAGBQJYVSqWAAoJENtN07w5UDAwVaUP/2Zae8Kfqn2M2Dvu4GQ6002d
95dMf1Cxi4apEcTqA14n5jgnE2c5ekSelX9pMUjeTX/QmrB2voyB9k5Zh3jkvlQZ
R0I6+E4Iz0MuFKM3ZTBc0wtMtdHn44nvFH9HSERB22uYKp3ycW1ZvRatnKbpX1tu
GRdyQ8OyYBX79rq+B/1KhUa/5aLHCuPrF49GeQikEulkmqG5XKeKXdcF+lpwKLeJ
5inFo1CpPqkl6DYCElKxJbZk8mKjLPKCkbAw+7HlMba7x0xGbxIieMXLqzAz35WO
x8oRPiB3gx+9Pi2uuoPudwptq0933pSJbxP++Yb04F/6dndctJNohIqlZadY4DK3
M1d0ct9i1XHL1NSGRlI084Vl7a7YBvpZsRewS5tXX6GoNcSwhpuC1E4zhPv2vHHL
fFxmJDF5mdF7csOkUV+iVffJx7t/BfNVlLgBNtRQmp+WbEkYX6kGNb7/6A1Dgi5w
8Q7Q338IVJ1xc4RHCwK87tEc3A6lGfyuAjgBnxg1+brtoGxwAIGVgR9L/KeouMZ1
McE/G84NQMFQBdazecVwoCCFH329oOdjIZL/VpI220waxFrSTC3MbbvZrBBStFIg
Yt9+Z/I3ygf7Nf8B39qL4lGEjVpdhrQECfH1JdcY345cRTeTPR93ENAuYayIJFv6
Ei4CaqABGXecJzXvxPTR
=FPFj
-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/de5aa64b-d851-d54b-3416-ebab27bc4ff1%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes Windows 7 HVM & Windows update

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-12-17 03:44, Swâmi Petaramesh wrote:
> Hi there,
> 
> I have attempted several installations of Windows-7 in a HVM (32 or
> 64 bits, with or without Qubes Windows tools for the 64-bit
> version...) and it "basically works", which means that Windows
> starts, I can use the explorer, I have Internet access, etc.
> 
> BUT, on *ALL* installations I attempted, Windows cannot use
> "Windows Update" : When starting Windows update, the Win7 VM will
> stay at the "Checking for updates" phase forever, without any
> visible progress, until the VM eventually crashes.
> 
> Is there something that I missed, does anybody have a clue ?
> 
> TIA, kind regards.
> 
> ॐ
> 

This is a longstanding Windows problem:

https://superuser.com/questions/951960/windows-7-sp1-windows-update-stuck-checking-for-updates

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

iQIcBAEBCgAGBQJYVSl+AAoJENtN07w5UDAwM2kP/2lj+lhFCcQq187vNzwihndi
NDjqlRKzrLvhz5dRmpkbyPcJIR4xg/5IUQ7113VwTRw6v6K0u6w5EQHmMj/a0eZb
56afYFWHg/ie621ZaFYIzOufMDvSWsneyi4yjWCF5/mlPbVDxJkWVDYqQyG7OLvR
eUNiw4Yo3HcCiB5MAqiheFaZSEUmrQMiLAEr3xjwOrkN1e8RCOmY/vhnV3mu11rF
qrR1OHbelGpRoW7V/KQ85v4N29idSJEuvjiz6ZNi02IpBt8EFs1jAEhvgdfq9SMx
4LD+aX1nvb6xTLqBrjNGfNHMsqKumpOXwFJxSPnh/eooO+xf8wJVTTQArkIk29M7
5hcLxmSKEb39ajNBCNS0EAr4i0RkvHvapOtqCRVxRDLftMUbwnqPPWZCTlLgasl7
5tb1qKBwoJTOJJissStAePsmk0DJ5YZNco2SXzjBQYucoHrWpJDJsw1VDbYraQGR
rIgxtvql2dB5Vep7THpiuI6ffWkMXe5nWCmXGCcGH10fqVNtkOyGa57fS2LEcW3R
l38VtH51BVn5m/XQ29mbb7v7LzKcG//Y8NFqqXo8cHl0s9bkyHj7GuIK5U2OHIaq
nka/y2/xPdIdse1hhFB7OwJnfrgKiujmGyXoN0WqV1WE9cLfV+GdAnKaAzALfDjC
3cFeug5drqsW9FEKWj6Y
=kVJG
-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/02a7339c-aa48-3682-fcac-87736204a3b9%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: disk passphrase failing with error message "luks_open failed for /dev/sda2 with errno -1"

[Swâmi Petaramesh]

Le 17/12/2016 à 12:22, Hello Mister a écrit :
>> When you attempt to boot this installation normally, what happens? The
>> same LUKS error as above?
> 
> == >> Same error after a long wait both in GUI & CLI

I'm afraid that you may have, by starting a reinstallation over a
previous installation, already somewhat destroyed or reformatted your
LUKS partition, thus irremediably destroying all of its contents.

I would advise you to boot from a live distro such as Partition Magic
(Or an Ubuntu or Mint live CD), and WITHOUT starting any installer, try
to manually

# cryptsetup luksOpen /dev/sda2 open_sda2

...If your passphrase works that's good. if it doesn't, that's probably
dead.

Good luck !

ॐ

-- 
Swâmi Petaramesh  PGP 9076E32E

-- 
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/d0a67e76-5eab-3663-4c57-680296fba130%40petaramesh.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Change screen dimension in qubes

[Unman]

On Sat, Dec 17, 2016 at 11:05:54AM -, pl1...@sigaint.org wrote:
> > Hi
> > Is there a guide to change screen resolution in qubes? I mean that
> > "fingerprint" the sites track and can see on whoer.net
> >
> > Thank you in advance
> >
> 
> Nobody know how do it?
> 
Use xrandr in dom0, or the Display tool from System Settings under the
Xfce menu.
Either will let you change resolution.
qubes started after a change will show the new resolution, so you can
run different qubes reporting different screen sizesat the same time if
you wish.

unman

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

[qubes-users] Qubes Windows 7 HVM & Windows update

[Swâmi Petaramesh]

Hi there,

I have attempted several installations of Windows-7 in a HVM (32 or 64
bits, with or without Qubes Windows tools for the 64-bit version...) and
it "basically works", which means that Windows starts, I can use the
explorer, I have Internet access, etc.

BUT, on *ALL* installations I attempted, Windows cannot use "Windows
Update" : When starting Windows update, the Win7 VM will stay at the
"Checking for updates" phase forever, without any visible progress,
until the VM eventually crashes.

Is there something that I missed, does anybody have a clue ?

TIA, kind regards.

ॐ

-- 
Swâmi Petaramesh  PGP 9076E32E

-- 
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/56dceae1-afca-5518-c8af-47197600529f%40petaramesh.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: disk passphrase failing with error message "luks_open failed for /dev/sda2 with errno -1"

[Hello Mister]

On Friday, December 16, 2016 at 5:48:44 PM UTC+5:30, Hello Mister wrote:
> disk passphrase is not bieng accepted and throwing this error  
> 
> luks_open failed for /dev/sda2 with errno -1
> 
> How do I reset my passphrase for disk.

So, if I understand correctly, your goal is to decrypt your previous
LUKS-encrypted Qubes installation so that you can recover files from
it, right?

== >> Yes please

When you attempt to boot this installation normally, what happens? The
same LUKS error as above?

== >> Same error after a long wait both in GUI & CLI

Have you tried accessing the disk from the command-line, e.g., using a
Live OS? (You can also just use the Qubes installer for this.) Or is
that what you were trying to do when you encountered the LUKS error
above?

== >> Yes please , with installation source media 

-- 
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/b51078f4-82e2-4b4f-94b2-ef84580fe677%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Change screen dimension in qubes

[pl11ty]

> Hi
> Is there a guide to change screen resolution in qubes? I mean that
> "fingerprint" the sites track and can see on whoer.net
>
> Thank you in advance
>

Nobody know how do it?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/53c9cd976c1c5a75696f370305df6546.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Networking & firewall

[Marc de Bruin]

Hi Jos,

> 
> Can anyone point out some more reading material? If any?
> 
> Cheers!
> Jos
> 

I would like to know this as well! 

Anybody that would like to join and share? 

Thnx,

Greetz,
Marc.

-- 
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/E64DF7C6-F41B-4A69-AA21-12E244B3BE77%40gmail.com.
For more options, visit https://groups.google.com/d/optout.