Re: [qubes-users] Updates Proxy a security Risk?

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-08-12 15:31, johnyju...@sigaint.org wrote:
> Greetings, Qubers.
> 
> Say you have a VM (e.g. "Banking only"), which has a NetVM of sys-firewall,
> but for which you have disallowed or greatly restricted networking, turned
> off DNS and ICMP, but left on "allow connection to updates proxy."
> 

That box should be unchecked by default in AppVMs and checked by default in
TemplateVMs.

> As I understand it, this creates rules in sys-firewall to enforce that 
> policy, and allow forwards to the tinyproxy living in sys-net on port 
> 8082.
> 
> -A FORWARD -s 10.137.2.25/32 -d 10.137.255.254/32 -p tcp -m tcp --dport 
> 8082 -j ACCEPT -A FORWARD -s 10.137.2.25/32 -j REJECT --reject-with
> icmp-host-prohibited
> 
> Good 'nuff.
> 
> However, there is nothing stopping such an AppVM (say, for example, it were
> compromised) to making any connections it wants through that 
> 10.137.255.254:8082 proxy, to call home, download malware, whatever.  (So 
> my otherwise properly-configured "Banking Only" vm, that is configured to 
> only allow connectons to my bank, can actually contact that hacker site in 
> russia if some bad javascript or other compromise happened.)
> 
> I set such a VM, networking disabled or restricted to one or two sites, no 
> ICMP, no DNS, but updates allowed, and pointed Iceweasel's proxy to 
> 10.137.255.254:8082 and was able to browse to my heart's content, even 
> totally bypassing sys-firewall, so it was potentially even *more* open than
> if "allow network access except" were checked.
> 
> This seems like a bit of a potential security risk.
> 

Indeed, this is why the box is unchecked in AppVMs by default. :)

> In general, I would recommend that updates *only* be allowed for Template 
> VM's.

I don't think this would be a good idea. There are many times when it's
important to be able to update or install a package in an AppVM even though it
won't persist after restarting that AppVM (to check compatibility, for
temporary use, etc.).

> And even then a compromised template can call home freely during the
> (hopefully brief) time it's running.

Well, yes, but if a TemplateVM is compromised, then it can potentially phone
home even if you remove its NetVM, due to the existence of cooperative covert
 channels.

> (Also, I would generally recommend turning off all other Networking for a
> Template, unless you do need some non-update network configuration for an
> app, such as adding a browser plugin; but that should generally be rare.)
> 

Indeed, this is why the default setting in TemplateVMs is to allow access only
to the updates proxy.

> (Also, Temporary OS updates are indeed handy in the AppVM's for testing or 
> one-off app runs, but leaving this checkbox on is just like turning 
> networking full-on for the AppVM.  The user should at least be aware of 
> this fact.  I wasn't.)
> 
> At the very least, the GUI should educate the user about this fact, and 
> maybe pop up a warning/confirmation page if the user tries to enable update
> access for an AppVM.
> 

In principle, I think this is a good idea. In practice, however, there are
already so many more accessible ways for users to shoot themselves in the
feet, e.g., running programs in dom0 or TemplateVMs (except for intentional
initial configuration). Ideally, we'd have such warnings in *all* of those
cases. While this would qualify as one of those cases, it seems a bit less
dire and bit less likely to affect huge swaths of new users (especially given
the defaults). If that's right, then it might be better to prioritize our
warning implementation efforts on the most blatant and serious pitfalls first.

> While it's easy to work around by leaving that option off except on 
> Templates, it's a simple way for new users to unwittingly leave an AppVM 
> wide open.  I'm thinking the update server access process might need to be 
> re-considered a bit.
> 
> I also think more visibility of the overall firewall setup/layout and 
> potential packet paths (as well as actual traffic) needs to be done 
> somehow.  Perhaps sys-firewall needs something more akin to Shorewall. 
> (Checking for leaks, and running iptraf in sys-net was rather depressing; 
> more on that in another post.)
> 

I think that might fall under this:

https://github.com/QubesOS/qubes-issues/issues/2135

(I've added a link to this thread in my comment on that issue.)

> Thoughts?
> 
> (I worry a bit that the attitude of the Qubes developers is "oh well, if 
> you're compromised, you're screwed anyway, no sense adding more security." 
> See no-password sudo, for example.

I think the idea is more like: "Let's not bullshit our users. If some
purported security measure doesn't actually add any real security, then we're
not going to implement (or preserve) it and point to it as evidence of defense
in depth (because it's really not). By contrast, we welcome defense in depth
that actually works."

> I disagree with that approach, and th

Re: [qubes-users] USB Root Drive Corruption

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-08-12 15:31, johnyju...@sigaint.org wrote:
> I realize USB drives (or USB *anything*) is a stupid, stupid idea when it 
> comes to being security conscious, but while trying out Qubes, I do have my
> root drive on an external USB HD.
> 
> (And there's something to be said for taking your drive with you.)
> 
> It works great in general, is fast enough, and seems very reliable.
> 
> Until shutdown time.
> 
> Things seem to shut down okay, but on the following boot, I see complaints 
> about the disk errors on the journal; it does a FSCK but fails and goes 
> into Read-Only mode, which prevents proper system startup, so most of the 
> system just sits there doing nothing, presumably waiting for the root drive
> to go rw, which it never does.
> 
> Doing an fsck from a console terminal on the ro partition notes the journal
> repair required, does its work, and says everything is ducky.
> 
> Then I reboot, and get the same problem.
> 
> If I reboot into Tails, do the cryptsetup, lvmchange, fsck to tidy up the 
> drive, and *then* reboot, the system will start up okay.
> 
> So every time I reboot the system, I need to first boot into Tails to 
> repair the drive, to get back into Qubes.  More than a minor inconvenience,
> and booting other OS's always adds to the risk of compromise.
> 
> I'll try moving the drive onto the SATA bus and see if the problem goes 
> away, just to verify that it's a USB-only thing.
> 
> It's also a bit weird that it gives a disk error (IO Buffer error I think).
> I've badblocks scanned the drive repeatedly, and its healthy and fine, not
> a bad sector to be found.  But something in the Qubes shutdown/startup is
> making Qubes think there's some bad sectors (maybe a problem the luks or
> lvm level?  The ext4/lvm/luks/usb layering might not be shutting down
> elegantly.)
> 
> (At boot, things fly by pretty quickly, and where the system crashes, I 
> don't have the logs stored in a file, but it almost appears to me that more
> than one fack gets run [perhaps stepping on each other].  That's just a
> hunch though, I'll try to narrow it down more.  The fact the journal needs
> recovering at all after a normal shutdown still remains a problem.)
> 
> System is an AMD64 with 4G memory, JMicron SATA->USB Controller on a 2.5" 
> 500G Samsung drive.
> 
> JJ
> 

Thanks for the report. Tracking here:

https://github.com/QubesOS/qubes-issues/issues/2245

Please let us know how it goes when you try moving the drive onto the SATA bus.

By the way, have you tested this on any other hardware (e.g., different
SATA->USB controller)?

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

iQIcBAEBCgAGBQJXrsp5AAoJENtN07w5UDAw9nIQAKmmvfzSRoZyprxr29UM4kCh
QVfPKUoOVo6aXE3YJVDJebhQQmvbKlzlTcGaYTWZYIdwg9I/Ugpo/DtutlwptMfP
xRZ4wUDMkGMA3/Z8iE1R7+sdCCx7R3QPktmZAcUJwnOlQ2HcYkX83xgbnWPChL0/
22uiaM3XXJdPs0AQvnLPHU7eeIajJo7a7Yqiqiid/SAcUYzKenDpqcdwTv29VIi8
mhwo2hntEqV2aYCBsVgMGL8jNh++Kq2c2+TgU1ZYXNLwwWDLQfr6Jy9kMaVBh+uQ
Z5dFtbaxnOZNsX+fxbY6N/LBkXrNYR67vK28wNY6oPeQrCBgHy1/bQ9WMlnsgL++
/pFQwhAKCheq8NpVVzTyWU3XlHPx5th3z9CMkX1YMUbIU0D28dcUOXf0Rx5ZTAdX
znc/7cdgfkKUwONm90Pip2bAV0uC3qAlJUIn4S7CITsJiyl0zjlLl7bMECG74Z1i
27WnPMS0iwoD646iACYSJ21YDusfolQmIAI/RsvVVDK7qEdCgNsdLRFeFABN95jO
37Gpwd+OrQmx+Y27se7dSsODpXWj6/9gbgZSS1cpH4G1+hV8LEJdM2eV0mhNsIcx
ALQmG3NpmDpxOBkRhhe6paFiEeiOAcLLcoO39ehPNGhE3ahp5dQUZ5cvUCy1Lw8F
kiuWm6Os+3j/BOvK4Nwo
=XDnZ
-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/3effc0e9-4513-cce2-e6fb-0a175bd58aec%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Unable to install R3.1 / media check failure

[Gabriele Bini]

I used dd: my current system is a Linux Mint 17.


On Sat, Aug 13, 2016 at 8:47 AM, Andrew David Wong  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2016-08-12 11:24, Gabriele Bini wrote:
> > Hello, I have exactly the same problem. This is what I did: 1. I
> downloaded
> > the Qubes-R3.1-x86_64.iso ISO from the Torrent. 2. I checked the
> signature
> > and the hash values in the DIGEST file (I checked just the hash values
> in a
> > second PC) and everything was fine. 3. I used dd to copy the ISO in a USB
> > flash drive (Sony 8Gb) 4. When I booted from the USB I tried the “Verify
> > and Install” option but, exactly at 4,8% (as for Cory Nelson) the check
> > failed. There was a message of this type (copied by hand): Failed to
> start
> > media check on /dev/sdc See 'systemctl status checkisomd5@
> -dev-sdc.service'
> > and 'journal.ctl-xn'  for details 5. I couldn't check anything because
> the
> > system was halted
> >
> > What can I do? Thank you in advance!
> >
>
> Did you use Rufus or Unix dd?
>
> - --
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> -BEGIN PGP SIGNATURE-
>
> iQIbBAEBCgAGBQJXrsJsAAoJENtN07w5UDAwvrsP+OhECR1mnbk5xO+b35beNxJV
> RpuPrSYZ3PSEjwPgvIVJCee6s2MwzUTjQnjVuGx8yLsPC7VdnAwcUceNyySAL9ST
> HXyJZErgEXkFnR9QK5VNl0RFqHPuiUmTmOPkfpZm7rgE1xVDFQk5E3ZCI60493i6
> 8yL3xz2eqhG4UfuvN665LDEwqvg7KSRUzbq0fQlrqLVLN8qucUKAijTTa31ea6Rk
> 8ea+KncQtN8RL6jMFG6guN+lpQnx2klHyU//bbNrjUnFQ/XzPV0N8C6HZbWpAItP
> RYdCZABDzrtYBgPGg/K0cxWfX4gvOPVA027fb8jJT7WgRVNaqwA0mdq3Vdzk3Xek
> 0SPMAfGlWGamrlpGqFrx1R7v+qHlYTfedrREgwp8pzP1Ey47Pt/XRt3PZScIwd1t
> G+vj83+X8Ochk8KDfVY5JrIo4vcK208xOXfkkRcCuZrR8PlGECdLjJFqPqXPr3mr
> DghrWdO0kTEKYI6slkt6EosG4OeCCKAj3+EbFOz1hPdohZZpGts4nuEpOqquhiIC
> YmbYhwT/JjefB4/EugdYH0pTBIqkgWXNKs+SMJ/s7Md8vFqhIdZJrh4Gp83DY1nv
> XKAiWOyBAv6O+Y2oYtzco9IpzB+3Ua+06/gx/UkDdamfZkt2nfJVcOwt1/2mPLKJ
> s7B1nmIeoCvuab4sHcU=
> =jY+z
> -END PGP SIGNATURE-
>
>


-- 

Asperges me hysopo et mundabor

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

Re: [qubes-users] Qubes 3.1 - Fedora update check disabled but still check

[johnroberts19855]

On Saturday, August 13, 2016 at 8:45:42 AM UTC+2, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2016-08-12 11:19, johnroberts19...@gmail.com wrote:
> > Hello
> > 
> > i disable all the option auto update options but qubes still pop the
> > update icon in my qubes vm manager.
> > 
> > qubes vm manager "System - Global Settings" Disable dom0 and VM updates
> 
> What is the output of "qubes-set-updates status" (in dom0)?
> 

dom0 = disabled
vms = enabled


> Also, check the "Services" tab of the affected TemplateVMs. There should a
> service called "qubes-update-check", and its box should *not* have a check 
> mark.

there was no "qubes-update-check" i add it and uncheck it.

now "qubes-set-updates status" message me:

dom0 = disabled
vms = mixed

it seems to be working.thank you. but why i have to do it manualy?


the same is for whonix... it says there are updates even if sys-whonix isn't 
running and don't connected to tor...


> 
> > Fedorar 23 Template VM disable firewall rule "Allow connections to Updates 
> > Proxy"
> > 
> 
> This setting doesn't affect update checks. The update checks are done by
> AppVMs based on the TemplateVMs. The updates proxy setting just controls
> whether the TemplateVM itself is able to communicate with remote repos when
> you actually try to update it.
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> -BEGIN PGP SIGNATURE-
> 
> iQIcBAEBCgAGBQJXrsILAAoJENtN07w5UDAwUBkP/0X9bqL1W7vhKbXSt5KCnoPr
> KRMJLrJeammSyWpDRy3hdbVTfGv7pEnaAe90Ta89R4u7EH8Af7QdbyrqZY4i7yur
> BYKTmRF2owkindF8ivhB5yPwDENhZvVkUkYz6FOo4fJqqyI3ct5/Xhog4INSXA/t
> NFQPpR4MMwdIyeUQ7ZaijGHaBaBx3gvVjZpVvBCxNpJTa/QuFtB5cKM1/GILoLGB
> 4NmUsBQ0RI+R1cRdrVj7Tdupot5to2F6VnLPhdzMXD4LgOQV7BwsEOLkvqbyWNai
> mlJpv88egxRpuA8H8lbaoWgopjL2mnSJXIkM6xMNHhXuZN+EVl6Z6LY2brU3oc1H
> Idjrw/0LubKXA8+QqSaZ+7ja4D8SoFCKRfoJmwf38ki6c9vXWrRmCs+F7DL1DXVD
> qcA7zchO6FjsHVCxXxW0KRdRNZxgCV4SDRRxFl5OFogu4aovurcFSrdy60IQ4zbN
> DpWji4g19sFg4ZF3cRW7sYSJX1gst8ggMzkb5/olHC/cYkSGxQ4j/b/tlt6Qyyl3
> xwwLzbVoLV7WTzZorDUz4n2FhxUWsqzVmEXwrkqQcaA+S+oTFt7X3WizD3mHm14k
> 1MBJfZJfRl8/ycGkOT7VE3+2lSmwILPmc4FYxcW9aCxmu0TCG4RqzkakjhoUUL/S
> AUSmk7pbJ6oG6nODAjUl
> =JVi6
> -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/e3bbc3a0-fedd-49c2-b16a-b1d9003e3f73%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: AppVMs using ProxyVM having DNS problems some days

[Markus Kilås]

On 08/03/2016 03:22 PM, Markus Kilås wrote:
> On 08/03/2016 09:31 AM, Marek Marczykowski-Górecki wrote:
>> On Mon, Aug 01, 2016 at 08:31:12AM +0200, David Hobach wrote:
>>
>>
>>> On 07/31/2016 10:05 AM, Markus Kilås wrote:
 On 02/28/2016 04:13 PM, Markus Kilås wrote:
> Hi,
>
> I am experiencing an issue with DNS queries in my AppVMs in R3.0.
>
> Sometimes after booting up, the AppVMS that are connected to
> sys-firewall are unable to do DNS lookups:
> user@untrusted ~]$ dig qubes-os.org
> ; <<>> DiG 9.10.3-P3-RedHat-9.10.3-10.P3.fc23 <<>> qubes-os.org
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
>
> The same command works in sys-firewall and netvm and any AppVM connected
> directly to the netvm but not when going through sys-firewall. There are
> no firewall rules added in the Qubes VM Manager and changing to allow
> all network traffic for 5 minutes makes no difference.
>
> Besides DNS lookups not working, the networking is working:
> [user@untrusted ~]$ ping 104.25.119.5
> PING 104.25.119.5 (104.25.119.5) 56(84) bytes of data.
> 64 bytes from 104.25.119.5: icmp_seq=1 ttl=56 time=31.4 ms
>
> If I manually change the nameserver to the same as in sys-firewall the
> resolving works also in the AppVM:
>
> With IP from /etc/resolve.conf (sys-firewall):
> [user@untrusted ~]$ dig @10.137.2.1 qubes-os.org
> ; <<>> DiG 9.10.3-P3-RedHat-9.10.3-10.P3.fc23 <<>> @10.137.2.1 
> qubes-os.org
> ; (1 server found)
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
>
> Instead with the netvm IP:
> [user@untrusted ~]$ dig @10.137.5.1 qubes-os.org
> ; <<>> DiG 9.10.3-P3-RedHat-9.10.3-10.P3.fc23 <<>> @10.137.5.1 
> qubes-os.org
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5804
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;qubes-os.org.IN  A
>
> ;; ANSWER SECTION:
> qubes-os.org. 127 IN  A   104.25.119.5
> qubes-os.org. 127 IN  A   104.25.118.5
>
> ;; Query time: 11 msec
> ;; SERVER: 10.137.5.1#53(10.137.5.1)
> ;; WHEN: Sun Feb 28 16:03:09 CET 2016
> ;; MSG SIZE  rcvd: 73
>
>
> Any idea what is going on here?
>
>>
>>> Very similar issues here...
>>
>> I think it's this issue:
>> https://github.com/QubesOS/qubes-issues/issues/1067
>>
 I think I solved this now.

 After re-installing with V3.2-rc2 and restoring my VMs (including my old
 netvm) I still had this problem from time to time.

 So what I did was to start use the new sys-net VM as NetVM instead of my
 restored old netvm (I manually copied over the network manager config,
 private keys, certificates etc from the old VM to not have to
 reconfigure that).

 Since then, so far I have not seen the issue again.
>>
>>> I had renamed the sys-firewall VM back to its old "firewallvm" name using
>>> Qubes manager after a fresh 3.1rc2 install (otherwise restoring my backup
>>> wouldn't have worked: "could not find referenced firewallvm" ...). 
>>
>> Enable option "ignore missing" during backup restoration. This will use
>> default VMs in place of missing ones (default netvm, default template
>> etc).
>>
>>> Maybe the
>>> sys-firewall name is hardcoded somewhere? I guess I'll test renaming it back
>>> again soon...
>>
>> It shouldn't matter.
>>
>>
> 
> My guess was not that the issue was with the name but rather that my
> restored netvm had some configuration (or similar) issue preventing the
> resolving from working in some situations.
> 
> I have no idea if that makes sense or not, it was just a hypothesis of mine.
> 
> But the fact for me is that since I switched to use the stock sys-net VM
> I haven't had the problem a single time yet.
> 
> 
> Cheers,
> Markus
> 

Unfortunately, I was wrong.

After working perfectly for a few weeks now I have seen the issue again :(

- working networking in sys-net
- working networking in sys-firewall using sys-net
- ping/dig etc not working in AppVM when using sys-firewall
- working networking in AppVM when connecting directly to sys-net

Currently the only workaround I know of is to connect directly to
sys-net or reboot and hope for better luck...

Cheers,
Markus

-- 
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/897e

Re: [qubes-users] grub2-mkconfig not found

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-08-12 20:57, zackp...@gmail.com wrote:
> Hi all, I'm a new qubes user and have been following the guides to get
> trim enabled for the dom0. Everything seems to have gone smoothly until the
> grub steps. I can't find a grub.cfg file anywhere. The only abnormality to
> my installation is that it's UEFI. So the closest thing I did find to this
> was /boot/efi/EFI/qubes/xen.cfg which had the kernel line referenced in the
> trim guide. However, when I attempt to run grub2-mkconfig -o 
> /boot/efi/EFI/qubes/xen.cfg I get "grub2-mkconfig: command not found" All 
> that is present in the /boot/grub2 folder is a themes folder. I am using
> the main dom0 terminal for all of this.
> 
> Considering that everything boots fine, I'm hesitant to reinstall grub2 (I 
> assume it would need to be grub2-efi in this case). Any clue as to what's 
> going on? Thanks
> 

I think grub2-mkconfig is not found because you're using UEFI rather than
legacy boot. Are you getting your instructions from here?

https://www.qubes-os.org/doc/disk-trim/

I think these instructions were written with legacy boot in mind. I'm not sure
how to enable TRIM on UEFI (CCing Marek).

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

iQIcBAEBCgAGBQJXrvJsAAoJENtN07w5UDAwnc8P/35kWSsRqTEPB4cA/F2dbTg/
m4eieEBI+qyo3mgMNSb/m2/WviqGtNWyOf5KT8ecHHoi6yeXVgv/eam2YgaCMYC0
K4RRTOOWPuguZlDDuZDI4OABeWEsQsekl7Mm6aQoA55SgekmyYv1B4iYaQ6RFUS1
b4TAmDteKea9l6thaxrJimv13l/LAUpsRxKiH/vksdpjPx3QSEQVozs6XNrEbbPo
ROXTF/kzbXP1b8GPCIcZLuD+wsomFVM0NyVwXRGDvL3wTIMTxL5qYprLu/Xnzr6m
53Yb+J6alV4gmXoRUWoHm2UzlB2LxffJlkVWbTzi4xaluIC6oAQ5YNvMg0etIHY1
7bfP8eEvr/3/iPI4ut15drUJNCjCaQG/fJy4hjOZOIqihxoGRTGceA5SCpkITpbt
uua7sO2Ya4rTG3fT8NudM7TFFsnUHuQ8VrKZTLZRhWG+BbRHlb2EumDFWv9qSNgd
qQ7vhXa+upy8/ccGMbIq07q/NbjB7MXm1h9ntch6RMPMtTUZXGlpip+urkVNzx1c
WIB4aLBleIytrbZofZspc51q4oIeEqVv5ge9D4oEKMj0BE1sTmOweYviH7GeC6w3
057VRyrtZmf0Zhx2XmJVtRtPgWbT2jZvHeEMlPR0KY04xIYPmoXmuuT0lufOtGQ4
Bt4EvyaJziT7Iy0+Fwxq
=g2ha
-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/0d841420-7ea0-7276-8c8c-451fb04cfdf9%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] grub2-mkconfig not found

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Aug 13, 2016 at 03:11:57AM -0700, Andrew David Wong wrote:
> On 2016-08-12 20:57, zackp...@gmail.com wrote:
> > Hi all, I'm a new qubes user and have been following the guides to get
> > trim enabled for the dom0. Everything seems to have gone smoothly until the
> > grub steps. I can't find a grub.cfg file anywhere. The only abnormality to
> > my installation is that it's UEFI. So the closest thing I did find to this
> > was /boot/efi/EFI/qubes/xen.cfg which had the kernel line referenced in the
> > trim guide. However, when I attempt to run grub2-mkconfig -o 
> > /boot/efi/EFI/qubes/xen.cfg I get "grub2-mkconfig: command not found" All 
> > that is present in the /boot/grub2 folder is a themes folder. I am using
> > the main dom0 terminal for all of this.
> > 
> > Considering that everything boots fine, I'm hesitant to reinstall grub2 (I 
> > assume it would need to be grub2-efi in this case). Any clue as to what's 
> > going on? Thanks
> > 
> 
> I think grub2-mkconfig is not found because you're using UEFI rather than
> legacy boot. Are you getting your instructions from here?
> 
> https://www.qubes-os.org/doc/disk-trim/
> 
> I think these instructions were written with legacy boot in mind. I'm not sure
> how to enable TRIM on UEFI (CCing Marek).

Yes, on UEFI install /boot/efi/EFI/qubes/xen.cfg is the right file - you
need to edit it directly.

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

iQEcBAEBCAAGBQJXrvMNAAoJENuP0xzK19csfqQH/0/P4FV8W2/pZhWaCeXfseqj
fw79GDTa5/ExjxSg4eehHDhHHVgG3kaeb0HafPvVnHS/DJuHzCG1Xrs1vyZJlPID
oCrH4FaaYQ2Che4L4D/Koh5lNEdEakKOrF7ILbTRN5u8Q4xvdM9KQ/paacCYkCDJ
YlYKELzyOZ1wkUvwttPynTANdrMlY797BHkHYHv2TbaMBTjw4EYmIs+VM9MRIWIv
Lis1hZn97y1z3ZIQglrQRCDLAmoNJPBsXRdMHjNyA5EeKQPX+fNxsE3/HIoqrIi3
3DHYzKIS/UBDFHOJXj7I3pK311fS1IcUlrbRCXJYCM0gF5A5EkWKxIj0ghV0YTI=
=uhvX
-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/20160813101436.GI9166%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Unable to install R3.1 / media check failure

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-08-13 01:25, Gabriele Bini wrote:
> I used dd: my current system is a Linux Mint 17.
> 

Ok, then this might be a different issue. The previous one was due to Rufus
and has already been fixed (or so we thought). However, given your new
information, it's possible there's actually a common root cause. Tracking your
new issue here:

https://github.com/QubesOS/qubes-issues/issues/2246

P.S. - Please avoid top posting.

> 
> On Sat, Aug 13, 2016 at 8:47 AM, Andrew David Wong  
> wrote:
> 
> On 2016-08-12 11:24, Gabriele Bini wrote:
 Hello, I have exactly the same problem. This is what I did: 1. I
> downloaded
 the Qubes-R3.1-x86_64.iso ISO from the Torrent. 2. I checked the
> signature
 and the hash values in the DIGEST file (I checked just the hash 
 values
> in a
 second PC) and everything was fine. 3. I used dd to copy the ISO in
 a USB flash drive (Sony 8Gb) 4. When I booted from the USB I tried
 the “Verify and Install” option but, exactly at 4,8% (as for Cory
 Nelson) the check failed. There was a message of this type (copied by
 hand): Failed to
> start
 media check on /dev/sdc See 'systemctl status checkisomd5@
> -dev-sdc.service'
 and 'journal.ctl-xn'  for details 5. I couldn't check anything 
 because
> the
 system was halted
 
 What can I do? Thank you in advance!
 
> 
> Did you use Rufus or Unix dd?
> 

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

iQIcBAEBCgAGBQJXrvTEAAoJENtN07w5UDAwsjQP/3HCP2/UGL+zD+ReofLTDlh9
WNwwdochWNmVLIP02XQxM4HNj+WsR+8tzZrjkQZeTV0Z4sr+Ks+5lc/3l2RYKQhD
5wO/ja5Vfl/imizct8CPc01JTB1brHXeFlrT1MJtweXQAgHPuGapdhasFnvbPjPB
Or6EtmQ+xNnHFSe2eND6V4Eu9dmOeonjCNEoUi6sbKdNMWakL4bE/xWyaTYGRBQR
g0Va7h+MAG/EyuE0FtvHapV9yWgComIuRJNJwfBwK21NOVCv9ycxnGBXPMoyl+v0
JAv4H9sIQFtVMXk2wUB3Ww6PhoyMKX+aZWc0IuZDcNaNnyQIPwWR0iY3K2mNh4t/
cOGlWQ9/Cov0u4KmcQGupI5+HMmo/6T44SpGwx4CwQSXpKf1sRlvmANCsmBB13CO
o2pbrV+QMXryX7si3kNte6m1g6MlcI5SAmHiGl00rRp3idT/pe9Wb5QY96vEF6Xm
ZXxit9v5xk5xEc5hTttMnRi3JMNq8ZrrDBOzHi8p5ubZT840h/fPeYtBZoYOiALJ
hHXlXLAngEMcdAxxyb92APkKQVQm7vGqA6WxY31s8R2pPXy91Lfxcuigdju6L7Ce
TUkpPnBnNxeYn6A1PWz67s84vrMzF9jm8ucywY8T9pIiwve2WuQfuRFoud4Xb0i1
t1O/t7l05RFQ9sGy6Qld
=je12
-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/361d4efc-deb4-ff90-10bf-f02b1d555a7f%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] VPN with PPTP failing

[kototamo]

Hi,

I'm trying to setup a VPN connection with PPTP from sys-net (first tried with 
the ProxyVM but it also didn't work) without success.

Any help is welcome, here below the logs.
I also tried

$ sudo modprobe nf_conntrack_pptp

without success.

I'm using the fedora template.

Plugin /usr/lib64/pppd/2.4.7/nm-pptp-pppd-plugin.so loaded.
using channel 9
Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
sent [LCP ConfReq id=0x1]
sent [LCP ConfReq id=0x1]
sent [LCP ConfReq id=0x1]
sent [LCP ConfReq id=0x1]
sent [LCP ConfReq id=0x1]
sent [LCP ConfReq id=0x1]
sent [LCP ConfReq id=0x1]
sent [LCP ConfReq id=0x1]
sent [LCP ConfReq id=0x1]
sent [LCP ConfReq id=0x1]
LCP: timeout sending Config-Requests
Connection terminated.
Modem hangup
Script /sbin/pptp 91.233.116.223 --nolaunchpppd --loglevel 2 --logstring 
nm-pptp-service-5272 finished (pid 5281), status = 0x0

-- 
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/be1af660-c2b7-4b03-82c6-1ee416919a68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 3.1 - Fedora update check disabled but still check

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-08-13 01:48, johnroberts19...@gmail.com wrote:
> On Saturday, August 13, 2016 at 8:45:42 AM UTC+2, Andrew David Wong wrote: 
> On 2016-08-12 11:19, johnroberts19...@gmail.com wrote:
 Hello
 
 i disable all the option auto update options but qubes still pop the 
 update icon in my qubes vm manager.
 
 qubes vm manager "System - Global Settings" Disable dom0 and VM
 updates
> 
> What is the output of "qubes-set-updates status" (in dom0)?
> 
> 
>> dom0 = disabled vms = enabled
> 
> 
> Also, check the "Services" tab of the affected TemplateVMs. There should a 
> service called "qubes-update-check", and its box should *not* have a check
> mark.
> 
>> there was no "qubes-update-check" i add it and uncheck it.
> 
>> now "qubes-set-updates status" message me:
> 
>> dom0 = disabled vms = mixed
> 
>> it seems to be working.thank you. but why i have to do it manualy?
> 

I'm not sure why the manual change is required. It is conceivable that there
has been a regression of #892 (CC Marek):

https://github.com/QubesOS/qubes-issues/issues/892

In any case, please note that "mixed" means that some TemplateVMs have update
checks enabled, while others do not. If you don't want *any* update checks,
you need make sure that both are set to "disabled".

In order to do this, you can try issuing "qubes-update-check disable" (from
dom0), then check the status again. If that still doesn't work, then make sure
to manually add the "qubes-update-check" service and uncheck the box in every
TemplateVM (assuming, again, that you don't want any TemplateVMs to have
automatic update checking).

> 
>> the same is for whonix... it says there are updates even if sys-whonix
>> isn't running and don't connected to tor...
> 

I imagine this is because the whonix-gw template still has update checking
enabled (see above). Try disabling it (as instructed above) and see if the
problem persists.

> 
> 
 Fedorar 23 Template VM disable firewall rule "Allow connections to
 Updates Proxy"
 
> 
> This setting doesn't affect update checks. The update checks are done by 
> AppVMs based on the TemplateVMs. The updates proxy setting just controls 
> whether the TemplateVM itself is able to communicate with remote repos
> when you actually try to update it.
> 

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

iQIcBAEBCgAGBQJXrvZdAAoJENtN07w5UDAwEzoP/i5uTTJBS1arS0YaVNJH8Xz4
ZckNC9o+Z90IVjByP07R2vqJACRQK0KfxgpYpZPApAhVDEzKoqlfYvALNLKC/wsF
O5z2kYYsDya5jqd6ba6O62dnl3t91GLHlmuYQnYYvj+GIaaTqcTJFL/ONvIutUB0
iC0/MhjbLLcqZwByn45Qrfjj0UT/KQ1P8iblW+WyaqDQ/2FD+jIGdONCo+JMIKow
pDOm27DSuzJ73wkrG5Dk/UZTPkvjSTQ8+I4fdqTS2cEOguC6VI3Q6N+P9N+TacXE
K0PvALQ2Pplf78ay9DBTarKBHQX7XIUa0DKOWGb5JDLo7mW3eTPKe+QG7jTqs03A
iZv3f6z4hjOOVw5+tEJ3P7eKHr90gzk+CahQ3M9KqUSG3ODDQWfXCkZmBEqi1eDQ
VA/iGktHEutpkWmZU/RYmqMyppzm/xFY5j2gbd4/9bgTdm1BP7E350R1NhSiON0u
gQN6TnbIbEZsnqFBj+sncAL3HFlrifj3Qq4jls8TT20b8ToElWzbWGgjYwb09rGY
S0/Cjq6SU81KISmOIHlpfzudn7fY5McRJP7PtU39nmzSEuJbTWucxKBVYYpSD3N4
NnnmtzTxHmtoXaddSOlneUDVarItYuFAouc2VGLzJFK/spy03u8pz04HkVOBPxib
csNandHw9EJDJVcnwD0H
=pSNA
-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/be1861a9-ae82-8073-dbac-18f43bb2532e%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] VPN with PPTP failing

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-08-13 03:22, kotot...@gmail.com wrote:
> Hi,
> 
> I'm trying to setup a VPN connection with PPTP from sys-net (first tried 
> with the ProxyVM but it also didn't work) without success.
> 
> Any help is welcome, here below the logs. I also tried
> 
> $ sudo modprobe nf_conntrack_pptp
> 
> without success.
> 
> I'm using the fedora template.
> 
> [...]
> 

I'm afraid I don't have any specific help to offer, but you didn't mention
whether you've already had a look at our VPN documentation. In case you
weren't already aware of it, you mind find some useful information:

https://www.qubes-os.org/doc/vpn/

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

iQIcBAEBCgAGBQJXrveoAAoJENtN07w5UDAw95sQAMwNGL/ezWe5XfftkyjV1Ybg
pUSURqDofKjM+aPCi7FGKguJE0Melwt5d/FsgkfglQ9+20TM9nKHdCzNazO+TV/C
65cS5dwMkr0g5shjCqMRhApZ8TlLfHOsckRai+zO/me19ITw2tMfEPIVRFsaxXy9
fiiIAfDvONyXlth0c+aptHKu2HVlH/ntCALfMyHtinPMwymfhcPxuINbsGTB/DRT
fen4MhZvC7n194EJeIF29yBaxai1EuhPXFRwOWrvgi15XjWw8pzmYTd/54R4dk21
OYrG0f1SbktHnmtAM0tKxmPBlQLRkPRiD8sXwTovlvOplgOPOxg1BdDoAr/fUGZ7
UQgIfUhO6GpxVVBKXgULlFiP/LxNxoDgQWNpocoiffVjCoL+32D22AFftGyp8/5+
Bf7XF5U6A+ypZDQGAsmoUywVBSuSpMhQkCJahq2NWoh823OixGoiH8jN/I9GLMUX
R4EJOlu4TNjubBVuwVhaZmEJSwg/6xNf3sK+xRKl6URhFB3PUAAv0oq6XA/nD4xV
LLYAdgXN1R8DQ6DhmLIESQUKgaAYPg1BrBqnBDs9f9N2lyPN1lBdmoqgOSvg6R4s
uAKE05xn2Xvvu3Fcx/l/TfJ0QB3mW2KTO9T2n/VmAyiWQDy56l/VmAbFaXtEe3ZL
4tQcA2752T3O1BHu/K6J
=ccMI
-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/25527ea0-2ad7-2999-e6d3-aee72af28673%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How to remove KDE from dom0?

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, Aug 12, 2016 at 02:37:18PM -0300, Torsten Grote wrote:
> Hi all,
> 
> I installed Qubes 3.2 with KDE and XFCE with the intention of continuing
> to use KDE as I did before. However, there were so many problems and
> bugs that I decided to use XFCE in the hope of having less of those.
> Although, it is not bug free, it works a lot better, so I would like to
> remove KDE from dom0 now.
> 
> I already tried removing the @kde-desktop-qubes group, but that wants to
> remove all sorts of other rather essential packages.

Take a look at `dnf group info kde-desktop-qubes`. Also `dnf` by default
removes not only packages which require those selected to remove, but
also those no longer needed by any of remaining. So, maybe just marking
some of those packages as manually installed will be enough:

sudo dnf mark install PACKAGE_NAME

You can do the same with `qubes` group - containing Qubes core packages:

sudo dnf group mark install qubes

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

iQEcBAEBCAAGBQJXrvxpAAoJENuP0xzK19csgrwH+QGHnvcIHQr4CnHvuGBNLocC
+NKetLj2FChiC5GD+PoQ0YBH/Zz2V1UD+UHfM4+9qWSfA2w75fXk3Z0VRc6aOp7S
7C+ro7PslhLLEEh3SZoXry9ETLLpNd/yezOHWkFzSr3E4X7PVLXOrpRE0sdpb+BH
cQeqkzPVFOTbgb/wwb5SLhturNgkj8H2t8/zBi106FQlPFUFfY/UwLHogVWI9BGj
ejUu6bTXydyGC1zgLSAv0lMQPv8pryP0htB89sx0k2jkLEMY9hD9xcDphVgLbmzo
ULc9wK/+BUGx8Gsl18VnO8TpxC6fKnpgw+gg9VdYjK4Q8+FQUoWFTUcyFCRfX/0=
=AJ2A
-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/20160813105433.GJ9166%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: AppVMs using ProxyVM having DNS problems some days

[Markus Kilås]

On 08/13/2016 10:49 AM, Markus Kilås wrote:
> Currently the only workaround I know of is to connect directly to
> sys-net or reboot and hope for better luck...

Copying the values in /etc/resolv.conf from sys-firewall to the AppVM
as mentioned in the ticket also seems to work as workaround.

// Markus

-- 
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/57a7d35c-8b70-16f4-e2a9-1bb206a15762%40xn--kils-soa.se.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Manual https://www.qubes-os.org/doc/templates/archlinux/ does not work.

[lol lol]

суббота, 13 августа 2016 г., 4:04:57 UTC+3 пользователь RSS написал:
> On Fri, 12 Aug 2016 07:56:23 -0700 (PDT)
> lol lol  wrote:
> 
> > Hi guys, it doesn't work on a step 9 after compiling.
> > 
> > /home/user/qubes-src/vmm-xenPKGBUILD: line 49: autoreconf: command
> > not found ==> ERROR: A failure occurred in build().  
> > Aborting...
> > /home/user/qubes-builder/qubes-src/builder-archlinux/Makefile.archlinux:120:
> > recipe for target 'dist-package' failed make[2]:***[dist-package]
> > Error 2 Makefile.generic:139: recipe for target 'packages' failed
> > make[1]: *** [packages] Error 1
> > Makefile:208: recipe for targert 'vmm-xen-vm' failed
> > make: *** [vmm-xen-vm] Error 1 
> > 
> > --
> > 
> > So, i can't install archlinux template step by step :( Script doesn't
> > work. Please fix it.
> 
> Step 9 from where?
> 
> I also am stuck on an Arch build, I wonder if it might be the same root
> cause?
> 
> $ make get-sources
> 
> --> Downloading additional sources for vmm-xen...
> Makefile:77: recipe for target 'xen-4.6.1.tar.gz' failed
> make[1]: *** [xen-4.6.1.tar.gz] Error 4
> Makefile:188: recipe for target 'vmm-xen.get-sources-extra' failed
> make: *** [vmm-xen.get-sources-extra] Error 2
> 
> And then again:
> 
> $ make get-sources-extra 
> --> Downloading additional sources for vmm-xen...
> Wrong signature on xen-4.6.1.tar.gz.UNTRUSTED!
> Makefile:77: recipe for target 'xen-4.6.1.tar.gz' failed
> make[1]: *** [xen-4.6.1.tar.gz] Error 1
> Makefile:188: recipe for target 'vmm-xen.get-sources-extra' failed
> make: *** [vmm-xen.get-sources-extra] Error 2


Hi, again. Here is full log.   "Step 9" meaning install  'make qubes-vm' 
command :) 

[root@development qubes-builder]# make qubes-vm 
Currently installed dependencies:
git-2.5.5-1.fc23.x86_64
rpmdevtools-8.9-1.fc23.noarch
rpm-build-4.13.0-0.rc1.13.fc23.x86_64
createrepo-0.10.3-3.fc21.noarch
debootstrap-1.0.81-1.fc23.noarch
dpkg-dev-1.17.25-6.fc23.noarch
python-sh-1.11-1.fc23.noarch
dialog-1.3-4.20160424.fc23.x86_64
--> Archlinux preparing build chroot environment
--> Archlinux prepare-chroot-builder
  --> Installing archlinux build root:
--> Archlinux prepare-chroot-base
  --> Bootstrap chroot environment may not exist, calling 00_prepare.sh...
--> Archlinux 00_prepare.sh
  --> Downloading Archlinux bootstrap tarball (v2016.08.01)...
--2016-08-13 14:53:39--  
http://mirrors.kernel.org/archlinux/iso/2016.08.01/archlinux-bootstrap-2016.08.01-x86_64.tar.gz
Resolving mirrors.kernel.org (mirrors.kernel.org)... 149.20.37.36, 
198.145.20.143, 2620:3:c000:a:0:1994:3:14, ...
Connecting to mirrors.kernel.org (mirrors.kernel.org)|149.20.37.36|:80... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 116295360 (111M) [application/octet-stream]
Saving to: 
‘/home/user/qubes-builder/cache/archlinux/archlinux-bootstrap-2016.08.01-x86_64.tar.gz’

archlinux-bootstrap 100%[===>] 110.91M  2.94MB/sin 52s 

2016-08-13 14:54:32 (2.15 MB/s) - 
‘/home/user/qubes-builder/cache/archlinux/archlinux-bootstrap-2016.08.01-x86_64.tar.gz’
 saved [116295360/116295360]

--2016-08-13 14:54:32--  
http://mirrors.kernel.org/archlinux/iso/2016.08.01/archlinux-bootstrap-2016.08.01-x86_64.tar.gz.sig
Resolving mirrors.kernel.org (mirrors.kernel.org)... 198.145.20.143, 
149.20.37.36, 2620:3:c000:a:0:1994:3:14, ...
Connecting to mirrors.kernel.org (mirrors.kernel.org)|198.145.20.143|:80... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 287 [application/octet-stream]
Saving to: 
‘/home/user/qubes-builder/cache/archlinux/archlinux-bootstrap-2016.08.01-x86_64.tar.gz.sig’

archlinux-bootstrap 100%[===>] 287  --.-KB/sin 0s  

2016-08-13 14:54:32 (9.60 MB/s) - 
‘/home/user/qubes-builder/cache/archlinux/archlinux-bootstrap-2016.08.01-x86_64.tar.gz.sig’
 saved [287/287]

  --> Preparing GnuPG to verify tarball...
gpg: keyring `/home/user/qubes-builder/cache/archlinux/gpghome/secring.gpg' 
created
gpg: keyring `/home/user/qubes-builder/cache/archlinux/gpghome/pubring.gpg' 
created
gpg: /home/user/qubes-builder/cache/archlinux/gpghome/trustdb.gpg: trustdb 
created
gpg: key 6AC6A4C2: public key "Pierre Schmitz (Arch Linux Master Key) 
" imported
gpg: key 824B18E8: public key "Thomas Bächler (Arch Linux Master Key) 
" imported
gpg: key 4C7EA887: public key "Ionut Biru (Arch Linux Master Key) 
" imported
gpg: key FFF979E7: public key "Allan McRae (Arch Linux Master Key) 
" imported
gpg: key CDFD6BB0: public key "Dan McGee (Arch Linux Master Key) 
" imported
gpg: key 9741E8AC: public key "Pierre Schmitz " imported
gpg: Total number processed: 6
gpg:   imported: 6  (RSA: 6)
gpg: no ultimately trusted keys found
  --> Verifying tarball...
gpg: Signature made Mon 01 Aug 2016 07:42:55 PM MSK using RSA key ID 9741E8AC
gpg: Good signature from "Pierre Schmitz "
gpg: WARNING: This key is not certified with a trusted signature!
gpg:   

[qubes-users] Re: Manual https://www.qubes-os.org/doc/templates/archlinux/ does not work.

[lol lol]

And that...


[root@development user]# cd qubes-builder/
[root@development qubes-builder]# ls
builder.confqubes-release-1-signing-key.asc
builder.conf.bakqubes-release-2-signing-key.asc
build-logs  qubes-release-3.0-signing-key.asc
cache   qubes-release-3.1-signing-key.asc
chroot-archlinuxqubes-release-3.2-signing-key.asc
doc qubes-release-3-signing-key.asc
example-configs qubes-src
iso README.md
keyringsrelease-configs
libsrepo-latest-snapshot
Makefilerpc-services
Makefile.dummy  scripts
Makefile.genericsetup
qubes-developers-keys.asc   win-mksrcimg.sh
qubes-packages-mirror-repo  win-mountsrc.sh
[root@development qubes-builder]# make template
mkdir -p 
/home/user/qubes-builder/qubes-src/linux-template-builder/pkgs-for-template/archlinux/pkgs
for arch_build_dir in archlinux; do\
pkgnames=`cat qubes-src/vmm-xen/$arch_build_dir/PKGBUILD | grep pkgname 
| cut -d "=" -f 2 | tr -d '()"'`;\
for pkgname in $pkgnames; do\
ln -f qubes-src/vmm-xen/pkgs/$pkgname-*.pkg.tar.xz 
/home/user/qubes-builder/qubes-src/linux-template-builder/pkgs-for-template/archlinux/pkgs/;\
done;\
done;\

ln: failed to access ‘qubes-src/vmm-xen/pkgs/qubes-vm-xen-*.pkg.tar.xz’: No 
such file or directory
/home/user/qubes-builder/qubes-src/builder-archlinux/Makefile.archlinux:156: 
recipe for target 'update-repo' failed
make[1]: *** [update-repo] Error 1
Makefile:296: recipe for target 'template-local-archlinux' failed
make: *** [template-local-archlinux] Error 1
[root@development qubes-builder]#

-- 
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/c2b8c4d5-0dca-425c-829b-457fdfb2ae02%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] grub2-mkconfig not found

[zackptg5]

On Saturday, August 13, 2016 at 6:14:44 AM UTC-4, Marek Marczykowski-Górecki 
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Sat, Aug 13, 2016 at 03:11:57AM -0700, Andrew David Wong wrote:
> > On 2016-08-12 20:57, zackp...@gmail.com wrote:
> > > Hi all, I'm a new qubes user and have been following the guides to get
> > > trim enabled for the dom0. Everything seems to have gone smoothly until 
> > > the
> > > grub steps. I can't find a grub.cfg file anywhere. The only abnormality to
> > > my installation is that it's UEFI. So the closest thing I did find to this
> > > was /boot/efi/EFI/qubes/xen.cfg which had the kernel line referenced in 
> > > the
> > > trim guide. However, when I attempt to run grub2-mkconfig -o 
> > > /boot/efi/EFI/qubes/xen.cfg I get "grub2-mkconfig: command not found" All 
> > > that is present in the /boot/grub2 folder is a themes folder. I am using
> > > the main dom0 terminal for all of this.
> > > 
> > > Considering that everything boots fine, I'm hesitant to reinstall grub2 
> > > (I 
> > > assume it would need to be grub2-efi in this case). Any clue as to what's 
> > > going on? Thanks
> > > 
> > 
> > I think grub2-mkconfig is not found because you're using UEFI rather than
> > legacy boot. Are you getting your instructions from here?
> > 
> > https://www.qubes-os.org/doc/disk-trim/
> > 
> > I think these instructions were written with legacy boot in mind. I'm not 
> > sure
> > how to enable TRIM on UEFI (CCing Marek).
> 
> Yes, on UEFI install /boot/efi/EFI/qubes/xen.cfg is the right file - you
> need to edit it directly.
> 
> - -- 
> 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
> 
> iQEcBAEBCAAGBQJXrvMNAAoJENuP0xzK19csfqQH/0/P4FV8W2/pZhWaCeXfseqj
> fw79GDTa5/ExjxSg4eehHDhHHVgG3kaeb0HafPvVnHS/DJuHzCG1Xrs1vyZJlPID
> oCrH4FaaYQ2Che4L4D/Koh5lNEdEakKOrF7ILbTRN5u8Q4xvdM9KQ/paacCYkCDJ
> YlYKELzyOZ1wkUvwttPynTANdrMlY797BHkHYHv2TbaMBTjw4EYmIs+VM9MRIWIv
> Lis1hZn97y1z3ZIQglrQRCDLAmoNJPBsXRdMHjNyA5EeKQPX+fNxsE3/HIoqrIi3
> 3DHYzKIS/UBDFHOJXj7I3pK311fS1IcUlrbRCXJYCM0gF5A5EkWKxIj0ghV0YTI=
> =uhvX
> -END PGP SIGNATURE-

So I'm editing the right file, that's all and good. Here's what I've done so 
far: 

#Find UUID of ssd
ls /dev/mapper/luks-*
#Set trim in crypttab
sudo nano /etc/crypttab
#Add "allow-discards" at end of entry for ssd with matching UUID
#Set trim in fstab
sudo nano /etc/fstab
#Add "discard" after other flags (like "default") for everything but swap
sudo nano /etc/lvm/lvm.conf
#Change "issue_discards" from "0" to "1"
#Add discard to grub
sudo nano /boot/efi/EFI/qubes/xen.cfg
#At the end of the kernel line, add "rd.luks.allow-discards=1"
#Rebuild initramfs
sudo dracut -H -f
##Check if discard (trim) is enabled:
lsblk -D
#OR
sudo dmsetup table

Everything above works except that lsblk still shows no trim support so I guess 
that the rebuilding of grub is an important step in this. How do I rebuild it 
with UEFI? I tried:

grub2-mkconfig -o /boot/efi/EFI/qubes/xen.cfg

but I just get the grub2-mkconfig not found error

-- 
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/80d636f9-a331-449b-9b46-2ad1b7301523%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] grub2-mkconfig not found

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-08-13 06:53, zackp...@gmail.com wrote:
> On Saturday, August 13, 2016 at 6:14:44 AM UTC-4, Marek 
> Marczykowski-Górecki wrote: On Sat, Aug 13, 2016 at 03:11:57AM -0700, 
> Andrew David Wong wrote:
 On 2016-08-12 20:57, zackp...@gmail.com wrote:
> Hi all, I'm a new qubes user and have been following the guides to 
> get trim enabled for the dom0. Everything seems to have gone 
> smoothly until the grub steps. I can't find a grub.cfg file 
> anywhere. The only abnormality to my installation is that it's 
> UEFI. So the closest thing I did find to this was 
> /boot/efi/EFI/qubes/xen.cfg which had the kernel line referenced
> in the trim guide. However, when I attempt to run grub2-mkconfig -o
>  /boot/efi/EFI/qubes/xen.cfg I get "grub2-mkconfig: command not 
> found" All that is present in the /boot/grub2 folder is a themes 
> folder. I am using the main dom0 terminal for all of this.
> 
> Considering that everything boots fine, I'm hesitant to reinstall 
> grub2 (I assume it would need to be grub2-efi in this case). Any 
> clue as to what's going on? Thanks
> 
 
 I think grub2-mkconfig is not found because you're using UEFI rather 
 than legacy boot. Are you getting your instructions from here?
 
 https://www.qubes-os.org/doc/disk-trim/
 
 I think these instructions were written with legacy boot in mind.
 I'm not sure how to enable TRIM on UEFI (CCing Marek).
> 
> Yes, on UEFI install /boot/efi/EFI/qubes/xen.cfg is the right file - you 
> need to edit it directly.
> 
> 
> So I'm editing the right file, that's all and good. Here's what I've done 
> so far:
> 
> #Find UUID of ssd ls /dev/mapper/luks-* #Set trim in crypttab sudo nano 
> /etc/crypttab #Add "allow-discards" at end of entry for ssd with matching 
> UUID #Set trim in fstab sudo nano /etc/fstab #Add "discard" after other 
> flags (like "default") for everything but swap sudo nano /etc/lvm/lvm.conf
>  #Change "issue_discards" from "0" to "1" #Add discard to grub sudo nano 
> /boot/efi/EFI/qubes/xen.cfg #At the end of the kernel line, add 
> "rd.luks.allow-discards=1" #Rebuild initramfs sudo dracut -H -f ##Check if 
> discard (trim) is enabled: lsblk -D #OR sudo dmsetup table
> 
> Everything above works except that lsblk still shows no trim support so I 
> guess that the rebuilding of grub is an important step in this. How do I 
> rebuild it with UEFI? I tried:
> 
> grub2-mkconfig -o /boot/efi/EFI/qubes/xen.cfg
> 
> but I just get the grub2-mkconfig not found error
> 

Quoting Marek from a different thread [1]:

> By default, if you install Qubes OS in EFI mode (which is the case when
> you launch installer as such), grub is not installed at all and Qubes is 
> configured to boot xen.efi directly from UEFI BIOS.
> 
> In that case, xen and kernel command line can be configured in 
> /boot/efi/EFI/qubes/xen.cfg.
> 
> Some details here: https://github.com/QubesOS/qubes-issues/issues/794

So, I don't think you're supposed to try to rebuild grub. Have you tried
simply rebooting after editing xen.cfg?


[1] https://groups.google.com/d/msg/qubes-users/0855TpoheY8/qxOnC_ZCDQAJ

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

iQIcBAEBCgAGBQJXry9fAAoJENtN07w5UDAwXnoP/3fFWf9MsgDdu9Frr7yOn5Fn
gtotENq4qZlpBwY/k1zSa8jGN8wT0nZcYZthUQgeIe4mUzh8Db/m2uAKDZCpFFRH
QzWvRBChcssXtzrtslkn5uf78g3d/VEonl0Fp/RQPl3bleKNMrssbhk0LchFXe/U
uDYdKWlTbTOYKP5Ucl/fEi+KxBWMx3EhBcKzbBi6WYuvy4/juyAAn/wF5xBWWzkP
zv0bTfsPSIP+HMqZ6P0bbcy5Fe4PTib8InsRiiRucwIZ2ulxXbd5S7WPws/lNTVD
rzgz/myv1ptIm8H5D1bliCVbBHaaDGNzNJMIoNCd1gcDgucI2Ov4kgfVbfxvENHg
/JAMmbZvyFW7nnXW46goYBtZ+MOBnidA8DhSpY5tLJiJ+MNsamwStc08mtoL7uqx
qNX2JDrW/SEzKzPwoEatVlVbdsfg7omjI4cLpUBfuQgbc6x4g/iol7lPn03DfCO0
3+lQFmx5/HWGBg00Ta3rznYK78mWfwpFaxVlQ4y7y7STjPOZ2AVE1V811oqLrtfO
xN3fYiCXGFHrgDukPhyHyzwnVifyWqiP7YsEdR4fUeFolmoiynKTFfSC75be7FOg
V5xEpS/qhAA979IVwOT0OGUUy1nkqEeXvhQbFQVSo1k+FHUucjCbrgsdb8EHbMlH
voRCXtsaCyMpCdZi1hNw
=fSFj
-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/a5d058fe-4b9b-b917-c56a-9b043c4d1814%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: Messaggio privato relativo a: [qubes-users] Re: Unable to install R3.1 / media check failure

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-08-13 07:28, Gabriele Bini wrote:
> Il giorno sabato 13 agosto 2016 12:22:04 UTC+2, Andrew David Wong ha
> scritto: On 2016-08-13 01:25, Gabriele Bini wrote:
 I used dd: my current system is a Linux Mint 17.
 
> 
> Ok, then this might be a different issue. The previous one was due to Rufus
>  and has already been fixed (or so we thought). However, given your new 
> information, it's possible there's actually a common root cause. Tracking 
> your new issue here:
> 
> https://github.com/QubesOS/qubes-issues/issues/2246
> 
> P.S. - Please avoid top posting.
> 
 
 On Sat, Aug 13, 2016 at 8:47 AM, Andrew David Wong 
  wrote:
 
 On 2016-08-12 11:24, Gabriele Bini wrote:
>>> Hello, I have exactly the same problem. This is what I did: 1.
>>> I
 downloaded
>>> the Qubes-R3.1-x86_64.iso ISO from the Torrent. 2. I checked
>>> the
 signature
>>> and the hash values in the DIGEST file (I checked just the hash
>>>  values
 in a
>>> second PC) and everything was fine. 3. I used dd to copy the
>>> ISO in a USB flash drive (Sony 8Gb) 4. When I booted from the
>>> USB I tried the “Verify and Install” option but, exactly at
>>> 4,8% (as for Cory Nelson) the check failed. There was a message
>>> of this type (copied by hand): Failed to
 start
>>> media check on /dev/sdc See 'systemctl status checkisomd5@
 -dev-sdc.service'
>>> and 'journal.ctl-xn'  for details 5. I couldn't check anything
>>>  because
 the
>>> system was halted
>>> 
>>> What can I do? Thank you in advance!
>>> 
 
 Did you use Rufus or Unix dd?
 
> 
> 
> Thank you! I will follow the issue on github: let me know if I should try 
> some experiments (I was thinking of copying the ISO on a different USB
> flash drive and using dd from a different computer...)

If you don't mind trying that, it would indeed be helpful to know whether you
can reproduce the problem on different hardware.

> Sorry for the "top posting": i have never used Google Groups before and I 
> assumed it works like a forum. I used "reply" the first time and "reply
> all" the second time (and I guess this is "top posting" because it involves
> all qubes-users users, right?).

No, top posting is when you place your reply on top of the quoted message rather
than on the bottom or interleaved:

https://en.wikipedia.org/wiki/Posting_style#Top-posting

(My reply to you right now is an example of interleaving.)

> For now I use "reply to author", just to be sure...
> 

If you don't mind, please keep the list CCed (unless there's a special need
for privacy). This increases the likelihood that a greater quantity of useful
information will be available to everyone in the future.

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

iQIcBAEBCgAGBQJXrzFZAAoJENtN07w5UDAww80QAKTnpwcxqvXmO0dVkebIchg3
D369WaEe3tOizFtR9rNna6Q+zgGZ38+LQtl87J2/R7W7cm+Nq6RKc3mKQlnRlKxs
JN2RwXhtQtcp0b//i0WmNGQuCgLeWqitUezngbleGMgd9LNrm0jqy5sNAdw9yvZZ
3vJmE5vltNnzI2yxpXK7Wqh27xyXN65wiiCRjZA9p8mdMaLv5l0Wrs7uT9Gcyqz4
X1K98hptTV4cXpnjhZ5lDuD3y6G4jvZfnYcLLdX0uBHPJD9Nnmv3AJAaRp9y8K8T
YhoZr4kOd8DhL+91g/l2Wo6k1rpU+HHxh9HsW8WV/wkJftmeCUEWaNW+CQeeF4rt
+YRb4/vJcFuxXBZaaoUuosFRLUOL3sQWt6ZYqFhX4Rr/p7DQ60D9q1WehAJYE/6I
m9nT+3s+TDg22m87QPrWlatmrUApd8HqVUObdsbIGXD1uO8qlCvYj1TR+E6xrK3n
t/uo2uBVuYRRkB9N3c/4NgWVeIOiGDCE+DJ42rwiBGGc1nbr7glu0/w+jAW78eRK
H33bwXLRF4bRIy713xOZOzIjYoZHE3snY9jGep+XB7ZSnPYrlNlXheNgzeLPkqE4
Bo2cibSkoIoSgSX1A16fWj1o5zQCyso1xs405WrkPZyRuW1v6XHzP/IdLpdCiyut
hML54gG1ape3pfsoKqC7
=+nUR
-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/2879e29e-f23f-4ded-ab36-3dac13f223a7%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Installing Whonix VMs in Qubes 3.1 - Still in the community template repo?

[hastingsdrew500]

I recently tried to install the Whonix templates on my Qubes 3.1 system and 
found that they aren't in the repository of ITL maintained images. I had 
assumed that since the 3.1 installer offers to install Whonix for you that ITL 
now considered the Whonix templates the same way that they consider the Fedora 
templates - guaranteed to be compiled from the source code as pulled from 
upstream. If I want to use Whonix in 3.1 do I still need to trust a random 
template builder on top of the distro maintainers and ITL, or does ITL now 
consider the Whonix templates "safe", at least as much as the Fedora templates, 
despite still providing them through the community repository?

-- 
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/f6cc8505-3916-4229-9578-2081a9d7cce1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] grub2-mkconfig not found

[zackptg5]

I have tried rebooting. The lsblk output has 0s under DISC-ZERO for the dom0 
partitions and the dsmsetup output has a ton of zeros in it which I'm not sure 
what that means (my internet is down, I can post the output hopefully tomorrow 
if that 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/d7011af8-6a88-4bad-ac09-04b1040bd326%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Installing Whonix VMs in Qubes 3.1 - Still in the community template repo?

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-08-13 07:41, hastingsdrew...@gmail.com wrote:
> I recently tried to install the Whonix templates on my Qubes 3.1 system
> and found that they aren't in the repository of ITL maintained images. I
> had assumed that since the 3.1 installer offers to install Whonix for you
> that ITL now considered the Whonix templates the same way that they
> consider the Fedora templates - guaranteed to be compiled from the source
> code as pulled from upstream. If I want to use Whonix in 3.1 do I still
> need to trust a random template builder on top of the distro maintainers
> and ITL, or does ITL now consider the Whonix templates "safe", at least as
> much as the Fedora templates, despite still providing them through the
> community repository?
> 

Well, it's not a "random" template builder. The template builder is Patrick
Schleizer, who is a well-known, well-respected member of the Qubes team and
the community (and, of course, even more well-known and well-respected as the
creator of Whonix).

I think the main for the different repos is, as you point out, that the
templates are officially maintained by different organizations. ITL (i.e., the
core Qubes devs employed by ITL) maintains the Fedora and Debian templates but
not the Whonix templates.

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

iQIcBAEBCgAGBQJXrzgzAAoJENtN07w5UDAwvnYP+wehxJXY+qSmpqXa475yd8tF
WIuTL3plMOf23p2fYo71XdEwg7Lk+onUda7zYVzX+gSORRqP8CxlNTmbo5NatJ+H
QOrPFonTdw8g5YdZobicSSe5AAI+4f6hvccRXXcMLVQ7UEZ/BMbPILL5DWDfSk2x
Mpk4g5SSHCzEIQdtm6L1RuIEJ5cKBi2rn+6X7RHhYPjRemIe/OUDFk/HxxWWz7wL
Un0n6VHTaNqX7z1CkBsyQMbydH6y+nX9qaqtP9a9Ig/M3FxHiv5x5AF05Pb8/N5d
6EVyZjpH9IURC729yWzfMRmrMolFMgf5/XXXNLrWQ6QZB2TbdSqMcBCPl/Xrr8uH
XGPuBkITdjVucDYSZLm1TOu5gUwkSvb5mEK0HM6RQiUD5rk/1AWBlWY2MH4oaHY0
3YRw/A8pvHD9TOG+CHlQLm9QnGuOXITsAjvdRA1fuHTao/OZ8MxpUaqMMPFwNfl9
IbrmWs/VFj92BOPqohlFRizANjVbV6Z6mW5q8utkDyVOhH2Y9v7lwEdl4cOqCNqU
NJWu9FnEEYNK828PzoWIdIUm0oBt8+lcq8A64y6d5hpBX5y4LIeI9FwnqEdmfIXf
1VPyevQGsLPflAd/4GEDpc6bOkrJI8y9g9O/x7lDGA9ALBy71yl/4W3lc2Md2Ro2
UHQeQp6JbN9lAzrfy6/5
=2ZI6
-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/3aa98bfc-c847-935a-2659-106193b0984d%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 3.2(R2) USB Connecting to DOM0 by Default

[amadaus]

On 2016-08-11 18:50, Andrew David Wong wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-08-11 05:08, amad...@riseup.net wrote:

My understanding is that by default Qubes Dom0 is protected from USB
attacks by disallowing access to USB's. To the contrary,on my system, 
USB's
have direct access to Dom0 - I plug in a usb -popup shows it's 
connected to

dom0 - i have direct access via dom0 to the files on the usb.

Is it just me? or it it a system failure?



Pleas read this page:

https://www.qubes-os.org/doc/usb/

Without a USB qube, the USB controllers are left in dom0, which sounds 
like
your situation. Depending on the version of Qubes you're using and 
whether
you're using a USB keyboard and/or mouse, you should have been prompted 
during
installation to create a USB qube. However, you can also create one 
yourself

by following the instructions on that page.

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

iQIcBAEBCgAGBQJXrMkGAAoJENtN07w5UDAw2SkQAKE230GVdVVTj6ds7dH2m7ua
LJfdrLATMfXiCc8ua0GCPB/LFlBHua39LJDowL0okeX7UZfh6mPS+iQ51wEDVHU1
Mox/PaEqkKpv7QnIj/6XSV3sIhwYqTIL+5HFBhd3IE8Psj2NCb30fYFJgoOdcpR6
/8Y2huXCxCIvlsuTnxaa9/xvwZXKaN7eB00OMrk2pzRBfNOTedMIONzy5pPOvF2Q
X0cOln+U7s2iu0s+WmZWtcgX82qKpTWa07r96WcTU262e8+TXvH8umZZtIlJLwLU
eJxucUJFaNOGYGUL9dx6zaFiQ5WmOpCQ37Awh/3m/iVgL6FrpUlX+z66ZCpC6UZG
pwjHKcv3jRyxNIXTu6ROwjPzjjuHx8xuKAP1cIhU/EsQi+k6goWXeIalwO2lmDy1
+lZwm3oHN1w2BEtPBthB+GDEsVjCzlUKnZSPZzj9rSMNW5CkYuw/KLXtKKhm2jcy
7sSAk8zZ320NA0OeLcMR485QFaQ3HPtVoWdaA2aHjV/bTtMQMR72rgUZGXI3jntB
kFnQfa255+IQN8+WH6goHypuunSz3od3HH1ChlSnO2slzykMRiy51bHvLGnyNILN
TuKSTBTzqHxeV242NoqJye+zVTm5Ka1V43MTjIO6vhLCFz5HN6ezViT3GX/Eehah
nrDdi2shrGFOzLwP7Zea
=ZISO
-END PGP SIGNATURE-

Thanks all for your input.
I do not recall being prompted to create a USB VM during installation of 
3.2 rc2. However, I've now successfully created one and it works fine. 
But I'm jittery that my system's integrity has been comprised by a 
compromised USB Flash stick.
I guess the only solution is to ditch my current VM's [including 
backups] and reinstall qubes?
It would be really good if the developers could modify their code to 
prevent users from accidentally falling into this unfortunate trap.


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

Re: [qubes-users] Updates Proxy a security Risk?

[johnyjukya]

>> Say you have a VM (e.g. "Banking only"), which has a NetVM of
>> sys-firewall,
>> but for which you have disallowed or greatly restricted networking,
>> turned
>> off DNS and ICMP, but left on "allow connection to updates proxy."
>>
>
> That box should be unchecked by default in AppVMs and checked by default
> in
> TemplateVMs.

Fair enough.  Choosing a sane default is half the battle, and does indicate
to the user (subtly ;) ) the right thing to do.  And I agree you don't
want to
"warn the user to death" about every possible peril.

One argument I might make, however, is that the update proxy does not belong
in the sys-net VM, but in the sys-firewall VM.

Part of the elegance of the sys-net VM is that it isolates the network card
from shenanigans affecting other parts of the system.  Compromising the
update proxy could obviously hand over the "keys to the kingdom" to all
the VM's via template updates.  (Although proper package signing and
verification
would limit that threat.)

And yes, if the network card is compromised, even moving the update proxy to
vm-firewall isn't going to protect you from mitm, redirection, DNS spoofing,
and other attacks from sys-network.

However, it does make more sense with yet-another suggestion I might make:

Since tinyproxy should only be used to contact legit update repos, there's no
reason it couldn't be configured (perhaps auto-configured by Qubes Manager,
from information in each template), to restrict access to *only* update sites
on port 443 (last part is already there).  e.g.:

tinyproxy-updates.conf:
> FilterDefaultDeny YES
> Filter tinyproxy-updates-filter.conf

tinyproxy-updates-filter.conf:
> fedoraproject.org
> debian.net
> debian.org
> [windows URL for those crazy enough to run windows hvms...]

I'll be manually doing this myself, shortly.

I'll also try moving the update proxy to sys-firewall (just a matter of
setting it up there, and changing the Templates to have their dns/apt tools
to point to it, I think)...  Where does the Qubes VM Manager get its
proxy-address to modify the firewall rules?  Hopefully from some xml
template I can change.

With what I would now consider an important configuration file now
part of tinyproxy, it makes a bit more sense to get it out of sys-net,
so a compromised sys-net can't affect which servers the Template (or
mis-configured App) VM's are allowed to contact (although yes, it
could still redirect packets, yadda, yada, yadda...)

(Also, on a quick browse through the yum repos, did I see Adobe and
Google repos there?  I'm not sure I inherently trust them.  I'm
personally moving my system to be as Debian based as possible, to
remove U.S. and commercial companies from the mix as much as possible.)

>> (I worry a bit that the attitude of the Qubes developers is "oh well, if
>> you're compromised, you're screwed anyway, no sense adding more
>> security."
>> See no-password sudo, for example.
>
> I think the idea is more like: "Let's not bullshit our users. If some
> purported security measure doesn't actually add any real security, then
> we're
> not going to implement (or preserve) it and point to it as evidence of
> defense
> in depth (because it's really not). By contrast, we welcome defense in
> depth
> that actually works."

Again, fair enough.  The first couple of times I saw that approach, I thought
"well, that's sensible and up-front," which I like.  :)  And as long as
minds are open to discussions on how to improve things (being wary of
feature-creep), I'm very cool with it.

And hey, if I disagree with one of your policies, I'm free to change it on
my system.  :)

JJ



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

Re: [qubes-users] Qubes 3.2(R2) USB Connecting to DOM0 by Default

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-08-13 09:35, amad...@riseup.net wrote:
> On 2016-08-11 18:50, Andrew David Wong wrote: On 2016-08-11 05:08,
> amad...@riseup.net wrote:
 My understanding is that by default Qubes Dom0 is protected from USB 
 attacks by disallowing access to USB's. To the contrary,on my system,
 USB's have direct access to Dom0 - I plug in a usb -popup shows it's
 connected to dom0 - i have direct access via dom0 to the files on the
 usb.
 
 Is it just me? or it it a system failure?
 
> 
> Pleas read this page:
> 
> https://www.qubes-os.org/doc/usb/
> 
> Without a USB qube, the USB controllers are left in dom0, which sounds
> like your situation. Depending on the version of Qubes you're using and
> whether you're using a USB keyboard and/or mouse, you should have been
> prompted during installation to create a USB qube. However, you can also
> create one yourself by following the instructions on that page.
> 
> Thanks all for your input. I do not recall being prompted to create a USB
> VM during installation of 3.2 rc2. However, I've now successfully created
> one and it works fine. But I'm jittery that my system's integrity has been
> comprised by a compromised USB Flash stick. I guess the only solution is to
> ditch my current VM's [including backups] and reinstall qubes? It would be
> really good if the developers could modify their code to prevent users from
> accidentally falling into this unfortunate trap.
> 

Tracking:

https://github.com/QubesOS/qubes-issues/issues/2211#issuecomment-239632240

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

iQIcBAEBCgAGBQJXr1kEAAoJENtN07w5UDAwDsYP/AjV012O4VlX4uS7yAkNA4zY
HkLPpFV2e266+Vht5eX0TOvLmPBi70B5YeKX4FuL+43JMmPLdWhD+uu7Og67kTz9
KQIAxHAYswmsFPiKRhdvx+Sg56KFEtrugEHJeWWtu/yKJR/d8IL4Vy49RI7IAMWm
00vTd4Aj13EjULOt91mS4k3JwyfBCANzCSPsR94PzrROGrTResYAzZOM3uNSWwi2
CCduR29wcB0jg1QUi8fiOUKBdjkCDBYwPVZX883OONw49IXlisCYuPwLZB+nIi2q
7jxKIpbdOhtZHDyRFNfCNYiTe4q2G6W4vu7XuolgvICuCArO/QxjFWs7K5bDogzN
/RNHNceztRk+hi0OFxHoKlLt7VQRcgCIMK+r3NZOPvf1nXmILMXmU4Yj7CcXOLs4
xf3vKYJ+NgOFs7V6XRja8tH8p9STMNuu0QEskHM303SL5Z92XuKoKOa7/J+9OlXB
PmTjKFpRmSH2dpiH4usixcQE2ri2lfppK+1LEkbqHWaqhpTRcLLEdpMDIwwT6Ivz
PmbgFC4yCK+3D6uQF80ge7oyo46Du0uLK2eIaEnjW88H24zvFa/E+tPxZA9fHElU
ZqmYoexflR7bVW+7omsTDMjl7UUL3wQ9dw4wqeD9aWtv+5875enLGu2uE4C+kqDc
c3nqv4CZMHOHc3X5AN1U
=QqmJ
-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/9c2b1bb6-a025-4929-f081-d5f31452a7a9%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Updates Proxy a security Risk?

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-08-13 09:49, johnyju...@sigaint.org wrote:
>>> Say you have a VM (e.g. "Banking only"), which has a NetVM of 
>>> sys-firewall, but for which you have disallowed or greatly restricted
>>> networking, turned off DNS and ICMP, but left on "allow connection to
>>> updates proxy."
>>> 
>> 
>> That box should be unchecked by default in AppVMs and checked by default 
>> in TemplateVMs.
> 
> Fair enough.  Choosing a sane default is half the battle, and does
> indicate to the user (subtly ;) ) the right thing to do.  And I agree you
> don't want to "warn the user to death" about every possible peril.
> 

Perhaps a good compromise (i.e., a less intrusive way to warn/educate the user
about this) would be with an explanatory tooltip. Added the suggestion here:

https://github.com/QubesOS/qubes-issues/issues/2211#issuecomment-239632572

> One argument I might make, however, is that the update proxy does not
> belong in the sys-net VM, but in the sys-firewall VM.
> 
> Part of the elegance of the sys-net VM is that it isolates the network
> card from shenanigans affecting other parts of the system.  Compromising
> the update proxy could obviously hand over the "keys to the kingdom" to
> all the VM's via template updates.  (Although proper package signing and 
> verification would limit that threat.)
> 

Part of the Qubes philosophy is "Don't trust the infrastructure," where "the
infrastructure" includes the updates servers. We basically assume those are
compromised and instead place our trust in package signature verification.
- From this perspective, it isn't handing over the keys to the kingdom at all,
and proper package signing and verification does more than just limit the
threat. It guarantees -- to the extent that cryptographic signatures can --
that the package we've received (even from a possibly compromised server) is
in fact the package the signer intended for us to receive.

> And yes, if the network card is compromised, even moving the update proxy
> to vm-firewall isn't going to protect you from mitm, redirection, DNS
> spoofing, and other attacks from sys-network.
> 
> However, it does make more sense with yet-another suggestion I might make:
> 
> Since tinyproxy should only be used to contact legit update repos, there's
> no reason it couldn't be configured (perhaps auto-configured by Qubes
> Manager, from information in each template), to restrict access to *only*
> update sites on port 443 (last part is already there).  e.g.:
> 
> tinyproxy-updates.conf:
>> FilterDefaultDeny YES Filter tinyproxy-updates-filter.conf
> 
> tinyproxy-updates-filter.conf:
>> fedoraproject.org debian.net debian.org [windows URL for those crazy
>> enough to run windows hvms...]
> 
> I'll be manually doing this myself, shortly.
> 
> I'll also try moving the update proxy to sys-firewall (just a matter of 
> setting it up there, and changing the Templates to have their dns/apt
> tools to point to it, I think)...  Where does the Qubes VM Manager get its 
> proxy-address to modify the firewall rules?  Hopefully from some xml 
> template I can change.
> 
> With what I would now consider an important configuration file now part of
> tinyproxy, it makes a bit more sense to get it out of sys-net, so a
> compromised sys-net can't affect which servers the Template (or 
> mis-configured App) VM's are allowed to contact (although yes, it could
> still redirect packets, yadda, yada, yadda...)
> 

I'll leave it to Marek (CCed) to comment here.

> (Also, on a quick browse through the yum repos, did I see Adobe and Google
> repos there?  I'm not sure I inherently trust them.  I'm personally moving
> my system to be as Debian based as possible, to remove U.S. and commercial
> companies from the mix as much as possible.)
> 

Those are disabled by default ("enabled=0"). It should go without saying that
we don't place any trust in those companies. The repos are just there for your
convenience, in case you want to enable them (e.g., in less trusted templates).

>>> (I worry a bit that the attitude of the Qubes developers is "oh well,
>>> if you're compromised, you're screwed anyway, no sense adding more 
>>> security." See no-password sudo, for example.
>> 
>> I think the idea is more like: "Let's not bullshit our users. If some 
>> purported security measure doesn't actually add any real security, then 
>> we're not going to implement (or preserve) it and point to it as evidence
>> of defense in depth (because it's really not). By contrast, we welcome
>> defense in depth that actually works."
> 
> Again, fair enough.  The first couple of times I saw that approach, I
> thought "well, that's sensible and up-front," which I like.  :)  And as
> long as minds are open to discussions on how to improve things (being wary
> of feature-creep), I'm very cool with it.
> 
> And hey, if I disagree with one of your policies, I'm free to change it on 
> my system.  :)
> 

:)

> JJ
> 

- -- 
Andrew David Wo

Re: [qubes-users] Qubes 3.1 - Fedora update check disabled but still check

[johnroberts19855]

On Saturday, August 13, 2016 at 12:28:59 PM UTC+2, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2016-08-13 01:48, johnroberts19...@gmail.com wrote:
> > On Saturday, August 13, 2016 at 8:45:42 AM UTC+2, Andrew David Wong wrote: 
> > On 2016-08-12 11:19, johnroberts19...@gmail.com wrote:
>  Hello
>  
>  i disable all the option auto update options but qubes still pop the 
>  update icon in my qubes vm manager.
>  
>  qubes vm manager "System - Global Settings" Disable dom0 and VM
>  updates
> > 
> > What is the output of "qubes-set-updates status" (in dom0)?
> > 
> > 
> >> dom0 = disabled vms = enabled
> > 
> > 
> > Also, check the "Services" tab of the affected TemplateVMs. There should a 
> > service called "qubes-update-check", and its box should *not* have a check
> > mark.
> > 
> >> there was no "qubes-update-check" i add it and uncheck it.
> > 
> >> now "qubes-set-updates status" message me:
> > 
> >> dom0 = disabled vms = mixed
> > 
> >> it seems to be working.thank you. but why i have to do it manualy?
> > 
> 
> I'm not sure why the manual change is required. It is conceivable that there
> has been a regression of #892 (CC Marek):
> 
> https://github.com/QubesOS/qubes-issues/issues/892
> 
> In any case, please note that "mixed" means that some TemplateVMs have update
> checks enabled, while others do not. If you don't want *any* update checks,
> you need make sure that both are set to "disabled".
> 

So for my fedorar template vm i unchecked "qubes-update-check" in services tab. 
After a new boot the "new update" icon pop up at "qubes vm manager" 

Than i do manual "sudo dnf update" (in fedora templatevm) and then they sad no 
new updates... so the icon in the qubes vm manager seems to be buggy.


I'm very happy with qubes is more like a simple distribution thank you all for 
creating it but the automatic update thing is buggy as hell seems need rework.

i don't feel that i have the control maybe its the price for using a gui ??


> In order to do this, you can try issuing "qubes-update-check disable" (from
> dom0), then check the status again. If that still doesn't work, then make sure
> to manually add the "qubes-update-check" service and uncheck the box in every
> TemplateVM (assuming, again, that you don't want any TemplateVMs to have
> automatic update checking).
> 
> > 
> >> the same is for whonix... it says there are updates even if sys-whonix
> >> isn't running and don't connected to tor...
> > 
> 
> I imagine this is because the whonix-gw template still has update checking
> enabled (see above). Try disabling it (as instructed above) and see if the
> problem persists.
> 
> > 
> > 
>  Fedorar 23 Template VM disable firewall rule "Allow connections to
>  Updates Proxy"
>  
> > 
> > This setting doesn't affect update checks. The update checks are done by 
> > AppVMs based on the TemplateVMs. The updates proxy setting just controls 
> > whether the TemplateVM itself is able to communicate with remote repos
> > when you actually try to update it.
> > 
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> -BEGIN PGP SIGNATURE-
> 
> iQIcBAEBCgAGBQJXrvZdAAoJENtN07w5UDAwEzoP/i5uTTJBS1arS0YaVNJH8Xz4
> ZckNC9o+Z90IVjByP07R2vqJACRQK0KfxgpYpZPApAhVDEzKoqlfYvALNLKC/wsF
> O5z2kYYsDya5jqd6ba6O62dnl3t91GLHlmuYQnYYvj+GIaaTqcTJFL/ONvIutUB0
> iC0/MhjbLLcqZwByn45Qrfjj0UT/KQ1P8iblW+WyaqDQ/2FD+jIGdONCo+JMIKow
> pDOm27DSuzJ73wkrG5Dk/UZTPkvjSTQ8+I4fdqTS2cEOguC6VI3Q6N+P9N+TacXE
> K0PvALQ2Pplf78ay9DBTarKBHQX7XIUa0DKOWGb5JDLo7mW3eTPKe+QG7jTqs03A
> iZv3f6z4hjOOVw5+tEJ3P7eKHr90gzk+CahQ3M9KqUSG3ODDQWfXCkZmBEqi1eDQ
> VA/iGktHEutpkWmZU/RYmqMyppzm/xFY5j2gbd4/9bgTdm1BP7E350R1NhSiON0u
> gQN6TnbIbEZsnqFBj+sncAL3HFlrifj3Qq4jls8TT20b8ToElWzbWGgjYwb09rGY
> S0/Cjq6SU81KISmOIHlpfzudn7fY5McRJP7PtU39nmzSEuJbTWucxKBVYYpSD3N4
> NnnmtzTxHmtoXaddSOlneUDVarItYuFAouc2VGLzJFK/spy03u8pz04HkVOBPxib
> csNandHw9EJDJVcnwD0H
> =pSNA
> -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/5760d3ae-e085-4201-8040-bdb5f59647a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Updates Proxy a security Risk?

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Aug 13, 2016 at 10:54:22AM -0700, Andrew David Wong wrote:
> On 2016-08-13 09:49, johnyju...@sigaint.org wrote:
> >>> Say you have a VM (e.g. "Banking only"), which has a NetVM of 
> >>> sys-firewall, but for which you have disallowed or greatly restricted
> >>> networking, turned off DNS and ICMP, but left on "allow connection to
> >>> updates proxy."
> >>> 
> >> 
> >> That box should be unchecked by default in AppVMs and checked by default 
> >> in TemplateVMs.
> > 
> > Fair enough.  Choosing a sane default is half the battle, and does
> > indicate to the user (subtly ;) ) the right thing to do.  And I agree you
> > don't want to "warn the user to death" about every possible peril.
> > 
> 
> Perhaps a good compromise (i.e., a less intrusive way to warn/educate the user
> about this) would be with an explanatory tooltip. Added the suggestion here:
> 
> https://github.com/QubesOS/qubes-issues/issues/2211#issuecomment-239632572
> 
> > One argument I might make, however, is that the update proxy does not
> > belong in the sys-net VM, but in the sys-firewall VM.
> > 
> > Part of the elegance of the sys-net VM is that it isolates the network
> > card from shenanigans affecting other parts of the system.  Compromising
> > the update proxy could obviously hand over the "keys to the kingdom" to
> > all the VM's via template updates.  (Although proper package signing and 
> > verification would limit that threat.)
> > 
> 
> Part of the Qubes philosophy is "Don't trust the infrastructure," where "the
> infrastructure" includes the updates servers. We basically assume those are
> compromised and instead place our trust in package signature verification.
> From this perspective, it isn't handing over the keys to the kingdom at all,
> and proper package signing and verification does more than just limit the
> threat. It guarantees -- to the extent that cryptographic signatures can --
> that the package we've received (even from a possibly compromised server) is
> in fact the package the signer intended for us to receive.

Exactly. Also note that the updates proxy is in fact a simple http
proxy, so all it can do, can also be done by any other component in the
network path between template and updates repository itself. This
includes anything running in sys-net (even if updates proxy is running
elsewhere).


> > And yes, if the network card is compromised, even moving the update proxy
> > to vm-firewall isn't going to protect you from mitm, redirection, DNS
> > spoofing, and other attacks from sys-network.
> > 
> > However, it does make more sense with yet-another suggestion I might make:
> > 
> > Since tinyproxy should only be used to contact legit update repos, there's
> > no reason it couldn't be configured (perhaps auto-configured by Qubes
> > Manager, from information in each template), to restrict access to *only*
> > update sites on port 443 (last part is already there).  e.g.:
> > 
> > tinyproxy-updates.conf:
> >> FilterDefaultDeny YES Filter tinyproxy-updates-filter.conf
> > 
> > tinyproxy-updates-filter.conf:
> >> fedoraproject.org debian.net debian.org [windows URL for those crazy
> >> enough to run windows hvms...]
> > 
> > I'll be manually doing this myself, shortly.
> > 
> > I'll also try moving the update proxy to sys-firewall (just a matter of 
> > setting it up there, and changing the Templates to have their dns/apt
> > tools to point to it, I think)...  Where does the Qubes VM Manager get its 
> > proxy-address to modify the firewall rules?  Hopefully from some xml 
> > template I can change.

In fact if you start updates proxy in sys-firewall, it will be enough -
it will intercept traffic going to the proxy. Details:
https://www.qubes-os.org/doc/software-update-vm/#tocAnchor-1-1-9

> > With what I would now consider an important configuration file now part of
> > tinyproxy, it makes a bit more sense to get it out of sys-net, so a
> > compromised sys-net can't affect which servers the Template (or 
> > mis-configured App) VM's are allowed to contact (although yes, it could
> > still redirect packets, yadda, yada, yadda...)

There is very little point in this. There is so much infrastructure
involved in updates distribution (all the mirrors etc), that assuming
none of it can be compromised is unrealistic. On the other hand, even
compromised mirror can't do anything about properly signed package
(besides hiding its existence). 
Updates proxy is only to prevent user mistakes - like browsing the web
directly from the template. Its power comes not from filtering the
traffic, but from the fact that any application not explicitly
configured to use the proxy, will not be able to access the network.
By default only package managers are configured to use the proxy.

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

Re: [qubes-users] USB keyboard with trackpad and trackpoint recognized as mouse

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Aug 06, 2016 at 03:53:44AM -0700, kotot...@gmail.com wrote:
> Hi,
> 
> I have a USB keyboard with an integrated trackpad and trackpoint. When 
> connecting it Qubes if sys-usb can execute Qubes.InputMouse. 
> 
> How can I get it recognized as a keyboard + mouse?

Take a look here:
https://www.qubes-os.org/doc/usb/#tocAnchor-1-1-4

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

iQEcBAEBCAAGBQJXr4RaAAoJENuP0xzK19cs42AH/ixErfop3jsRLbuMkohtr1EN
FdNer+FzrbZBViSUefPALsCG+gFXrAgP/C5ivhgy0fyarn2EGEOr+iaAfWdcQsMU
uVuzt418s2kDiwQu4+dDjbqgmjIq2ZIPpNMI3XQmTxYLKG2DQObNL51dzh9lZ64a
RLCI8HKNqVhxnYvojIyhdT04euS4oyZL9n2HGyYNNQ9NZkqhuytWN6gnyYr2lmb/
cSn/729rlf81fMu0xyjF6Stsj9DrEgoa6S4gaPRcEn+oJm5Y0VEWwqodmpgHkhuU
j01ux22QfP9QYI8ibjXPTPwKj+Vlu20hNOvYAdwIl5JqgV10nq08InkfxuR2K3I=
=kVQ6
-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/20160813203434.GN5701%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] debian template manager (was: Updates Proxy a security Risk?)

[Michael Carbone]

Andrew David Wong:
> On 2016-08-12 15:31, johnyju...@sigaint.org wrote:
>> (Is that Debian Template manager a paid position?  :) )
> 
> I think that depends on the current funding situation (CCing Michael).

currently no, though funding is actively being sought for it.

-- 
Michael Carbone

Qubes OS | https://www.qubes-os.org
@QubesOS 

*new GPG fingerprint: D3D8 BEBF ECE8 91AC 46A7 30DE 63FC 4D26 84A7 33B4*
old GPG fingerprint: 2DBE 2014 E7B0 0730 303D 7AAB 99AB 0624 6EEB F5A8



-- 
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/9d54e3da-a559-d50d-ac4b-2ff6c4f8ecc6%40invisiblethingslab.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] grub2-mkconfig not found

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Aug 13, 2016 at 06:53:20AM -0700, zackp...@gmail.com wrote:
> On Saturday, August 13, 2016 at 6:14:44 AM UTC-4, Marek Marczykowski-Górecki 
> wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > On Sat, Aug 13, 2016 at 03:11:57AM -0700, Andrew David Wong wrote:
> > > On 2016-08-12 20:57, zackp...@gmail.com wrote:
> > > > Hi all, I'm a new qubes user and have been following the guides to get
> > > > trim enabled for the dom0. Everything seems to have gone smoothly until 
> > > > the
> > > > grub steps. I can't find a grub.cfg file anywhere. The only abnormality 
> > > > to
> > > > my installation is that it's UEFI. So the closest thing I did find to 
> > > > this
> > > > was /boot/efi/EFI/qubes/xen.cfg which had the kernel line referenced in 
> > > > the
> > > > trim guide. However, when I attempt to run grub2-mkconfig -o 
> > > > /boot/efi/EFI/qubes/xen.cfg I get "grub2-mkconfig: command not found" 
> > > > All 
> > > > that is present in the /boot/grub2 folder is a themes folder. I am using
> > > > the main dom0 terminal for all of this.
> > > > 
> > > > Considering that everything boots fine, I'm hesitant to reinstall grub2 
> > > > (I 
> > > > assume it would need to be grub2-efi in this case). Any clue as to 
> > > > what's 
> > > > going on? Thanks
> > > > 
> > > 
> > > I think grub2-mkconfig is not found because you're using UEFI rather than
> > > legacy boot. Are you getting your instructions from here?
> > > 
> > > https://www.qubes-os.org/doc/disk-trim/
> > > 
> > > I think these instructions were written with legacy boot in mind. I'm not 
> > > sure
> > > how to enable TRIM on UEFI (CCing Marek).
> > 
> > Yes, on UEFI install /boot/efi/EFI/qubes/xen.cfg is the right file - you
> > need to edit it directly.
> > 
> > - -- 
> > 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
> > 
> > iQEcBAEBCAAGBQJXrvMNAAoJENuP0xzK19csfqQH/0/P4FV8W2/pZhWaCeXfseqj
> > fw79GDTa5/ExjxSg4eehHDhHHVgG3kaeb0HafPvVnHS/DJuHzCG1Xrs1vyZJlPID
> > oCrH4FaaYQ2Che4L4D/Koh5lNEdEakKOrF7ILbTRN5u8Q4xvdM9KQ/paacCYkCDJ
> > YlYKELzyOZ1wkUvwttPynTANdrMlY797BHkHYHv2TbaMBTjw4EYmIs+VM9MRIWIv
> > Lis1hZn97y1z3ZIQglrQRCDLAmoNJPBsXRdMHjNyA5EeKQPX+fNxsE3/HIoqrIi3
> > 3DHYzKIS/UBDFHOJXj7I3pK311fS1IcUlrbRCXJYCM0gF5A5EkWKxIj0ghV0YTI=
> > =uhvX
> > -END PGP SIGNATURE-
> 
> So I'm editing the right file, that's all and good. Here's what I've done so 
> far: 
> 
> #Find UUID of ssd
> ls /dev/mapper/luks-*
> #Set trim in crypttab
> sudo nano /etc/crypttab
> #Add "allow-discards" at end of entry for ssd with matching UUID
> #Set trim in fstab
> sudo nano /etc/fstab
> #Add "discard" after other flags (like "default") for everything but swap
> sudo nano /etc/lvm/lvm.conf
> #Change "issue_discards" from "0" to "1"
> #Add discard to grub
> sudo nano /boot/efi/EFI/qubes/xen.cfg
> #At the end of the kernel line, add "rd.luks.allow-discards=1"
> #Rebuild initramfs
> sudo dracut -H -f
> ##Check if discard (trim) is enabled:
> lsblk -D
> #OR
> sudo dmsetup table
> 
> Everything above works except that lsblk still shows no trim support so I 
> guess that the rebuilding of grub is an important step in this.

I think dracut by default place output file in
/boot/initramfs-(kernel version), while on UEFI system bootloader loads
it from /boot/efi/EFI/qubes/. Try to copy it there.

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

iQEcBAEBCAAGBQJXr5UPAAoJENuP0xzK19csZGMH/RUxcWpX8666s3xhNptrw7NH
d5bgtzZu9kHWCGILyeLAmnJcW8y36VPMhdWcbyLcakh4WSKqPqIIqJeq+1CAm6bG
SRMTMnMTIjlQsP9ODNGFpS/JaW8tN6qQA4Cg33NSs92mlWIcRDy/ufb7A8S+NxEu
0LssHH7A7y+aY13ZDy9osd3S/cKf1c8v/fQOTcg29QRq8hq0KKaD8J/a/xiCbvth
yc2eknJGOnG8j1Q3v3X6ByaA8StbmlR9LibkmSH7Y8DV3cV7Rmbv/0M7IbSf7V7F
oeehHK+AhFHZLHidQUxd4UkIfI7CKymHyzHIqClYXvdjiZui5ClSvsLmJPR+ovw=
=jCSn
-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/20160813214550.GO9166%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 3.1 - Fedora update check disabled but still check

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, Aug 12, 2016 at 11:45:35PM -0700, Andrew David Wong wrote:
> On 2016-08-12 11:19, johnroberts19...@gmail.com wrote:
> > Hello
> > 
> > i disable all the option auto update options but qubes still pop the
> > update icon in my qubes vm manager.
> > 
> > qubes vm manager "System - Global Settings" Disable dom0 and VM updates
> 
> What is the output of "qubes-set-updates status" (in dom0)?
> 
> Also, check the "Services" tab of the affected TemplateVMs. There should a
> service called "qubes-update-check", and its box should *not* have a check 
> mark.

In fact you should set this on AppVMs you want (or don't want) to check
for updates for its template. Or simpler: it controls whether this
particular VM will check for updates - in case of template-based VM,
those will be updates for its template.

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

iQEcBAEBCAAGBQJXr5ZvAAoJENuP0xzK19csrOAH/0jLfBJTShiPK1sQeW7aiLca
tvEROd7L0eTphfEw/86s/Zg4qmiBM9q6IMrEgfJSRMUNGA1qbEHrw/zy57EWB2kb
ue70XSwb+eHFRENB2+HDlP4zlSo4uxoNMbvcbDKKeT0yDv/sVaVPEYsBl6so5e/i
lLqPzWBSTwiww+qThyQToMhL8KIAmyvLtoQVGfeinhTwm4PYrIm1z3mJ9B+pKdWv
xNd4HAD2e/LhmsUop3cS1+uTrk1g0e9OtG8pK7Lpw9O3zLA3GE31Ux400XgW59AG
Tiqb6OkDwAsDFgTJsHtExgHewTgDNR7/I6y46VmOOVgUyW93v+ywXN7C9R9Iq0k=
=hgVK
-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/20160813215142.GP9166%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Manual https://www.qubes-os.org/doc/templates/archlinux/ does not work.

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Aug 13, 2016 at 05:30:51AM -0700, lol lol wrote:
> суббота, 13 августа 2016 г., 4:04:57 UTC+3 пользователь RSS написал:
> > On Fri, 12 Aug 2016 07:56:23 -0700 (PDT)
> > lol lol  wrote:
> > 
> > > Hi guys, it doesn't work on a step 9 after compiling.
> > > 
> > > /home/user/qubes-src/vmm-xenPKGBUILD: line 49: autoreconf: command
> > > not found ==> ERROR: A failure occurred in build().  
> > > Aborting...
> > > /home/user/qubes-builder/qubes-src/builder-archlinux/Makefile.archlinux:120:
> > > recipe for target 'dist-package' failed make[2]:***[dist-package]
> > > Error 2 Makefile.generic:139: recipe for target 'packages' failed
> > > make[1]: *** [packages] Error 1
> > > Makefile:208: recipe for targert 'vmm-xen-vm' failed
> > > make: *** [vmm-xen-vm] Error 1 
> > > 
> > > --
> > > 
> > > So, i can't install archlinux template step by step :( Script doesn't
> > > work. Please fix it.
> > 
> > Step 9 from where?
> > 
> > I also am stuck on an Arch build, I wonder if it might be the same root
> > cause?
> > 
> > $ make get-sources
> > 
> > --> Downloading additional sources for vmm-xen...
> > Makefile:77: recipe for target 'xen-4.6.1.tar.gz' failed
> > make[1]: *** [xen-4.6.1.tar.gz] Error 4
> > Makefile:188: recipe for target 'vmm-xen.get-sources-extra' failed
> > make: *** [vmm-xen.get-sources-extra] Error 2
> > 
> > And then again:
> > 
> > $ make get-sources-extra 
> > --> Downloading additional sources for vmm-xen...
> > Wrong signature on xen-4.6.1.tar.gz.UNTRUSTED!
> > Makefile:77: recipe for target 'xen-4.6.1.tar.gz' failed
> > make[1]: *** [xen-4.6.1.tar.gz] Error 1
> > Makefile:188: recipe for target 'vmm-xen.get-sources-extra' failed
> > make: *** [vmm-xen.get-sources-extra] Error 2
> 
> 
> Hi, again. Here is full log.   "Step 9" meaning install  'make qubes-vm' 
> command :) 
> 
> [root@development qubes-builder]# make qubes-vm 

   ^
This is the problem.
You should call it from normal user, it will use sudo for those (few)
things that require root. Now you probably have files ownership screwed
up... The easiest way to fix is to remove and start again.

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

iQEcBAEBCAAGBQJXr5iVAAoJENuP0xzK19csmQMIAIdPCjUi/tw0u0khOKzZrzzk
GnTbJP9waGtQUZMXOKjUn1shNupH+aIRwLlzrMlKGkmlAZIMPVTYIMk/UkGYeWml
/BVuM78Q0NxM8iVNeCPnGDj3gfEUpFFa0TZERocv3JAeGIjWW1EPcnTWHmvEjkT5
gXi++r4XlUIkXSPc/ocX3G19S1QPGZ2VrZPlqQIDo/dpULKBvXr2YpnuBffqkLiY
1gsvnn4I4CPjSEPrQnPzbmNu0kMVtIaAUEloeFfBz9yDetcFKsd+139cSc6wxR5l
xJ/rns2U3L5iXFv33qQPhHwn1TL0bgewP0Zlj4meEncqTAZXwNHF6WPEvMvwey8=
=E2RK
-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/20160813220053.GQ9166%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Unable to install R3.1 / media check failure

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Apr 25, 2016 at 11:28:52AM -0500, Cory Nelson wrote:
> On Mon, Apr 25, 2016 at 11:11 AM,   wrote:
> > On Monday, April 25, 2016 at 9:16:12 AM UTC-4, dbo...@gmail.com wrote:
> >> Thanks Raah... Rawrite had the same issue for me.
> >
> > then maybe you need a diff brand usb stick,  or you have to change your 
> > bios mode to legacy, or  also try diff usb 2.0 ports on your computer.
> 
> There appears to be something unique about the Qubes ISO that causes
> these tools to fail when writing from Windows. I wonder if Windows
> reads the partition table and tries to correct something it thinks is
> an error.
> 
> For me, multiple PCs (one Win8.1, one Win10), multiple drives (one usb
> 3.1, one usb 3, one usb 2), all failed when written from Windows, but
> then succeeded in Linux.

Yes, Windows do break installation image:
https://github.com/QubesOS/qubes-issues/issues/2051
Some excerpt:

the core of the issue is that the default modern Windows behaviour is
that, whenever you plug a disk with a file system that Windows can
recognize, it creates a System Volume Information\ directory on that
file system, that contains a single file called IndexerVolumeGuid.

So the problem is that, after a Windows user writes the Qubes image in
dd mode, the FAT32 ESP gets mounted by Windows, which results in the
creation of the directory and file above.

Of course, this means that the FAT32 index gets modified and fails the
byte comparison...

As you can see in the issue history, we're trying to prevent this by
providing those files in installation image. It is in R3.2-rc images,
but not R3.1. So hopefully should be better in new release.
Unless Windows create the other file ("WPSettings.dat")...


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

iQEcBAEBCAAGBQJXr5n0AAoJENuP0xzK19csbVQH/3pFl8ZuWxtwtLMTQRWBmGlo
IoRc0v6tT2m4BGYm2CAeApLSl7BjFf6MfpzvFbASNxJYLGPM4Eid2lXVpSbVD5CN
8PzDBsMe2hXToidLr3WWN2D9Eb0B6lbDUha+EsB07X8K9kTiMjiIRydVGs3Tygxg
9+JngNfWl7MGP6NkgdH7Y9B6cw8hA/5GYEnVunHYwRI6ZQKyiUrR7YTCBbVuWAjW
Mbz6PHun3O5CfHWcY5G1JljgKLxsNR2y9H/zVTYPomicOIYviqgZwGgB/gias7Dm
kDjyqL+5Sbf+2nSy6GCckepBvio7y4LmGCU8xOyqXrkZDZSW2tezKTsIQLWIEGQ=
=PrvF
-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/20160813220644.GR9166%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Tool to record Whonix / Tor browsing history..?

[Qubed One]

Manuel Amador (Rudd-O):
> On 08/12/2016 01:39 PM, neilhard...@gmail.com wrote:
>> I would like to be able to do something like:
>>
>> 1. Use Whonix/Tor as a disposable VM
>>
>> 2. Record browsing history using an external software
>>
>> One of the reasons I don't use Tor that much (other than slow speed, 
>> captchas etc) is because I actually want to have a record of the websites I 
>> have visited.
>>
>> We know that it could be risky to have the Tor browser itself record 
>> history, if it gets hacked.
>>
>> But to have some tool running outside of the VM would be useful..
> 
> For the same reason that attackers outside the VM can't see what you're
> visiting, you yourself won't be able to see it either.
> 
> What you want is not doable.
> 
> If you want to have a record of sites you visit, then tell the Tor
> Browser to record your browsing history, and hope that works for you.
> 



You could also simply fire up a text editor (gedit etc) in another VM
and record what you want that way. Trying to automate the process would
be a bad idea for security, especially if using Whonix as a dispVM.

-- 
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/28f04dba-7a03-9468-cf85-ba68ea502216%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Customizing DisposableVM Menu

[dfoxfranke]

How can I customize what applications appear under the DisposableVM menu? I 
want to add a menu item to launch chromium; I've already installed chromium in 
the debian-8 template and then run "qvm-create-default-dvm debian-8". I've 
tried using the Qubes VM Manager to edit the VM settings for debian-8-dvm and 
add chromium there, but this had no effect. I've also tried adding chromium to 
the "Template: debian-8" menu before running qvm-create-defeault-dvm; this was 
likewise ineffective.

-- 
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/4b890be6-ae9b-4726-9d24-32544c0dc186%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes VM Manager: Organize?

[eliwu]

> don't
> yet know what the new system will look like, so I can't say whether a
> folder-based system (like the app menu) will make sense, but something like
> that could be a good idea. I've added this suggestion as a comment with a link
> back to this thread.

Thanks.  

If you do make it, please try to remember to try to be intuitive... Copy shit 
that everyone knows..  (Click on triangle to reveal subdirectory or something 
that runs through most OS guis).  Not trying to be rude or imply that qubes is 
overly complicated.. It just is by its very nature.  

I am not sure about other people, but I connect to different AppVM's via 
different VPN locales (of the same VPN provider).  Perfect?  No, but it saves 
money, and I bet a bunch of users do something like this.  Most VPN's give you 
20+ different locales to connect to (London, Paris, Sydney, etc..)  It is 
desirable (when not using tor at least) to set up different ProxyVm's for each 
AppVM that you use, even if you are using the same vpn company.  
If I am not the only one out there doing that, it would be really helpful to be 
able to visualize which appvm connects to which proxyvm (maybe by shading 
background colour or a dotted line denoting parents/children/siblings when you 
scroll over the app/proxy to indicate relationships?).  

And I probably just came up with an unintuitive idea.  But if it's intuitive to 
you too, maybe it would be for more people.  Maybe a mouse-hover would bring up 
a small explanation of 'taint/relationships with other appvm's that are using 
the same ip?  

My couple nunsense.  

-- 
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/07c15eea-1e73-4d87-9242-43195eb9a6b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 3.1 - Fedora update check disabled but still check

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-08-13 14:51, Marek Marczykowski-Górecki wrote:
> On Fri, Aug 12, 2016 at 11:45:35PM -0700, Andrew David Wong wrote:
>> On 2016-08-12 11:19, johnroberts19...@gmail.com wrote:
>>> Hello
>>> 
>>> i disable all the option auto update options but qubes still pop the 
>>> update icon in my qubes vm manager.
>>> 
>>> qubes vm manager "System - Global Settings" Disable dom0 and VM
>>> updates
> 
>> What is the output of "qubes-set-updates status" (in dom0)?
> 
>> Also, check the "Services" tab of the affected TemplateVMs. There should
>> a service called "qubes-update-check", and its box should *not* have a
>> check mark.
> 
> In fact you should set this on AppVMs you want (or don't want) to check for
> updates for its template. Or simpler: it controls whether this particular
> VM will check for updates - in case of template-based VM, those will be
> updates for its template.
> 

Ah, thanks for the correction, Marek. (It turns out I have that service
disabled in both my TemplateVMs and TemplateBasedVMs, but I had only looked at
the former.)

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

iQIcBAEBCgAGBQJXr+a+AAoJENtN07w5UDAwpMYP/1i99JW+EQLTsVCe4W12P1Nt
IXa/7861mRUXfrRB6rTe9ekW3IikbPTx9mqMR78gm3zry7fwUREidJ0nMfoLk05H
kzV2/wEzElXS5atSWm5XY+IrVyABUJhu9qsc/BQuaHG3EKYPp+cLXGnS30Ce/MAE
7wH5OqlnRwpDzIDfBk/s/ow5l2KrK0AhucwcaT21WNdVZCyMbXnCrbwP6rlu0sLH
Vsz056ezQyvqeDYV7sB4a0FTa1ZgGs+IEg/QpomlFi+6NeipkDKh7E5Pdk21hIFf
0zfMhTYAkwzI3eXaTrOylgbrKgkn2Ulpd6DzhDZ/uO2ZpE/6n1dIeQIx9hAc0Yn8
Tf0af+PNsd89CEtAv2LJRj1XiZvT3XHRC3+Il+sicxWWHg2yKSaZq6xWgPHfMPUz
lWIjRl7uCERRNE8gDNU/Nz62VHQsYAcf+XKLkHYDQCfo7G/w+IQuHYEX0ywDCPx/
wXrARNSdz/VOnO438oo0lmAe82ic5elwOC99l5Kkwb1ZMtM5Ic5zkJev7TBE/f2j
dpjiyyBNnBQYYph95No4gC2uFwj1q3PtMvdhteiJKV5hd0XG4RBcmGeeW1DljRkF
RVzJwxsjDTHl2OBqyElFnAyxq9U/2AyXPigdvIuy5rDlHWoPsW/e/EY+8nV7or4w
6D/oHZKQ4vOBJyx98bzP
=s4j/
-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/2a8e197c-a299-3e50-ea92-aadd4aa3feba%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Customizing DisposableVM Menu

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-08-13 18:19, dfoxfra...@gmail.com wrote:
> How can I customize what applications appear under the DisposableVM menu?
> I want to add a menu item to launch chromium; I've already installed
> chromium in the debian-8 template and then run "qvm-create-default-dvm
> debian-8". I've tried using the Qubes VM Manager to edit the VM settings
> for debian-8-dvm and add chromium there, but this had no effect. I've also
> tried adding chromium to the "Template: debian-8" menu before running
> qvm-create-defeault-dvm; this was likewise ineffective.
> 

Which Qubes release and desktop environment are you using? For example, on
R3.1 with KDE, you can create your own menu entries in the DispVM menu manually:

1. Right-click the "Application Launcher Menu" (AKA "Start Menu")
2. Click "Edit Applications..."
3. Select the "DisposableVM" menu.
4. Click "New Item".
5. Assign the name, icon, description (if any), and comment (if any) as you see
   fit.
6. In the "Command" box, add your command. For example:

sh -c 'echo chromium | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 \
DEFAULT red'

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

iQIcBAEBCgAGBQJXr+iyAAoJENtN07w5UDAwoDQP/37KvdjoGQJYNodJEx8fX2Hu
JcRGdYgmSVY1ONiCAfAdT7TQwrtb+d3YAmrniGLxt9U993bZptQIOxe8/51qZFQi
SEzsVxViE/Kp6a67Jf8riuwoJmcPSEOU8rhDNsffuBcq2sh+HGVWn1ykBeFKZfgO
QmW3C9DcIM9AuOyL7Roi495ApkbOsLLXa0ugByabvIGmOD+huAW0V8FAvWeqwx0/
rm5a8TngRzU85js284HoCzNAZDZ3MiM1t5j8I0LYFNBUokFGj2l2wiS2TK9f7BNn
6VUtC4XRlrliEDtULJmj5PEBDwz/EEB/Kair5tPvIcAI+rUeLoWAlTjMuiPY4O5q
jM4Mp3GYztiCEkKfySucwJCYsY4Y5tU3Wb9ON+IS+Qm3+fR50eDlDUQrczWZbsCR
Ip2k9ljf/+QUamSD0jdty6XDDDWG7SFXss4XENM9xwgiuc1iUOlq6/MwW8pUGkOt
3MbhmwQqToqTgjjPIL0j4rjY8Shp7vwD+P3iGLvpy6bZovtggSwmPCbU0um7AR8s
om3qR83r0yn+75b+nQCcROU73EZ+js4lGOvK9Vp4OrgsSBPkc/DLeRmhLoIiJ00U
Bu/z2gU8khyqa2B3/VEkHsppbdNM1cWZnPncI/BAWuFlKq7nECTcMKBeuvayOIix
mWRHWnn2KiGPXlL3O9n4
=KGJ2
-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/359c2112-9ecd-29fb-3287-52ef7e54140b%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Customizing DisposableVM Menu

[Daniel Franke]

/13/16, Andrew David Wong  wrote:
> Which Qubes release and desktop environment are you using?

I'm on 3.2-rc2 under Xfce.

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

[qubes-users] Thinkpwn?

[eliwu]

Maybe this is a dumb question, but I can't seem to find any threads here on 
thinkpwn on the qubes group. 
Should we be turning off our thinkpwn'd computers off until there are bios 
updates to correct thinkpwn?  
Specifically, if we have...
single boot qubes?
dual boot with some other os (windows / osx)?

Lastly, perhaps more importantly, once a computer has been thinkpwn'd, is there 
any way to check?  
In other words, is it no longer safe to buy a used computer with which to run 
Qubes off of (in case it has been breached by thinkpwn)?  
>From my understanding, even if you swap out the hard drive and change the os, 
>the malicious software survives.  That is huge, no?  

There is a laymen's guide on github.. I am sure that every first-world nation 
(and at the very least the cryptolocker people--they made millions in two 
months last year) have ten to twenty people working on honing out the exploit.  

Toss the old computers, or am I being too paranoid?  

-- 
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/0997e10d-87de-4261-929e-bc1811a13e4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Assigning Drivers Help

[david . vorick]

I'm trying to create a Windows HVM and assign drivers to it. I've read that you 
can bypass issues such as no audio support and no GPU support by assigning the 
GPU and the audio to the HVM. (and using separate devices in dom0). We do have 
2 GPUs.

I've created a vm 'win7', and installed windows on it. Later, I tried to assign 
some devices to it. When starting the vm, I get the error "Requested operation 
is not valid: PCI device :01:00.0 is in use by driver xenlight, domain win7"

But... win7 is not running, and win7 is the vm that I'm trying to start. Anyone 
have any ideas?

-- 
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/c9b4a623-5f6f-45b7-ae20-3dd836f78602%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Unable to install R3.1 / media check failure

[Benson Muite]

On 8/12/16 9:24 PM, Gabriele Bini wrote:
> Hello,
> I have exactly the same problem. This is what I did:
> 1. I downloaded the Qubes-R3.1-x86_64.iso ISO from the Torrent.
> 2. I checked the signature and the hash values in the DIGEST file (I checked 
> just the hash values in a second PC) and everything was fine.
> 3. I used dd to copy the ISO in a USB flash drive (Sony 8Gb)
> 4. When I booted from the USB I tried the “Verify and Install” option but, 
> exactly at 4,8% (as for Cory Nelson) the check failed. There was a message of 
> this type (copied by hand):
> Failed to start media check on /dev/sdc
> See 'systemctl status checkisomd5@-dev-sdc.service' and 'journal.ctl-xn'  for 
> details
> 5. I couldn't check anything because the system was halted
> 
> What can I do?
> Thank you in advance!
> 

Buringn and iso to a DVD and installing using the DVD tends to be more
reliable than USB stick.

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