Re: [qubes-users] Custom initramfs
> while initially I thought it would be interesting to try, the only situation > when yubikey could actually improve security is having to boot a Qubes PC > under unavoidable surveilance. came to the same conclusion - probably not worth the security tradeoff... Perhaps one can implement a 2FA solution for FDE using something like paperkey? It would still be the 'someone peeks over my shoulder in a cafe' kind of scenario, but without the USB compromise -- 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/a62b822e-04b8-04b6-42e0-93c4928fb0b6%40raphael-susewind.de. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Building Archlinux Template Error
On Thursday, August 25, 2016 at 1:41:51 PM UTC, richar...@gmail.com wrote: > On Wednesday, August 24, 2016 at 3:15:09 PM UTC+1, Foppe de Haan wrote: > > On Wednesday, August 24, 2016 at 4:14:12 PM UTC+2, Foppe de Haan wrote: > > > On Thursday, August 18, 2016 at 6:40:42 PM UTC+2, Jovan Miloskovski wrote: > > > > Hi, > > > > I'm really learning all of this template building stuff right now but > > > > I've stumbled upon an error in the Archlinux qubes template building > > > > process I can't find a solution for. > > > > Here is the segment of the error in my terminal output: > > > > > > > > -> Building vmm-xen (archlinux) for archlinux vm (logfile: > > > > build-logs/vmm-xen-vm-archlinux.log) > > > > --> build failed! > > > > gcc -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe > > > > -fstack-protector-strong -O2 -fomit-frame-pointer -m64 > > > > -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes > > > > -Wdeclaration-after-statement -Wno-unused-but-set-variable > > > > -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -m64 > > > > -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes > > > > -Wdeclaration-after-statement -Wno-unused-but-set-variable > > > > -Wno-unused-local-typedefs -D__XEN_TOOLS__ -MMD -MF > > > > .subdirs-install.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -O2 > > > > -fomit-frame-pointer -m64 -fno-strict-aliasing -std=gnu99 -Wall > > > > -Wstrict-prototypes -Wdeclaration-after-statement > > > > -Wno-unused-but-set-variable -Wno-unused-local-typedefs > > > > -D__XEN_TOOLS__ -MMD -MF .subdir-install-libxl.d -D_LARGEFILE_SOURCE > > > > -D_LARGEFILE64_SOURCE -O2 -fomit-frame-pointer -m64 > > > > -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes > > > > -Wdeclaration-after-statement -Wno-unused-but-set-variable > > > > -Wno-unused-local-typedefs -D__XEN_TOOLS__ -MMD -MF .libxl_create.o.d > > > > -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Werror > > > > -Wno-format-zero-length -Wmissing-declarations > > > > -Wno-declaration-after-statement -Wformat-nonliteral -I. -fPIC -pthread > > > > -I/home/user/qubes-src/vmm-xen/src/xen-4.6.1/tools/libxl/../../tools/libxc/include > > > > > > > > -I/home/user/qubes-src/vmm-xen/src/xen-4.6.1/tools/libxl/../../tools/include > > > > > > > > -I/home/user/qubes-src/vmm-xen/src/xen-4.6.1/tools/libxl/../../tools/libxc/include > > > > > > > > -I/home/user/qubes-src/vmm-xen/src/xen-4.6.1/tools/libxl/../../tools/include > > > > > > > > -I/home/user/qubes-src/vmm-xen/src/xen-4.6.1/tools/libxl/../../tools/xenstore/include > > > > > > > > -I/home/user/qubes-src/vmm-xen/src/xen-4.6.1/tools/libxl/../../tools/include > > > >-Wshadow -include > > > > /home/user/qubes-src/vmm-xen/src/xen-4.6.1/tools/libxl/../../tools/config.h > > > > -c -o libxl_create.o libxl_create.c > > > > gcc -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe > > > > -fstack-protector-strong -O2 -fomit-frame-pointer -m64 > > > > -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes > > > > -Wdeclaration-after-statement -Wno-unused-but-set-variable > > > > -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -m64 > > > > -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes > > > > -Wdeclaration-after-statement -Wno-unused-but-set-variable > > > > -Wno-unused-local-typedefs -D__XEN_TOOLS__ -MMD -MF > > > > .subdirs-install.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -O2 > > > > -fomit-frame-pointer -m64 -fno-strict-aliasing -std=gnu99 -Wall > > > > -Wstrict-prototypes -Wdeclaration-after-statement > > > > -Wno-unused-but-set-variable -Wno-unused-local-typedefs > > > > -D__XEN_TOOLS__ -MMD -MF .subdir-install-libxl.d -D_LARGEFILE_SOURCE > > > > -D_LARGEFILE64_SOURCE -O2 -fomit-frame-pointer -m64 > > > > -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes > > > > -Wdeclaration-after-statement -Wno-unused-but-set-variable > > > > -Wno-unused-local-typedefs -D__XEN_TOOLS__ -MMD -MF .libxl_dm.o.d > > > > -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Werror > > > > -Wno-format-zero-length -Wmissing-declarations > > > > -Wno-declaration-after-statement -Wformat-nonliteral -I. -fPIC -pthread > > > > -I/home/user/qubes-src/vmm-xen/src/xen-4.6.1/tools/libxl/../../tools/libxc/include > > > > > > > > -I/home/user/qubes-src/vmm-xen/src/xen-4.6.1/tools/libxl/../../tools/include > > > > > > > > -I/home/user/qubes-src/vmm-xen/src/xen-4.6.1/tools/libxl/../../tools/libxc/include > > > > > > > > -I/home/user/qubes-src/vmm-xen/src/xen-4.6.1/tools/libxl/../../tools/include > > > > > > > > -I/home/user/qubes-src/vmm-xen/src/xen-4.6.1/tools/libxl/../../tools/xenstore/include > > > > > > > > -I/home/user/qubes-src/vmm-xen/src/xen-4.6.1/tools/libxl/../../tools/include > > > >-Wshadow -include > > > > /home/user/qubes-src/vmm-xen/src/xen-4.6.1/tools/libxl/../../tools/config.h > > > > -c -o libxl_dm.o libxl_dm.c > > > > gcc -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic
[qubes-users] Re: Building Archlinux Template Error
> I have built Arch Linux (and Ubuntu) templates successfully (eventually!), > but they won't start as the error message: "The Dom0 GUI daemon do not > support protocol 1:1, requested by the VM" appears. It looks like the > templates are being built against Qubes 3.2, whereas I'm on 3.1 here. I succesfully built the Archlinux template with the xen-4.7 branches being set on vmm-xen and core-vchan-xen with a few tweaks in the series.conf file of vmm-xen but now I'm getting the same error as Richard. I am on Qubes R3.1. I will keep you updated with my progress (if there is any) until I succesfully get this template running in Qubes R3.1. I will look into what is causing the error. If anyone knows what is causing the error, then please post here. -- 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/0befc0bb-5088-4521-9c08-177c57f9adc3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] QVM Backup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-08-28 18:04, Drew White wrote: > Hi folks, > > Just wondering.. > > I've looked at the backup data for the XML file and it contains > ALL of the guests on the machine, not just the one I'm backing up. > > Is there any particular reason for this? Is it just the way that > it does the backup for 1 guest? > Yes, that's just the way it does the backup, even for a single guest. However, there are plans to implement a qvm-export-vm tool that will allow you to export a single guest without exposing metadata about other guests: https://github.com/QubesOS/qubes-issues/issues/1747 (The comments on this issue explain why the current qvm-backup tool doesn't already do this.) - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJXw8D3AAoJENtN07w5UDAwQTQQAKcfKGoycWhhi3wGfm3PY0oN Wq8fGUpykjjGN7gLP1LbTF1NbAB7gJBpvhuUu8t84QBGycv34SvD8dJ2XS0irPSG AAyRmLzCkTKUUtcJTb0/PtfvNOAzW14EoUo28+Xro8DbayZSWAcU8I280yFx42/o Hct4vYTz1pR5BClKRRO6U4icSFcihHuqel5aKJngoRIFE5G6+q5jxphPr2yjxcIq q+8WyOv4D2eVCFmbFE8up11yNtnJdYSsvZHUVwFAwtqQVwrcCshcXTnfLkb/QJ5z qe6ffhvKqVhLWzmZfCdxrZangETXsYYScpBc7lJfIfPdBUIYW3U3kDSiS/5WFB5b OjQKs0vkW5r/ghvaLY0Y98Xe4aYQWtFS8kJyyxqijVHdqCtu8f+EZbQbKoLMwVdt c+WLbgwDQPDFTQzYxIhXRvuHYOaBerGwkczMl5mfo0HtSijtvOUIlHVNrYKi7nNJ ph5pixenVdx/mWjTWM31OnjCfBCADD4drMatvf3UDnmJzxt5qTljtCFy51NCuHzu NdedHwrcmXBrmwhemb/AsvKWiq6Nz6y5Upiln9HDbPZhsnUYN7Kc4BqRMX/UOg2y Kqj9qrebIyq2zgoo1VR8sux5/BBKFHAti+h04SD6AK25qmyo4f/0Bz8Vb6Uxj8o9 FopgGOsAv5617Haw4ujY =VuS7 -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/a7fe0216-c070-2e06-97ce-68ed7100f21e%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Network selection
On 08/28/2016 09:58 AM, Jon Solworth wrote: NetworkManager apparently selects which network to connect to based on most recently connected network. This policy is really unfortunate. At my university, I connect to my lab's WiFi and when I'm out of range to my University's WiFi. My notebook can also see eduroam, an inter-University roaming facility. But these networks have different policies, in regards to firewall and bandwidth limits. I want to prioritize access points to lab first, university second, and eduroam third. Is there a way to do this? Jon You could edit your connections so that they all have "Automatically connect..." disabled. Then you can easily choose which AP to connect to based on your venue. You could also write a script using 'nmcli' to select APs based on your preferences. Chris -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ca8b1934-f448-186e-cce5-5bbe30fdd7ac%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Multi-drive computers installation
Any new information on this issue? Is there any way that it will be resolved or available for use for installation? -- 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/1c1ae4cc-27a3-49e8-9271-e21ececd32d0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] QVM Backup
Hi folks, Just wondering.. I've looked at the backup data for the XML file and it contains ALL of the guests on the machine, not just the one I'm backing up. Is there any particular reason for this? Is it just the way that it does the backup for 1 guest? -- 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/6a1b8f11-08de-47a0-a9fa-883bfda5bcdb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: OSX
On Sunday, 28 August 2016 06:56:34 UTC+10, johny...@sigaint.org wrote: > Hey, does anyone have any luck with getting any form of OSX to fire up > under Qubes? > > After several other failures, I was able to get some iPC ISO build to get > to a certain point in an HVM, but the mouse didn't work, so I couldn't do > much, and I couldn't figure out how to get it to any kind of command line > (single user or otherwise). > > Not looking for the full OSX experience, just want to fsck_hfs some legacy > drives that are too cranky for Linux. Get a successful fsck done, and > turn off Journaling so Linux is a bit friendlier with them, until I can > copy/retire them. > > Anyone? > > JJ There is a patch in this forum for Qubes 3.0. All you have to do is compile it in. Other than that, they won't put the availability of OSX under Qubes because they say it breaks the lisencing agreement, even though it doesn't really. But OSX86 might be an option. like JJ said. I don't know much about it, and Qubes won't make an integration kit for it because they said they won't, so you can't have shared clipboard or seamless mode or anything like that. -- 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/d2abc8eb-d83e-4b58-95c4-ad178e0dc480%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Weird network access issues
On Saturday, 27 August 2016 07:23:33 UTC+10, angelo "angico" costa wrote: > Hi, all! > > I'm experiencing some weird network access issues. I'm using Qubes 3.1. > > After logging in to the system, sys-net, sys-firewall and sys-whonix start as > expected, and network access is normally available. I can use apps such as > OwnCloud, qBittorrent, Firefox and others to connect to several internet > services and they all work fine. But suddenly, and I just cannot specify > when, the apps start to fail connecting. One such app that most catches my > attention with respect to the problem is OwnCloud, which reports connection > failure -- though other devices such as an Android tablet or even another > notebook running Debian, tell me Internet access is absolutely normal, > including access to my OwnCloud server. > > I've already tried restarting the VMs related to network connection -- > sys-net and sys-firewall -- but the problem persists, and it's happening with > two different notebooks -- an Acer Aspire with Intel Core i7, 10GB RAM, 1TB > HD and an unbranded one with equal CPU. 8GB RAM, and 640GB HD. > > Does anybody have experienced such issues? Does anybody have any hint on what > may be the cause of those issues and on how I can solve them? > > TIA and best regards to you all, > > Angico. According to what you are saying it sounds like it's not an issue with Qubes, but with your connection. You say you have the issue from Android Tablet, a Notebook running Debian, and your Qubes PC. If not all 3 are running Qubes, then it isn't a Qubes issue. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3828fe56-dddc-479c-98a8-95e4dc1e643c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Actual Display??
On Saturday, 27 August 2016 04:36:52 UTC+10, grzegorz@gmail.com wrote: > Run the Vm in debug mode and disable seamless integration. I wish to access the display, not run in debug mode, that completely defeats the purpose. I need to find out if it's sitting at the login screen or not. -- 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/cbbc665c-a553-4fc6-9012-be0e119d6a71%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] installing Signal on Qubes mini-HOWTO
On Wednesday, August 24, 2016 at 3:43:13 PM UTC-7, pixel fairy wrote: > just to clarify, this method will soon stop working because chrome apps are > being killed, only chromeos (and probably chromiumos) will be able to run it. this might fix that. https://github.com/koush/electron-chrome -- 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/f64eb3c6-7a6f-4e1f-8b95-b28133b486b8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: OSX
> Hey, does anyone have any luck with getting any form of OSX to fire up > under Qubes? > > After several other failures, I was able to get some iPC ISO build to get > to a certain point in an HVM, but the mouse didn't work, so I couldn't do > much, and I couldn't figure out how to get it to any kind of command line > (single user or otherwise). > > Not looking for the full OSX experience, just want to fsck_hfs some legacy > drives that are too cranky for Linux. Get a successful fsck done, and > turn off Journaling so Linux is a bit friendlier with them, until I can > copy/retire them. > > Anyone? I was able to get what I needed done with a single-user boot of an osx86 build. I might make it a bit of a fun side-project to play with osx86 under Qubes, though, and will obviously report back here any results. Cheers. 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/736822dbddcf9d60992435684c1dd153.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes VM Manager Suggestions
> But I'll Joanna's page a more detailed read when I'm a bit more refreshed. Sorry, not just "Joanna's" page; on a quick scan, I see you contributed to it significantly as well. I very much look forward to giving it a proper read and review tomorrow. Cheers, and thanks, Andrew. :) 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/ff7eefd239a9541aaed1d8a4be7b927e.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes VM Manager Suggestions
> Thanks for the suggestions. Our goal for Qubes 4.0 is to "decmopose" > the current Qubes Manager by integrating its functions more seamlessly > into the desktop environment: > > https://github.com/QubesOS/qubes-issues/issues/2132 > > We hope that this approach will take care of the kinds of issues that > you and others have pointed out regarding the current Qubes Manager. Hm. That's interesting. I'm not 100% sure I comprehend what "decomposition" means here. I'm not sure splitting stuff out into different parts of the window manager makes things less confusing, or more confusing. And potentially harder to maintain. I hate trying to hunt around and find things when they could all be in one place. In the past when I've seen stuff like that, it means a lot more work finding stuff. I like what Qubes does, and I think the Qubes VM Manager sums it the state of things pretty nicely, currently. I really don't have a problem with it and the way it's tied to main Qubes menu. But I'll Joanna's page a more detailed read when I'm a bit more refreshed. Thanks. :) 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/441974ba840cb5033821e153a452e3ea.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes VM Manager Suggestions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-08-28 15:22, johnyju...@sigaint.org wrote: > These are fairly minor cosmetic issues, and if I ever get some of > my current struggles under control, I'll submit patches instead of > suggestions. :) > > I think the Qubes folks work on the VM Manager (and install > process, which is amazing) has made major strides in making the > system more accessible to all. Which is, in turn, key to making a > secure work/personal computing environment available to the > oppressed, or those who are simply security conscious. > > In that spirit, here are a few minor things I'd like to see tweaked > in the VM Manager: > > 1) Column resizing. I like to toss my windows into one of four > "quadrants" on the screen. xfce shortcuts make that pretty easy to > do. But it'd be nice to see the whole VM Manager, not truncated, > with the fields I want to see, each given the column size they > deserve. > > 2) Current CPU % takes up wa to much space for a simple > two-digti number. You don't need a bar graph to go along with it. > > 3) The CPU graph itself could easily add the current CPU % to it > (centered, perhaps), without compromising the display. > > 4) Custom ordering. I like to stack my VM's in the order I want > them. (Maybe even nested. :P) Currently, I use my own coloring > scheme to achieve that, and sort by color. But it'd be nice if > there were better support for arranging the multitud of VM's. > > (Just FYI, if you sort by color, the order is > red-orange-yellow-green-gray-blue-purple-black. I usually sort by > color, and use red for system stuff; orange for dicey stuff with no > firewall protection; green for stuff that's nicely protected by Tor > or a VPN; blue for stuff that has *no* network and is just a lot > safer; black for templates; grey/purple for VM's I either no longer > trust or no longer use). > > 5) It'd also be nice to be able to hide certain VM's (or certain > colors, perhaps) no longer of interest, but that you want to keep > around for reference. (Like the "internal" flag, but separate). > The color mechanism is a great cue to the level of security you've > flagged certain VM's to be, so that might be a good way to > hide/show certain classes of VM's. > > 6) It'd be handy to have the application list for a VM (as you see > on the main Qubes menu) be accessible when you right-click on a VM. > Right-click on WorkVM, choose Firefox, kinda thing. (There's a > "run command", but having the configured app list show up would be > a lot handier.) > Thanks for the suggestions. Our goal for Qubes 4.0 is to "decmopose" the current Qubes Manager by integrating its functions more seamlessly into the desktop environment: https://github.com/QubesOS/qubes-issues/issues/2132 We hope that this approach will take care of the kinds of issues that you and others have pointed out regarding the current Qubes Manager. > 7) Are there any thoughts to support "hibernation" in VM's? (Not > just a pause, but something that could survive a reboot?) "xl > save/restore" does it, and I've had a bit of success with that, but > I think it freaked out the VM Manager on a couple of occasions. > :P > > Especially when memory is tight, it'd be nice to be able to > hibernate a less-critical VM or two, and fire up something more > important. > Interesting suggestion. Tracking it here: https://github.com/QubesOS/qubes-issues/issues/2273 - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJXw2tTAAoJENtN07w5UDAwB/cQALPSirzFd8K7GS6k0N4x/I27 wyGeHaHL5JYZ6wQDvIy1c5MN/REdJQ1YgK0qWv/u8jCTNTu32F5YnqUOJXPdA3y+ yZ0d8xreJr5Pb50njxlT8C0yV8j+pUavJMkoV20Izg1pwUrp0bNY+w+xB0CiQfW8 blZnbclTIp9W7Y7RCUI4osiav2CpizOJ+D2PgV/0+hDzJBMryTf5vVvjfyHYx0oG vr1wQ0dKnFo15zFs197MEYgSlZCOOoc87PXURdMgB0Y05P3OmTFRKr2Hp2P0nyXd GklW4hl+fSbY0ooVZNLFMJhfa7iVHBIkVLaBH7zsaz9paCDVE/B6oGRC9E+MebWw yD8EgW5UzgNGxidM/zVVgIdtvcI46F5CvuRPGgSv4fz+kkdg0i+4kh4axYSjH86F xuwDTlbrx/9x/c697AiwdnMHxzIAS0llQO9DsQrvlMIk+9vknHOEqo3GviuTW6hw uo4NmcTy/zzrnOrVPt5Rtjp3yQIqyH4Xj2Opd3nLn/0hxUAWd92QBAF13a4nHaqp tzXNjD28aRUgebH73jCqUURGECoaVQgbOPK9ScCiEr0CQ6sXDXzJzD37c2mukTJP HPsmBDo219tEmxcUn0G/vlmoO1f11n+Vzxinu3xCsiKM3deDjD0Pf3nB7wQPoCle swixreZgy/wmGnD6fWY0 =Zkze -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/77cf2b79-5062-40da-5fa8-9c544fb2b2b1%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Security Best Practice: Cache web passwords in custom VM's or not?
> On Saturday, August 27, 2016 at 1:50:22 PM UTC-7, johny...@sigaint.org > wrote: >> BTW, keepassx rocks. I'm working on some scripts to make it a little >> less >> painful with all the Ctrl-Alt-C and Ctrl-Alt-V'ing (which also conflicts >> with the standard konsole paste shortcuts). > > I have no problem with the special cut/paste. Doesn't mean I don't screw > it up on occasion, but I do like the assurance of having to do the step > > Actually you betray yourself with the correct solution above; Speaking of "betraying yourself," that's why I am working on a few scripts. More than once, I've thought I've copied they URL (from sigaint, for example) and gone to paste it, but I copied/pasted the password instead into the URL bar. D'oh! Even if I didn't load the page, with SIGINT stuff, I don't like having my password show up on the screen. Some scripts to let keepassx in a non-network VM interact with a networked VM's browser could avoid such betraying-yourself screwups. A few Qubes features are described as not protecting you from others, but protecting you from yourself. This falls into that category, IMO. > the Qubes > shortcut to copy/paste between VM's is Ctrl-Shift-C/V which conflicts. I, > like you, map that to Ctrl-Alt-C/V so no conflict. I've wondered why that > isn't the default since the other is such an obvious conflict. Agreed. It's way too obvious a conflict. There's just not enough key combos on the damn keyboard it seems sometimes. :) >> Using keepassx on Tails is so much more streamlined, without the extra >> level of copying/pasting. It'd almost be nice if there were some >> explicit >> dom0 support for it somehow. > > Yeah but Tails suffers from the same thing other OS's do which is one big > system. So if it was theoretically compromised your streamlined copy/paste > is exactly what you don't want. I'm a bit torn on that issue. Calling it "one big system" when Qubes is arguably more complex, I'm not sure is correct. I guess it depends upon your perceived threats. There have been times when things got "weird" on Qubes, and retreating to a Tails DVD-rom felt safer. But the Xen-on-top (with IOMMU protection against DMA attacks, etc.) ultimately should be safer. So confusing at times. > Nothing you don't know, but I don't want the inter-VM copy/paste to change > a bit. It's a small burden for a huge benefit. It also has an additional > benefit of each VM having it's own Paste buffer, which ends up being very > convenient. I hear ya. Right now, I *trust* the inter-VM copy/paste mechanism. I don't want features introduced that make it more complex/less trustworthy. And I think the tools are there with qrexec and the permissions system implemented to do what I want it to do, without changing the core. So yeah. :) If it's working, don't break it. >> Agreed. I keep my keepass database on one removable device, with a >> keyfile on a separate removable device plus a password. Some cowardly >> creep/crook wants to tamper with my system while I'm out, they're not >> going to get very far. > > I'd argue that your actually less secure with that scheme. Johanna made > some comments to that effect, what you are doing is a kind of air-gapping, > but you have a large attack surface through USB. Trust me, every time I hear those three letters, U.S.B., I think "security compromise." Why they ever let programmable firmware and stuff into the mix totally escapes me. If WW3 every happens, I swear it will be triggered by some USB security screwup. :) I actually load most of my keys off of 3.5" diskettes. :) Sometimes retro feels more secure, less hackable. > If an Evil Maid controls > your system it does you no good to bring in your passwords on a USB. No TPM here, just BIOS, so I don't think anti-evil-maid is something that applies to me. I could be wrong, need to research it more personally. I have a couple of personal anti-tampering approaches I use myself in lieu of that, which I might suggest as additions to Qubes at some point; but I won't talk about them just yet. > So, > if you're really concerned with that you should be implementing > Anti-Evil-Maid on your system as the only defense - not keeping passwords > separate. I'll read up on that more. Can't afford a maid, but I think there are other evil actors about. :) >> Since moving to that approach, I've noticed a lot more "noise" from the >> ones I suspect of being involved in my harassment. Ironically, probably >> a >> good sign. > > OH, OK then you have a situation with a probably not too computer > sophisticated opponent. Never mind then. The biggest mistake I've made (repeatedly) is underestimating the opponent. I have been totally naive throughout a lot of the grief. (In reality, I think there's a mix: one or more sophisticated opponents; and mostly likely expensive hired help. And one or more obviously not-to-sophisticated actors, that make obvious screw-ups now and then. Which makes things all m
Re: [qubes-users] Why not a Whonix (or TOR) Disposible VM?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-08-28 07:07, Cube wrote: > On Saturday, August 27, 2016 at 10:59:50 PM UTC-7, Andrew David > Wong wrote: >> This has been proposed and is being tracked here: >> >> https://github.com/QubesOS/qubes-issues/issues/2024 > > OK that's in the direction of a pure tails HVM solution it seems. It's not restricted to that. Read the comments on that issue. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJXw2lKAAoJENtN07w5UDAw6x8P/At2cMn2hNLAwzeIgKfelwH6 DGhZK+QaSljDo6FCypG1N+rFhkW/4augrwzMe0pnvPVw9GBuVimrVFG+oTv0UTZu twaznt4TlUsk8a4gDvMVfrDf7Ch0hRjdWjITdFjVNP7qAgRHszJLzKkFopBCVPIg CcB7ku7ZYJhvaw3m44PBAjWIoTbQIRMUunc6cOAF1ej1GAe5kJgAcsD18lCFLaUt yI+irPOCP6U4DuLlqFEFS+Fxp8vTHSZzyi6GLQ0f0zbqOnGGi/OzWoULDV9nfWln 6wmjLQz3N1GU3RNi1VPGqP39lS6P5XxrCXFN39WXvuxKMydXo7HyjQIvvgTlSedU Read5dhBoK3SXNU6xyCxd6AJTrHgOoCxkO0VrVnPl5BFkF/jV/Kq1fx/sCqfAr4s 7trYmsQvQW3UInvDnrN/59D7OhM+MJ1BcCHNtX4tRJ7c7wQ156tNGTBxAkaFXP39 oWpO73iROwFfPtF+Um9lIaPd3ag0uvF40cOw9IsjCGduHgomtd6AEEIuLkd9zRN9 BoxxsMUg6KblXoM07QBL6ICdO/17REfS34SQb67VYy2SbGdGHRNOvE59bGbJ7HW8 hOxlaeWjiupG6slhZIJi5seXAsdLGhsGH1YDnfZE8rf4HB0XZlRSXlfEg2caVJpY w2fR3oPXr99nzbU6YoIA =LN+w -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/f4bdc82a-7c01-8408-1509-4dd7a263ac59%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] R3.2 rc2 blank screen - screenlock issue?
richard.f.go...@gmail.com: > Problem description: > > After using the system all day (including unlocking and unlocking the > screen just fine) and then leaving it overnight I come back to a > blank screen. > > Doing a Ctrl-Alt-F2 gives me a command prompt but I can't get X to > respond (with Ctrl-Alt-F1). > > After a reboot all is well until after some apparently random period > it happens again. > > I've gone through the screen locker and power management settings in > Xfce (turned power management off) and turned of power management in > BIOS. No joy. > > System spec: Qubes RC2 rc2 running Xfce on Intel NUC5i5YRH with 16G > ssd. Kde is also installed but I'm not using it. > > Has anyone got a solution? -- Richard > Hi, I'm having a similar issue, which I believe may be caused by a bug in xfce. I posted about it here in a previous thread: https://groups.google.com/d/msg/qubes-users/qwMzj2au6uE/qd_hU6EUBQAJ Best of luck! -- 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/305ca12c-ce33-aee2-64c7-3586f7f9a5d7%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Network selection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-08-28 06:58, Jon Solworth wrote: > NetworkManager apparently selects which network to connect to based > on most recently connected network. This policy is really > unfortunate. > > At my university, I connect to my lab's WiFi and when I'm out of > range to my University's WiFi. My notebook can also see eduroam, > an inter-University roaming facility. But these networks have > different policies, in regards to firewall and bandwidth limits. > > I want to prioritize access points to lab first, university > second, and eduroam third. > > Is there a way to do this? > > Jon > If no one here can answer your question, you might have better luck with the NetworkManager folks. Qubes is just an indirect user of NetworkManager (in virtue of being a user of Fedora). We don't have any say in or control over NetworkManager's functionality. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJXw2iKAAoJENtN07w5UDAw7TAQAIYKS5U9OOt85JHvpXZoAAri DDTkuFyIoIaQsXNYipr3GKzwouPb3ymb89k9CtcZSoYe3IY7kxtScAjrkqxV0QHp 9lGa3hJWj7NEW9vAmT2hKa4TuGaGzVXXBzmwPZpukcwRX9enCvI7KRH8lfxKVB+x qZgZjNMKepq2yCvxoaekbtqsKDAr9MlslSqx2Uz2HUglpM5W4j3CqLvIIAS7T8+c CgkfGNIkEMfkQxbGFMxsTezPsBTPmhU+PScJ5vlv3nlUJYcc75w7EXquVpcPD1dV DsVG8AHRF0JPCjJfBCVfLdQ+U+4ppxwkTO2/bzT82Mg+18seaWAKa2LMMUang4DC Q3dYXB7EzrSyEGSIzLzm7DDYdJGb9fbyf4n5zY1YgkRdBkXZYjytyLdx9ZOoI+SN giu/a8vnAxvwnRuhfY/2OaIR4cZfHoY+YIyRW1JBsmU90ro/cgecp0KT0MR5Z6Dk 91oLFJeSxfKzyhvR3lM5YyvzsQeF2Dwm805aCdidvEFORsLWxBKFACb0AiGKg0sy FZz8yPVivlhGSmdNn0UrGHMLT5CsKogD08ZKPeJvJ8kbuPilOw95pPpULVnzdCyU ipN4cbEjc8uLLTcEN0s4R5u4zRrIivBIbVvs9rR061vkz5dJzLLXD1GUq3cusWwY zP8wtMDPwwlKGDK2p/h7 =kOrn -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/163f9346-3317-d29b-85fb-0a05a9fb3b9d%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes VM Manager Suggestions
These are fairly minor cosmetic issues, and if I ever get some of my current struggles under control, I'll submit patches instead of suggestions. :) I think the Qubes folks work on the VM Manager (and install process, which is amazing) has made major strides in making the system more accessible to all. Which is, in turn, key to making a secure work/personal computing environment available to the oppressed, or those who are simply security conscious. In that spirit, here are a few minor things I'd like to see tweaked in the VM Manager: 1) Column resizing. I like to toss my windows into one of four "quadrants" on the screen. xfce shortcuts make that pretty easy to do. But it'd be nice to see the whole VM Manager, not truncated, with the fields I want to see, each given the column size they deserve. 2) Current CPU % takes up wa to much space for a simple two-digti number. You don't need a bar graph to go along with it. 3) The CPU graph itself could easily add the current CPU % to it (centered, perhaps), without compromising the display. 4) Custom ordering. I like to stack my VM's in the order I want them. (Maybe even nested. :P) Currently, I use my own coloring scheme to achieve that, and sort by color. But it'd be nice if there were better support for arranging the multitud of VM's. (Just FYI, if you sort by color, the order is red-orange-yellow-green-gray-blue-purple-black. I usually sort by color, and use red for system stuff; orange for dicey stuff with no firewall protection; green for stuff that's nicely protected by Tor or a VPN; blue for stuff that has *no* network and is just a lot safer; black for templates; grey/purple for VM's I either no longer trust or no longer use). 5) It'd also be nice to be able to hide certain VM's (or certain colors, perhaps) no longer of interest, but that you want to keep around for reference. (Like the "internal" flag, but separate). The color mechanism is a great cue to the level of security you've flagged certain VM's to be, so that might be a good way to hide/show certain classes of VM's. 6) It'd be handy to have the application list for a VM (as you see on the main Qubes menu) be accessible when you right-click on a VM. Right-click on WorkVM, choose Firefox, kinda thing. (There's a "run command", but having the configured app list show up would be a lot handier.) 7) Are there any thoughts to support "hibernation" in VM's? (Not just a pause, but something that could survive a reboot?) "xl save/restore" does it, and I've had a bit of success with that, but I think it freaked out the VM Manager on a couple of occasions. :P Especially when memory is tight, it'd be nice to be able to hibernate a less-critical VM or two, and fire up something more important. I think I've read that disposable VM's use that save/restore feature, although not having explored that feature thoroughly yet (and that fact it takes up precious memory), I have that disabled for now. I think that's it for now. Sorry for the brain dump. :) Cheers. 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/3e6cf6fc76a5c53d70e3dd6d2c52cbf2.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: qvm-usb does not detect all devices, crashes
On Monday, August 22, 2016 at 5:28:17 PM UTC+2, Raphael Susewind wrote: > Dear all, > > > Any advice on how to proceed would be much appreciated, > > Thanks, > Raphael I am having more or less the same issue with my usb 2.00 devices (although I'm not seeing issues with buses having 2 digits); one is my keyboard, which, although it errors, works fine (permanently passed through to dom0). The other is my webcam (lifecam hd3000), which I cannot pass through to another qube because qvm-usb throws the error described above: Invalid 7-2 device desc in VM 'sys-usb' Invalid 5-2 device desc in VM 'sys-usb' Bluetooth connector for wireless keyboard: lsusb -v -s 7:2 Bus 007 Device 002: ID 045e:07a5 Microsoft Corp. Couldn't open device, some information will be missing Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x045e Microsoft Corp. idProduct 0x07a5 bcdDevice7.57 iManufacturer 1 iProduct2 iSerial 0 bNumConfigurations 1 Lifecam HD-3000: lsusb -v -s 5:2 Bus 005 Device 002: ID 045e:0779 Microsoft Corp. LifeCam HD-3000 Couldn't open device, some information will be missing Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x045e Microsoft Corp. idProduct 0x0779 LifeCam HD-3000 bcdDevice1.06 iManufacturer 1 iProduct2 iSerial 0 bNumConfigurations 1 -- 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/8b84fb94-06ed-4b66-a534-60aabb6db7ba%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes: No direct install on MacBook Pro mid-2012 retina (10,1) system
I have a mid-2012 MacBook Pro retina system - a 10,1 machine with 2.7GHz i7, 750 gig SSD, and the Intel HD Graphics 4000. I put Qubes 3.1 on an 8 gig USB and booted the system with option key held down. Qubes shows up as "EFI Boot" and it starts to a menu with four options: Test media and install Qubes R3.1 Install Qubes R3.1 Troubleshooting - verbose boot and Install Qubes R3.1 Rescue a Qubes System I tried the first three and played a bit with the command prompt. When selected the options flash something about a "file path:" which passes to quickly for me to see, then it returns to the menu. My install target is an external USB 3.0 enclosure with a 120 gig SSD that does a good job of running OSX. I was motivated to attempt this direct install based on this article, which explains how to get the Broadcom BCM4313 wireless card working. I realize the author installed Qubes using a PC, then shifted to running it on a 10,1 Mac similar to mine. https://groups.google.com/forum/#!topic/qubes-users/pcPwoNsq-j8/discussion https://groups.google.com/forum/#!searchin/qubes-users/broadcom$20success/qubes-users/VVwWqvz5dX4/Xbum_4MaCgAJ Next I'll try a PC install to the external drive, then boot it on the Mac. I just wanted to leave this here in case anyone else is tempted to try this experiment. -- 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/4d7b8251-ded4-43f7-8ef9-0b4f9573c893%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Why not a Whonix (or TOR) Disposible VM?
On Sunday, August 28, 2016 at 7:07:06 AM UTC-7, Cube wrote: > On Saturday, August 27, 2016 at 10:59:50 PM UTC-7, Andrew David Wong wrote: > any thoughts on either reverting my disposable VM statefile Well it's easy to revert qvm-create-default-dvm --default-template -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/35c7dba9-9628-409c-b628-07f325547452%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Why not a Whonix (or TOR) Disposible VM?
On Saturday, August 27, 2016 at 10:59:50 PM UTC-7, Andrew David Wong wrote: > -BEGIN PGP SIGNED MESSAGE- > > This has been proposed and is being tracked here: > > https://github.com/QubesOS/qubes-issues/issues/2024 OK that's in the direction of a pure tails HVM solution it seems. I think I'm more on the idea of simply a disposable Whonix/TOR VM. I followed the instructions I gave above https://www.whonix.org/wiki/Qubes/Disposable_VM And found that my disposable VM's have been taken over by Whonix. Wups ... any thoughts on either reverting my disposable VM statefile or having dual VM's? -- 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/fc16fb73-8636-43dc-8dac-77d8799690b3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Network selection
NetworkManager apparently selects which network to connect to based on most recently connected network. This policy is really unfortunate. At my university, I connect to my lab's WiFi and when I'm out of range to my University's WiFi. My notebook can also see eduroam, an inter-University roaming facility. But these networks have different policies, in regards to firewall and bandwidth limits. I want to prioritize access points to lab first, university second, and eduroam third. Is there a way to do this? Jon -- 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/7b70bd8e-0970-47a5-87c1-a3a9b4ad22e9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Security Best Practice: Cache web passwords in custom VM's or not?
On 08/27/2016 10:50 PM, johnyju...@sigaint.org wrote: > BTW, keepassx rocks. I'm working on some scripts to make it a little > less painful with all the Ctrl-Alt-C and Ctrl-Alt-V'ing (which also > conflicts with the standard konsole paste shortcuts). That would be nice. KeepassX used to have a working auto-type feature before v2, in which it was completely broken on Qubes. I did not try the auto-type of keepassx2 on any other fedora installation... > And to digress further, does anyone have opinions on Keepass2? It > looks "shinier," but I'm not sure needing to haul in all of Mono > *adds* to one's peace of mind...? I tried that, because I used to use that on Windows before moving my main workstation to qubes. It's even more broken than keepassx2. And I say that as a professional cross-platform C# developer, so absolutely no prejudice against Mono. > I realize some of the factors are licensing issues, but having to go > to a non-Fedora-approved, non-Fedora-Reviewed, repository (Fusion) to > simply view mp4 videos with mp3 audio didn't sit well with me. > > And half the "howto's" about adding that repository involved a > --nogpgcheck flag, which isn't cool with me, either. :) I guess > there are signing keys around, and people say "yeah, sure, you can > trust rpmfusion, it's been around forever" but it just doesn't seem > as provably trustworthy as the core repo. It'd be a great vector for > attack. > [] > These days, I think anyone is subject to attacks on a mass scale, > for anyone who is willing to pay to get access to the hacks. Many a > time I've been led to believe that things are simply hacked by > default, and up for sale if the price is right, to anyone with enough > money or craziness to invest in it. > > Just my cynical point of view. :) > I understand your cynical point of view, but just two paragraphs above that you seem to heavily discriminate against "non-core" repositories (i.e., rpmfusion) wrt Fedora's official repositories. I can't agree with you on that: for me, the Fedora repository is just as exploitable as any other repository can be, be it rpmfusion or debian; did you ever question your blind trust in Fedora's repos above the others? Why do you think one is preferable than the others? I'm sorry if I sound a little aggressive, English is not my primary language, I just want to understand your point of view. That distrust in software repositories is one of the very reasons for the templated infrastructure of qubes: isolate vms, create different templates with different software to minimize exposure of data to untrusted software. (say, home banking credentials, amazon AWS otp generators, etc.) where attackers may have the financial power to aggressively attack the target AppVM - so my line of defense here is to be sure not to have the sensitive information available on the filesystem at all. > > Agreed. I keep my keepass database on one removable device, with a > keyfile on a separate removable device plus a password. Some > cowardly creep/crook wants to tamper with my system while I'm out, > they're not going to get very far. > I think you are mixing threat models, and I myself lost once in that sea... Being Qubes a single-user OS for local-console-interactive workstations, the question about caching web passwords in browser or not does not belong to analysis of physical exploits; thus my threat model, which does not include any physical attacks beyond evil maid. But judging from your paragraph, I can't discern your threat model. Is it a software exploit? Is it an untrusty person walking up to your computer? It seems to me quite inconvenient to have to juggle with 2 usb thumb drives, with all the added burden of connecting each to the correct AppVM... About that: connecting USB thumb drives to AppVMs it's just a couple clicks more, but the added work drove me in using thumb drives less than before. And I think that's a relatively healthy habit to acquire... But I'm going too much OT. > That reminds me: one thing I think I read in some Qubes architecture > docs or online reviews, was the mention that each AppVM's filesystem > was individually encrypted with its own key, which is clearly not > currently the case. > > Are there any plans to support this in the Qubes VM Manager? > > Currently, I just keep personal communications, documents, etc., in > a separate, encrypted, mountable device that I can assign to a VM as > needed. But having individual keys for each VM would go further > towards one stated goal of disallowing each VM or dom0 from being > able to snoop on each other. I don't agree this will add any security. Since the keys should actually be in dom0 (or pass through that, if entered by a user), having a compromised dom0 will ultimately lead to global vulnerability, be the disk images encrypted or not. This will negatively impact performance, instead. Again, depending on the threat model, you may want to be able to give
