[qubes-devel] Re: GVT-g Discussion

[pixel fairy]

This comes up often, and i suspect qubes-os is the inspiration for the xen 
version of it, but it also opens up a big can of attack surface. maybe 
after splitting the guivm off from dom0?

On Friday, November 22, 2019 at 2:02:14 AM UTC-8, Dylanger Daly wrote:
>
> Will the Qubes team consider enabling the use of GVT-g so we can enjoy 
> hardware accelerated graphics?
>
> After upgrading to DDR4 Memory I've noticed a significant increase in 
> performance, I assume this is because of the many, many memory copies 
> taking place, GVT-g should lighten the load.
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/49dcc8d8-18ec-4b47-8329-f0fcb84581b6%40googlegroups.com.

[qubes-devel] Re: My farewell to Qubes OS!

[pixel fairy]

Saw this and thought it was april 1st!

Thanks for creating this project! you changed the face of endpoint security

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/62fe68c0-14c7-4ac0-900a-11c30dc14e4d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Re: Massive improvement in performance and battery life since switching to pvh

[pixel fairy]

On Tuesday, February 13, 2018 at 3:14:15 PM UTC-8, Jean-Philippe Ouellet wrote:
> Thanks :)
> 
> The ~10% cpu overhead for each linux-stubdom should still probably be
> fixed for those who need HVMs (and for sys-{net,usb}), but still...
> 
> My previously constantly-spinning laptop fans appreciate it.
> 
> Cheers,
> Jean-Philippe

strange. i got the opposite, but given one of other replies, it may be specific 
to my motherboard. i realize its a stretch, but ill try it as soon as i get a 
chance. see 
https://groups.google.com/forum/?hl=en#!topic/qubes-users/YSeDcd91v-s

its not just boot up times. some apps subjectively feel slower or jerkier, 
though watching movies in youtube in full screen still works in firefox, but 
not chrome.

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

[qubes-devel] Re: Fedora 27

[pixel fairy]

why not skip 26 and just go to fedora-27 for dom0 in 4.0?

On Thursday, November 2, 2017 at 8:37:48 AM UTC-7, Frédéric Pierret 
(fepitre) wrote:
>
> Hi,
>
> Maybe you have seen that Fedora 26 is supported for building (see 
> qubes-builder) and it is on the road to be officially released (Marek can 
> you confirm?) in Qubes R3.2 and R4.0. Just to let you know that I have 
> prepared and built Fedora 27 template for Qubes 4.0 and everything seems to 
> work: qubes tools, sound (pulseaudio 11.1) etc. I don't plan to test it for 
> R3.2 but it should be straightforward if needed.
>
> Notably, we could discuss what would be dom0 in 4.1: I tried Fedora 26 and 
> I will also try Fedora 27.
>
> There is still things to do for the installer, specifically, rewrite few 
> things about passwords in Anaconda (see 
> https://groups.google.com/d/msg/qubes-devel/l9xDmPXpNfg/NJyHRP_EAQAJ) but 
> I should work on it in the next days.
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/f1189238-86e2-4ce6-949f-52fa4fdbe1fb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] dispvms in qubes 4.0

[pixel fairy]

On Wednesday, November 8, 2017 at 9:01:44 PM UTC-8, Marek 
Marczykowski-Górecki wrote:
>
> > > Hmm, what exactly to do you want to achieve? The above "qvm-create 
> > > 
> > 
> > make a customized dvm with menus that show up in the top left. Ideally, 
> > this 
> > would behave like the qubes-3.2 version. so for example, browser 
> settings 
> > could be customized, and the dvm would still update when the template vm 
> > does. 
> > 
> > 
> > > - --class DispVM ..." is the correct one. It creates DispVM which can 
> be 
> > > later started etc. And when you shutdown it, all its state (private 
> > > volume etc) is discarded. Initially it get all its properties from its 
> > > template, so this is why it got black border. Indeed it is confusing 
> and 
> > > could be improved. You can change the border using qvm-prefs. 
> > > 
> > 
> > yes, it is confusing. But after this thread the docs can be made clear. 
> > 
> > seems qvm-create ignored the label flag in those two cases. 
> > "qvm-run myvm gnome-terminal" works as you describe, deleting the 
> > dummy text file i left in ~. but there was no indication of this. it 
> > started "mydvm" 
> > instead of disp. 
>
> Well, a VM name is just a VM name. Having disp name does not 
> guarantee that it is really DispVM. You can freely create AppVM with 
> such name, or even TemplateVM, if you really want... 
>
> If you want some naming convention, apply it on your own. 


> > no menus for mydvm or my-other-dvm showed up in the top left menu 
> widget. 
> > nor any indication that these new dispvms exist, other than seeing them 
> in 
> > qvm-ls. 
>
> DispVMs do not have menu entries on its own, on purpose - to not trash 
> the menu with a lot of disp entries, and also to not slow down its 
> creation. 
>

I meant menu entries that start the dispvm. for example, when you call 
firefox 
from the fedora-25-dvm multiple times, it makes multiple dispvms. I dont 
want disp
to show up in that menu. i agree that it would be silly.
 

> Maybe this should only apply to "dynamic" DispVMs - those created just 
> for one service call... 
>
> But, you can say that you want menu entries for an AppVM to launch 
> applications in a new DispVM created from it. Just like it is done for 
> fedora-25-dvm. To enable this feature for your own AppVMs, use 
> qvm-features tool: 
>
> qvm-features dispvm-template appmenus-dispvm 1


that worked for dispvm-template, but no menu for mydvm.

If you deleted fedora-25-dvm, how would you re create it?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/71f807fc-0518-4f51-8a1b-cd75391a8dce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] dispvms in qubes 4.0

[pixel fairy]

>
>
>
> Template for DispVM needs to be an AppVM. So, first create AppVM (or use 
> fedora-25-dvm provided for this purpose), then set 
> template_for_dispvms=True and use that AppVM for your DispVM. 
>

Still confused. The second thing i tried above was make an appvm, then set 
template_for_dispvms=True.
that command returned without error, but it made a standard AppVM, 
preserving data. 

Just tried making an appvm to use as a template for a dispvm,

qvm-create --class AppVM --template fedora-25 --label black dispvm-template
qvm-prefs dispvm-template template_for_dispvms True
qvm-create --class DispVM --template dispvm-template --label red mydvm


That created a DispVM thats only visible from qvm-ls, and somehow has a 
black border if you start it with qvm-start. its the only one listed as a 
DispVM. the two working ones, fedora-25-dvm and whonix-ws-dvm are listed as 
AppVM

Trying the third command with --class AppVM gave an error in journalct that 
ended with "TypeError: wrong VM class: domains[https://groups.google.com/d/msgid/qubes-devel/08e685c7-6ca8-46a5-b2cb-3167bb4365a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] dispvms in qubes 4.0

[pixel fairy]

Ive tried creating them with 

qvm-create --class DispVM --template fedora25 --label red mydvm
app: Error creating VM: Got empty response from qubesd. See Journalctl in 
dom0 for details. 

the last line of that was 

AttributeError: 'TemplateVM' object has no attribute 'template_for_dispvms'

so i tried

qvm-create --class AppVM --template fedora-25 --label red mydvm
qvm-prefs mydvm template_for_dispvms True

which seemed to work, but mydvm was a standart appvm. 

qvm-prefs mydvm dispvm_allowed True
qvm-prefs: error: no such property: 'dispvm_allowed'

so how does one create and modify dispvms in qubes 4?

I was able to clone the fedora-25 template. modify that, and set that as 
the template vm to an existing dispvm, but then when you have to update 
packages, you have to download Nx as much data (number of dispvm 
templates), so i hope thats not the only way.

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

Re: [qubes-devel] feature request, copy / paste / type. is this feasible?

[pixel fairy]

On Friday, August 11, 2017 at 4:16:38 AM UTC-7, Marek Marczykowski-Górecki 
wrote:
>
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA256 
>
> On Fri, Aug 11, 2017 at 04:08:53AM -0700, pixel fairy wrote: 
> > 
> > there is another reason id like to be able to type into a VM, but its a 
> > corner case ive seen twice. sometimes the gui can hide keyboard events 
> from 
> > other apps, but not the clipboard. os x does it, but its hard to use 
> unless 
> > the app specifically allows for this, and wayland when xwayland is 
> enabled 
> > thanks to a design flaw in that. i doubt os x will ever become a 
> supported 
> > appvm, but wayland is inevitable. a future version of windows may also 
> > become like this. for now we have more reason to make different appvms 
> to 
> > isolate all those gui apps. 
>
> I wouldn't count on _meaningful_ GUI isolation in any mainstream OS in 
> the near future... There are improvements, but - as you noted already - 
> there is still way more to do there. 
>

wayland has the right intentions. it isolates screen, clipboard, and input 
(mouse, keyboard etc)
so im skeptically hopeful for this one. its far better than any other 
design i've seen. 

but, all it took was one misdesigned plugin, and desktops that rely on its 
functionality (gnome), 
and not only does the clipboard isolation go out the window, the rest of 
wayland prevents something like 
keepassx from getting around that by typing into the receiving app. you 
would have to build keepassx 
into your compositor to get around that. (or send keystrokes to the vm)

just thought about xdotool from dom0 to make it transparent to the 
receiving end. thats scary close
to the trusted base, but perhaps a tool like this could be made in the 
future.
 

> - -- 
> 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 
>
> iQEcBAEBCAAGBQJZjZIRAAoJENuP0xzK19csRAoH/iEz5Eujq6PPMBY0Bb7O50HI 
> ixqFEbbJAvfnR0s6tKH8kYX4Z9JwdQauiErbNANCiszKzJWnh/HnQaiqjI7UY9Xs 
> dYUORunjlRFMxWlTvmZDVXZdTSMYtgjAqRGBapMRmYzy56/qB4ScVcOYpDW2FhGi 
> uiBRDKqhtcLoGQ5dQF9enC5Sm6zOu214otponNZnd1t+/i9gnP00qY9Rb2JEu6UL 
> 0ifX65AK0bNpZErla09rISsLzA8/qB823r3IcsSyhPK/pUFtp8Zd7k+lSg5SaQ1Y 
> JvhpXSKjkMXBTHrje0suuoyAeq5gSwN3QEsv/g05cx8URfxOslNSucK5YtwA5Ds= 
> =uE/r 
> -END PGP SIGNATURE- 
>

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

[qubes-devel] feature request copy/paste/type is this feasible?

[pixel fairy]

sometimes, copy paste isnt enough, because not all apps use the clipboard. 
for example, most remote desktops like rdp or vnc unless that app has its 
own clipboard sharing mechanism. while one could simple view their keepass 
file and type, this has two problems. 


   - shoulder surfing
   - keyboard timing attacks

before qubes, when i ran vmware/virtualbox with packer and ansible, i would 
use xsel to copy and xdotool to create keyboard events on the receiving vm. 
is there a way to do this with qrexec or the input proxy? could this be 
added, perhaps as ctrl-shift-t? 

this could be tricky. i had trouble using virtualboxes built in keyboard 
typing for example, and a script that worked on vmware didnt work reliably 
on virtualbox.
Click here to Reply

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

[qubes-devel] feature request, copy / paste / type. is this feasible?

[pixel fairy]

sometimes, copy paste isnt enough, esp for keyboards, because not all apps 
use them. usually you cant copy / paste into remote desktops like rdp or 
vnc unless that app has its own clipboard sharing mechanism. while one 
could simple view their keepass file and type, this has two problems. 


   - shoulder surfing
   - keyboard timing attacks

before qubes, when i ran vmware/virtualbox with packer and ansible, i would 
use xsel to copy and xdotool to create keyboard events on the receiving vm. 
is there a way to do this with qrexec or the input proxy? could this be 
added, perhaps as ctrl-shift-t? 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/1740493e-4bb0-4f03-b5b7-81a38915356c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] kickstart for tricky hardware

[pixel fairy]

could kickstart work with the qubes installer? if so, maybe kickstart files 
could at least help some of the pain or at least help share knowledge for 
installing qubes on tricky hardware. most issues seem to be dealt with in 
bios / uefi where kickstart cant really help you, so this may not be worth 
the effort.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/314ccd87-5c96-468e-a2a0-3673e50cdc9d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Announcement: Toward a Reasonably Secure Laptop

[pixel fairy]

On Friday, July 14, 2017 at 10:08:36 PM UTC-7, Syd Brisby wrote:
>
> Well, at least one phone maker has recognised that the best security comes 
> from physical separation. Unfortunately, PC / laptop makers are a long way 
> behind.
>
> Privat phone:
>
> http://privat-smartphone.com/#solution
>
> "PRIVAT has two independent mainboards, one for the smartphone hardware 
> and the other one for the independent camera. Furthermore, each one has its 
> own operating system with an internal memory and an expandable SD slot. You 
> can also physically disconnect through a switch the GPS module, cameras and 
> microphones. The use of PRIVAT could be useful for famous artists, business 
> men, politicians or simply everyone who needs to keep high control of his 
> private data through an robust system."
>

cool, now we just need to get qubes running on that phone! 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/3f88175a-e093-464b-9c6a-0c3873a75f5a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Re: 'Hypervisor Introspection defeated Eternalblue a priori'

[pixel fairy]

On Friday, July 7, 2017 at 1:20:10 PM UTC-7, Chris Laprise wrote:
>
> I know Joanna's reservations about VM introspection, but this 
> Bitdefender introspection example is interesting nonetheless: 
>
>
> https://businessinsights.bitdefender.com/hypervisor-introspection-defeated-enternalblue-a-priori
>  
>

Im curious about these reservations. is it the attack surface?

xen hypervisor introspection looked like a total win to me.  

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

[qubes-devel] Re: Fedora 25 template for Qubes 3.2

[pixel fairy]

meant to say please tell me this will be dom0 for qubes 3.2.1

On Thursday, July 13, 2017 at 3:12:55 PM UTC-7, pixel fairy wrote:
>
> please tell me this will be dom0

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

[qubes-devel] Re: Fedora 25 template for Qubes 3.2

[pixel fairy]

please tell me this will be dom0

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

[qubes-devel] Re: Preliminary test image of Qubes 4.0

[pixel fairy]

On Thursday, July 6, 2017 at 2:44:36 PM UTC-7, Marek Marczykowski-Górecki 
wrote:
>
>
>
> Download links: 
> https://ftp.qubes-os.org/~marmarek/Qubes-DVD-x86_64-20170706.iso 
> https://ftp.qubes-os.org/~marmarek/Qubes-DVD-x86_64-20170706.iso.asc 
> (signed with my code signing key) 
>

wheres your code signing key? 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/956115fd-676e-405e-94f9-467501a74db1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Re: 3.2.1 should be released

[pixel fairy]

On Thursday, June 15, 2017 at 11:50:31 AM UTC-7, Reg Tiangha wrote:
>
>
> We're still stuck with FC23 in dom0 though, although you could attempt 
> to build an ISO that uses FC24 or FC25 in dom0; some people have. It's 
> unsupported though and you're on your own when it comes to compiling 
> Qubes updates for dom0 afterwards. 
>

why stuck with fc23? thought marek had built fc25, but was having trouble 
with fc26 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/13e281c1-8d09-415c-9d4c-3b166e919374%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] fedora 26 releaseed july 4, should 3.2.1 come a week or two after that?

[pixel fairy]

fedora 26 is coming out july 4, debian 9 should be out in a couple weeks, 
so should be stable(ish) by then. would a couple weeks after the f26 
release be a good time for 3.2.1? 

the sad problem with fedora releases is their short life span, but that 
also helps them have more modern drivers. 

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

Re: [qubes-devel] ipv6 for internal network in 4.x?

[pixel fairy]

On Monday, May 29, 2017 at 9:57:08 AM UTC-7, Patrik Hagara wrote:
>
>
> I'd like to mention the relative complexity of the IPv6 specification 
> (and by extension, its implementations) as a reason against this 
> proposed change. For example, take a look at this list of CVEs 
> related to IPv6 [0]. Please also note that writing firewall rules 
> for IPv6 can be quite challenging at times. 
>

against which proposed change? one is the standard dual stack with nat66, 
the other nat64, which as i already mentioned, wouldnt work for us as it 
breaks some protocols. iptables is being replaced with nftables, which 
applys the same rules to both, so i dont think there would be much added 
challenge in that, but there are more pitfalls.  

Second, IPv6 was, in fact, designed with clients running multiple VMs 
> at a time in mind -- you're just supposed to delegate v6 addresses 
> from a /64 (or bigger) IPv6 prefix and not use a NAT mechanism. 
>

wasnt rfc 4389 supposed to address that? in our case, we want to hide 
whats going on behind the netvm, but having this, or just a binat, would 
be good for a vm that we want to seem outside it comepletely. 
 

> While I do accept the fact that IPv6 support is neccessary, I don't 
> think the existing v6 network stack implementations are quite as 
> mature as the v4 ones (which have undergone extensive testing "in 
> production" over the last few decades) -- especially not mature 
> enough for use in a security-oriented OS. 
>
> Should you find yourself in an environment with only v6 connectivity, 
> having IPv6 stack available **only** in the untrusted net VM will 
> definitely come in handy, but IMO all the VMs downstream should be 
> using v4 (either via 4in6 [1] or similar transition mechanism). 
>

i like this idea.

we could also only enable and nat v6 in the vms that need it. but, this 
would add attack surface to the firewall vm.
something like 4n6 from app vm to netvm would mean added firewall rules to 
the netvm, increasing its complexity.
a separate v6 enabled firewallvm would be additional overhead, but maybe 
not enough to matter.
 

> Cheers, 
> Patrik 
>
>
>
> [0] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ipv6 
> 
>  
> [1] https://en.wikipedia.org/wiki/4in6 
>

 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/15bd78ab-d95a-4e50-9fea-8d566c392147%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] ipv6 for internal network in 4.x?

[pixel fairy]

>
> Are you suggesting that VM's no longer have internal ipv4 addresses? You 
> mean 
> via the ipv4-in-ipv6 address range or something else? 
>

i was thinking dual stack and nat for both 4 and 6. my first thought was 
using the v6 addresses to internally address the vms, but that seems to be 
mostly done through vchan. proxy, firewall, and network vms, would need to 
support both anyway.

the only other way ive tried was nat64, and i remember hitting a problem 
with tls verification, but my setup could have been wrong. tried googling 
for "nat64 ssl" and "nat64 tls" and cant find anything on it.
 

>
> -- 
> https://petertodd.org 'peter'[:-1]@petertodd.org 
>

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

[qubes-devel] ipv6 for internal network in 4.x?

[pixel fairy]

since qubes needs to adopt ipv6 eventually anyway, can we make the internal 
network v6? 

v6 nat is the same as v4, but you would have to alert qubes when there is 
no external v6 route. this will also be true when there is no external v4, 
so its a problem that needs to be solved anyway. 

one of the motivations is how easy it is to conflict with an existing v4 
10.x network. and, of course, id like to finally have ipv6!

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

[qubes-devel] Re: QSB #30: Critical Xen bugs related to PV memory virtualization (XSA-213, XSA-214)

[pixel fairy]

On a more immediate or practical level, i was going to ask about a qubes 
3.2.1 release for all the things that have been building up, or perhaps a 
3.3 release, with the significant change of moving to hvm by default.

that way, theres less incentive to rush the 4.x releases.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/631de1e9-83ab-4f26-ad94-7248d6841b51%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] qubes-builder fail: get-sourcesls

[pixel fairy]

On Monday, April 24, 2017 at 3:13:48 AM UTC-7, Marek Marczykowski-Górecki 
wrote:
>
>
> All of this is conveniently handled by `./setup` script in qubes-buider. 
>

the goals is to try different versions of xen and of fedora in dom0.  how 
can you know which versions of xen and linux kernel are available?

tried with the setup script, and override.conf in the qubes-builder 
directory, but that didnt seem to help. is the above possible with the 
setup script?

right now just seeing if it will build with an f24 dom0, and seems to be 
working. have you gotten it to work with f25?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/5cad225a-6ff8-4e1f-8d48-91d8a5e391ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] f25 broken?

[pixel fairy]

last build worked when i disabled f25, is that currently broken? 
is there any reason to still use f23 as dom0? 

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

Re: [qubes-devel] another build fail, could not find xen source

[pixel fairy]

thanks. git pull didnt change, make get-sources did its thing. 

this time it failed at 

Makefile:294: recipe for target 'template-local-fc25' failed

going to try again with just fc24

On Friday, April 21, 2017 at 8:20:41 AM UTC-7, Marek Marczykowski-Górecki 
wrote:
>
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA256 
>
> On Fri, Apr 21, 2017 at 02:22:27AM -0700, pixel fairy wrote: 
> > dpkg-source: error: can't build with source format '3.0 (quilt)': no 
> > upstream tarball found at ../xen_4.6.4.orig.tar.{bz2,gz,lzma,xz} 
> > dpkg-buildpackage: error: dpkg-source -b debian-vm gave error exit 
> status 
> > 255 
> > /home/pixel/qubes-builder/qubes-src/builder-debian/Makefile.debian:199: 
> > recipe for target 'dist-package' failed 
> > 
> > looks like it couldnt find the xen source. is an earlier stop supposed 
> to 
> > download it? 
>
> debian/changelog was not updated. Fixed now. 
>
> - -- 
> 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 
>
> iQEcBAEBCAAGBQJY+iNEAAoJENuP0xzK19csNzwIAId+XtDo5HmKzVlJC8zerOAW 
> kBI0GTAZydCD1Gq0zl9xfXKXXqYwcB1e/YM31bcxsFX+3BYsJJmICxXV5GiA8DCb 
> UqWWJsXAlxVtOwJ7XTFeJb2y0ShMjuSsPjcOYVGE299vyFpW6HWGh1Jl/hbt4pWU 
> xXuAFf4yP4+ipoyTHHfnB0MGMJ+tdYT80KILsBI3FInom1Xwbrobgp6T8i+yDs0O 
> Pw7rtylz1inhqRStc0bkn2U0c4VrCx470xuo/JiPFQ6e4ALAq1mOw9/h3s6sESRZ 
> +se3KGi5g/vGQFiawrszx13H+UnTEFOIYeMTYddRm/tPSLB5XOgQsiuDqEo0cpg= 
> =2a/4 
> -END PGP SIGNATURE- 
>

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

Re: [qubes-devel] 3.2 build fail

[pixel fairy]

just clicked it out of curiosity. id be happy with fedora25, debian 8/9, 
and ubuntu xenial

On Friday, April 21, 2017 at 8:16:11 AM UTC-7, Marek Marczykowski-Górecki 
wrote:
>
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA256 
>
> On Fri, Apr 21, 2017 at 01:41:36AM -0700, pixel fairy wrote: 
> > tried building the stable release, heres the script session and 
> builder.conf 
> > host is fedora 25. 
>
> The failure is during building xen for Archlinux - apparently Archlinux 
> have much newer gcc which include some new warnings. Is your intention 
> to have Archlinux template? If so, you'll probably need a patch for 
> those warning. If not - simply disable Archlinux build in builder.conf. 
>
> - -- 
> 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 
>
> iQEcBAEBCAAGBQJY+iI2AAoJENuP0xzK19csZtMIAIshBU6bND3iJnfLB1xOIhaj 
> sxR5sjpHW+HCKX9uezDna1ZhHS+/Qu/DzGWB6p/V5omJoRtYglHKpsKuHLR6+2xI 
> Zw+8EVODSUUdW8MJPg/k1j2NFKc938rKsNs6cfeYHrlZZ2tVxLjBl2SSvatl7aJg 
> NS7AYQyavY0ZrA31TA9zaAl0HYiW+kMkqGKc8iZzmlBFDTxiV7P0PMNaiYJH6+lY 
> DbRu4itzZ+I0sr1/Q9KdtnjUDIBlnX0UL7BtxJA6o9yRsXIvj6axPAGdRzeWKPxE 
> VxfWr4DXRXOlV2YFPkOOZkxEeq/u1op6igC1HGX7VZtnc4eF3qm7iv0kG+la2Pc= 
> =kG4M 
> -END PGP SIGNATURE- 
>

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

[qubes-devel] Re: Announcement: Qubes OS Begins Commercialization and Community Funding Efforts

[pixel fairy]

So this is basically support contracts with some custom coding thrown in? The 
next step, probably scary to some users, is corporate channels. Have you 
contacted dell and hp yet? 

either way, im happy for this and hope it works!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/b95f0188-bce5-42ed-846c-6a17896f37f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] questions about qvm-block

[pixel fairy]

how do you specify which device to detach? this is for detaching disk 
images.

is there an easy way to know what device it attached as? "ls /dev/xvd*" 
before and after seems messy to me, but if thats the way, im not too 
worried about it.

is attaching qcow2 images not supported because of oversight or fear of 
parsing a malicious qcow2 header? 

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

[qubes-devel] xdotool to type senstive data into app vms

[pixel fairy]

in my precube days, i had a vaultvm and various appvms. because firejail 
could protect the keyboard from scary apps, and i just dont like sensitive 
data hitting that clipboard, my pass script would copy the vaults 
clipboard, then type it into the target vm using xdotool over ssh. this 
worked pretty well, so i was thinking of installing xdotool into dom0 and 
writing a new script to the same end. 

now, i just make new appvms for all the big gui apps or related apps like 
gimp and blender, which work together.

the only problem i can think of is that this might break with wayland, 
depending on what order things move. but worst case, were back where we 
started.


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

[qubes-devel] replacing fedora?

[pixel fairy]

This has come up a few times, so heres a thread discuss it.

for whatever reason, supported versions of fedora are not working with 
qubes. dont know if this is fixable.

debian looked good at first, but its hardware support is too many 
generations behind. tried switching sys-net to debian, and it couldnt find 
my intel wifi from 2010. i understand ubuntu has a licencing issue, and 
thus, can not be used. 

would centos work, or is that also too far behind?

arch and alpine have been brought up as alternatives. anyone try those? do 
they do a good job with hardware compatibility and vulnerability patching? 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/144ccb6d-91bb-446a-bc74-853ddd5020cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Re: Introducing the qubes-announce read-only mailing list

[pixel fairy]

On Thursday, October 27, 2016 at 8:00:34 PM UTC-4, Drew White wrote:

>
> So it's a forum, not a mailing list


its a mailing list that happens to have a forum interface. kinda like nntp 
but the other way around. 

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

[qubes-devel] adding -nolisten local to X startup, to allow for better gui isolation.

[pixel fairy]

As explained here, https://github.com/netblue30/firejail/issues/770 adding 
'-nolisten local' allows for easily isolating x11 or sandboxing an app from 
it. i cant see any advantage to having both the unix domain socket and the 
abstract socket. 

this should be upstream. but, that change would take longer, if it even 
makes it through their bureaucracies.

example, a text based irc client shouldnt take screen shots in the 
background.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/3476eef1-f203-4ee4-9ef6-3045d60adf6f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] dom0 blue?

[pixel fairy]

On Tuesday, September 6, 2016 at 8:50:49 AM UTC-7, Nicklaus McClendon wrote:
>
>
> Looks to me like the blue is a result of the chosen Theme's default 
> color. Perhaps the Qubes XFCE patches should also set a color for dom0 
> to avoid confusion and allow for a greater number of themes to be used 
> without color conflict? It looks from the patch that the color 
> currently used to represent dom0 is 100% transparent. 
>
> There are more color neutral window manager decorations. maybe one of 
those should 
be the default.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/e5e772dc-9a7c-4085-8fb5-99086ef94605%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Re: 3.2-rc3 still fedora23

[pixel fairy]

too bad. i hope whatever replaces fedora in qubes 4 is more xen and 
graphics driver friendly.
graphics drivers are still the bane of qubes on laptops!

On Friday, September 2, 2016 at 4:03:20 AM UTC-7, pixel fairy wrote:
>
> why not fedora24? its been out for more than 2 months.
>

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

[qubes-devel] 3.2-rc3 still fedora23

[pixel fairy]

why not fedora24? its been out for more than 2 months.

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

Re: [qubes-devel] 3.2rc3 sys-whonix settings

[pixel fairy]

theres the issue of tor safety, when sometimes your in a bad place, but not 
always. 
i was also thinking of resource usage while sys-whonix is just sitting 
there.  but, its 
pretty light so probably doesnt matter much.

On Wednesday, August 31, 2016 at 10:47:22 AM UTC-7, Marek 
Marczykowski-Górecki wrote:
>
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA256 
>
> On Wed, Aug 31, 2016 at 09:55:08AM -0700, pixel fairy wrote: 
> > in 3.2-rc3 sys-whonix is started at boot, and has backups enabled. 
> neither 
> > are needed. 
> > 
> > starting a connection to tor might be bad in some places, so its better 
> to 
> > make sure the user wants to start that whenever they use it. 
>
> During first startup it will ask you whether you want to connect to Tor 
> directly. If you want, you can also disable autostart of that VM, but in 
> most cases it will be simply more convenient (faster startup of 
> Whonix-related VMs). And if you live in censored area, you'll probably 
> need to setup bridges anyway. 
>
> As for backups, you're probably right, but lets wait for Patrick's 
> confirmation. 
>
> - -- 
> 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 
>
> iQEcBAEBCAAGBQJXxxgeAAoJENuP0xzK19csCvcIAJmegvBaR3hWPp/Occjo6WqR 
> 9lEYn8vT/q4ZMrKzRiWBncAml8asAEzbvFdTKYOLWass8y6vhTUWBofRF9vVqrhH 
> NGSP6hqhB27vRfWcIyPB3APf31XvQv3bOkDBTysjjwqYS2nZvtpulHOBwAes5sdx 
> LM3IxdFxp9AQSDl+Hv6zWjUT9oxdpvRo5u3KzJKSTc71SsKWv+N3olUVzvE/KCIf 
> 8C3rl2CGWThhNO0a51NW4NyOGJaD9k7/2PU9bY2gGHb5JUJ1rx9SbDGT+Sb06zOy 
> JlW1jmUmR64t0jo5+G/ThtlM5q/CN+wOvw+FpPqoQVvcQE/30h2Vlyg3R/R0Hnc= 
> =SHpI 
> -END PGP SIGNATURE- 
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/6d6f2f91-8df3-44e7-abd4-1b4334c1cf71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] 3.2rc3 sys-whonix settings

[pixel fairy]

in 3.2-rc3 sys-whonix is started at boot, and has backups enabled. neither 
are needed. 

starting a connection to tor might be bad in some places, so its better to 
make sure the user wants to start that whenever they use it.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/6e79adb2-1d0f-4940-81c7-acf9d2ac87ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] qubes 3.2rc2 blender can fullscreen when fullscreen is set to false

[pixel fairy]

On Wednesday, August 31, 2016 at 6:36:53 AM UTC-7, Andrew David Wong wrote:
>
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA512 
>
> On 2016-08-31 06:34, Marek Marczykowski-Górecki wrote: 
> > On Wed, Aug 31, 2016 at 02:32:40AM -0700, pixel fairy wrote: 
> >> run blender. press alt+f11 
> > 
> > Alt+F11 happen to be the default shortcut for making window fullscreen 
> in 
> > Xfce. Application can't trigger it itself. 
> > 
>
> But I think pixel fairy's main point is that it shouldn't be possible to 
> cause 
> a program to go fullscreen even by pressing Alt+F11 if "allow_fullscreen = 
> false" for that AppVM in guid.conf. 


as a user, i was fooled by this. but, now its clear that its doing what its 
supposed
to. 

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

Re: [qubes-devel] qubes 3.2rc2 blender can fullscreen when fullscreen is set to false

[pixel fairy]

>
> On 2016-08-31 06:34, Marek Marczykowski-Górecki wrote: 
> > On Wed, Aug 31, 2016 at 02:32:40AM -0700, pixel fairy wrote: 
> >> run blender. press alt+f11 
> > 
> > Alt+F11 happen to be the default shortcut for making window fullscreen 
> in 
> > Xfce. Application can't trigger it itself. 


 yes, i was fooled by the happy coincidence. 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/f3888769-37fd-46c0-b6b1-8ddf9c7879d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] qubes 3.2rc2 blender can fullscreen when fullscreen is set to false

[pixel fairy]

On Wednesday, August 31, 2016 at 5:56:12 AM UTC-7, Andrew David Wong wrote:
>
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA512 
>
> On 2016-08-31 02:32, pixel fairy wrote: 
> > run blender. press alt+f11 alt-tab still works. 
> > 
> > personally dont care. but, if someone really wants full screen disabled, 
> > this could be an issue. 
> > 
>
> Would you mind clarifying what you mean for those of us who aren't 
> familiar 
> with Blender? It would help if you could specify the actual behavior, the 
> expected behavior, and how they differ. 
>
>  
blender is an art creation and mixing app, mostly used for 3d and video. 
its probably the 
last thing anyone would use qubes-os to run. https://www.blender.org

with fullscreen disabled in guid.conf, the expected behavior is that any 
app cant
go full screen. the actual behavior, is that blender does go full screen.

to replicate,
make sure fullscreen apps are disabled
in the fedora template vm: dnf -y install blender
restart appvm
in an appvm: blender
when it starts, press alt-f11

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

[qubes-devel] qubes 3.2rc2 blender can fullscreen when fullscreen is set to false

[pixel fairy]

run blender. press alt+f11
alt-tab still works. 

personally dont care. but, if someone really wants full screen disabled, 
this could be an issue.


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

Re: [qubes-devel] Implications of switching to Hardware Memory Virtualization for all AppVMs

[pixel fairy]

Just confirmed 3.2rc2 does not work in vmware-fusion. 

theres something ironic about a compartmentalization platform built on 
virtualization being so hard to run in virtualization.

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