[qubes-users] Introducing: Qubes Video Companion v1.0

['Elliot Killick' via qubes-users]

Hello, everyone!

Starting this past early September, I've been working on and off to
create a new tool for secure webcam integration in Qubes OS out of
/absolute necessity/ for remote work at both my (new) job and school at
the university I'm newly attending. The tool is called Qubes Video
Companion and I'm proud to announce that it's evolved far past that
basic requirement and at version 1.0.4 is now publicly available for
testing!

Before resorting to the creation of an entirely new project, I thought
of many other potential solutions for allowing me to use a webcam in
Qubes but all of them fell flat in one way or another, to list them all
(skip through this list if you're not up for too much reading, haha):

1. Do video conferencing in the sys-usb qube with the webcam device attached

Unfortunately, the desktop I run Qubes OS on doesn't have a sys-usb qube
due to complications of its hardware. The primary issue being that I
require a USB sound card which has to stay attached to dom0 where the
other Qubes audio components are. Not to mention, this solution is also
far from being optimal from a security standpoint particularly because I
also use a USB mouse and keyboard meaning I would essentially have to
hand over control of those devices to sys-usb. This leaves the door open
for keyboard injection into dom0 thereby compromising it (and the entire
system) in the case sys-usb is compromised due to, for example, a bug in
the video conferencing software. This also means enabling networking
(removing the air gap) for sys-usb which again is harmful to security.

Note that I don't personally consider not having a sys-usb qube for
protecting dom0 from physical USB device attacks as much of a security
issue because my desktop is always at home which is outside of my threat
model.

2. Do video conferencing in any qube with qrexec+usbip (with a sys-usb
qube; can't be done from dom0)

Even disregarding my personal hardware issues above, qrexec+usbip is a
mess to get working and does poor on performance according to this
GitHub issue: https://github.com/QubesOS/qubes-issues/issues/4035.
Although, I've never been able to test it out myself. Additionally, the
security concerns of using TCP/IP and USBIP between qubes is there. This
also remotely exposes the webcam firmware which is yet another security
risk with this configuration.

3. Do video conferencing in any qube with a bought USB hub PCI card

This also means taking on all the security risks of attaching that
physical hardware directly to the VMs which considering they are to run
applications I don't trust such as Zoom (which my job requires; I
wouldn't use Zoom given the choice of course) — doesn't sit well with me
at all. Plus, hot swapping PCI devices, though supported by Xen, is
disabled in Qubes because of what a complex operation it is
security-wise leaving the door open to bugs (I read this was the reason
somewhere I think in the Qubes mailing list I think). This means that in
order to use my webcam on different qubes (my "school" and "work" qubes
for my purposes) I would have to reboot them each time to attach and
remove the USB hub with my webcam plugged into it. This would be very
inconvenient for my use case particularly when I'm trying to get work
done efficiently. I thought about combining my school and work qubes
into just one qube but at that point why am I even bothering to use
Qubes OS if I don't utilize its most basic security feature. Lastly, I
could also buy multiple USB hub PCI cards but that was just too hacky
for me.

4. Do video conferencing in any qube with FFmpeg for streaming video

At the time, there were preliminary outlines of a working solution for
webcam video streaming with FFmpeg. While this was a good start, it just
didn't cut it for my needs. The resolution was very low (when I tried to
raise it to 1920x1090 it didn't work) and even with that low resolution
the latency was below optimal and it just tore up my CPU power when I
needed it the most; hence this too was not a realistic solution. Plus,
FFmpeg isn't available in Fedora without adding RPM Fusion repo due to
patent issues which was just one more little gripe I had with it. And to
top it off, FFmpeg doesn't exactly have an amazing security track record...

5. Dual booting and other OSs

Finally, as a very last resort (not being able to use my webcam wasn't
an option for me), I thought about dual booting (way too inconvenient
not to mention the security downfalls) and (just for a very brief moment
for the sake of completeness) other OSs. However, I have already
contributed one project (qvm-create-windows-qube) to Qubes OS and have
now been "locked in" to the Qubes ecosystem (haha) by fantastic features
such as Qubes Split GPG, a great community as well as countless other
qualities and would feel insecure running any other operating system.

As far as using a webcam in Qubes OS went, I needed something that /just
worked/, I needed — Qubes Video Companion. And that's how t

Re: [qubes-users] qvm-create-windows-qube 2.0

['Elliot Killick' via qubes-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2020-02-11 04:55, paulos elias wrote:
> Hey Elliot,
>
> I used your script to install windows and it worked like champ. Great
work really! I was a little upset that QWT doesn't support speaker and
usb devices passthrough. I know that is not what your script is supposed
to do but I was just wondering if there exist, at all, some tweak I can
do to make that work. I just thought it doesn't hurt to ask. Sorry to
bother but do have any trick?

Late response⁠⁠⁠—I'm aware, but, if you're still interested then info on
that is available here:

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

Also, for future reference please keep the mailing list CC'd in.
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQQBj7nebfoT+xj7VVL5uQ1E+D3V8gUCXruqwwAKCRD5uQ1E+D3V
8m91AP9DZxMf+E0PVzzjZJ7ZyqxGcNGgeDYDaRuxSpJVe/yc/AEA0mtZ0mfFXZED
TwD8CTeF9MW923/Xc/A4AFkKB3Z/FAo=
=ewcx
-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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b67316f8-c678-e605-a2bd-5e65ac374969%40zohomail.eu.

Re: [qubes-users] What's your flow for new templateVM?

['Elliot Killick' via qubes-users]

On 2020-05-12 15:23, unman wrote:
> On Mon, May 11, 2020 at 08:46:25PM +, 'Elliot Killick' via qubes-users 
> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On 2020-05-11 14:26, 'Ryan Tate' via qubes-users wrote:
>>> Saw the new f31 templateVM (thanks for that) and just curious how
>> folks generally migrate to a new templateVM.
>>> I manually maintain this big text list of packages and just use
>>> that
>> to manually update the fresh templateVM to what I need. There's
>> typically also some non package installs, which I include basic pointers
>> for (think downloaded rpms and so forth), as well as some outside repos
>> to add (e.g. keybase). There's also typically some packages I forgot to
>> put on the list, which I can usually suss out by going through the bash
>> history for the old template, although often there's one or two that
>> slip through the cracks, which I find out about eventually and it's not
>> a huge deal.
>>> I'm particularly curious if anyone does anything more
>>> sophisticated
>> than that, using salt or some other automated deploy system to prep new
>> template images.
>>> Thanks for any tips!
>>>
>> I also keep a list of packages I want to have on each of my templates.
>> For the switching part of each AppVM to the new TemplateVM (e.g.
>> fedora-30 to fedora-31) I use a simple Python script that utilizes the
>> Qubes Admin API:
>>
>> #!/usr/bin/python3
>>
>> import qubesadmin
>> from qubesadmin.exc import *
>>
>> from_templatevm = 'fedora-30'
>> to_templatevm = 'fedora-31'
>>
>> qubes = qubesadmin.Qubes().app.domains
>>
>> for qube in qubes:
>> if qube.name == from_templatevm:
>> appvms = qube.appvms
>> for appvm in appvms:
>> print('Changing TemplateVM of:', appvm.name)
>> try:
>> appvm.__setattr__('template', to_templatevm)
>> except QubesVMNotHaltedError:
>> print("Cannot change TemplateVM while qube is turned on!
>> ")
>>
>> I usually just run this after my next reboot when almost (don't forget
>> to shutdown the NetVMs) all my qubes will be turned off. This is much
>> better than switching them manually one by one in Qubes Manager.
>>
> Just for the record there's a GUI tool to do this.
> System->ManageTemplates in Qube Manager
>
Huh, I've seen that before but I guess I kind of forgot about it!

Thanks, unman.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b0af88bd-d42c-941d-9011-92a57f5c9f4f%40zohomail.eu.

[qubes-users] [Solution] Fix Screen Tearing for Chromium-Based Browsers on Qubes

['Elliot Killick' via qubes-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, I just thought I would share the solution I found to my screen
tearing problem for Chromium-based browsers on Qubes.

First, test if you are experiencing screen tearing in Chromium by
watching this video in full screen (You should see only straight
vertical lines going across the screen; no rips):
https://www.youtube.com/watch?v=MfL_JkcEFbE

If you are, then what fixed it completely for me was going to:
chrome://flags/#ignore-gpu-blacklist
And then enabling:
"Override software rendering list"
Description:
"Overrides the built-in software rendering list and enables
GPU-acceleration on unsupported system configurations.  Mac, Windows,
Linux, Chrome OS, Android
#ignore-gpu-blacklist"

Then watch that video again to confirm the fix was successful. Worked
like a charm with my Intel iGPU at least.

If that doesn't fix it then I recommend going to:
chrome://gpu
and seeing what you can tweak in there.

I tested each and this fix worked for me in Chromium, Brave Browser,
Iridium Browser and (just to top it off) Google Chrome.

I think the culprit in the Chromium source is this line at:
https://chromium.googlesource.com/chromium/src/gpu/+/master/config/software_rendering_list.json#355
Seems strange but for some reason my "GPU0" is detected as "VENDOR=
0x [VMware, Inc.]" (you would think it would say Xen?) in
chrome://gpu after enabling #ignore-gpu-blacklist (Before it was
"VENDOR= 0x [Google Inc.]"), it also has the "Mesa" driver vendor
with version >= 9.2.1 and is of course running on "Linux", all of which
falls in line with that entry in the software_rendering_list.json file.

I kept digging by looking at the "cr_bugs" field in the JSON file and at
first was alarmed because the first one listed (#145531
) was a
UAF security bug that was closed as "Wont Fix". However, I tried all the
PoCs and none of them produced a crash for me with #ignore-gpu-blacklist
enabled so I think it's safe and adding this GPU driver to the blacklist
is just a precaution the Chromium team took. Then I went through the
other cr_bugs listed and sure enough others were reporting it doesn't
seem like this bug exists anymore and that it does appear to be safe
now. I've had the #ignore-gpu-blacklist enabled for a while now and have
experienced no instability.

No such fix should be necessary for Firefox as it came out of the box
with no screen tearing for me.

Note, this is only a fix for screen tearing in Chromium-based browsers.
If you're experiencing screen tearing elsewhere like on your desktop too
then it's probably something you need to change in you xorg.conf in Dom0.

And as a side note, if your browser fails to play some videos, that is
due to it not supporting some formats which can be diagnosed at a site
such as:
https://tekeye.uk/html/html5-video-test-page

Anyway, this ended up being longer than expected. Hope it helped a
fellow Qubes user. :)
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQQBj7nebfoT+xj7VVL5uQ1E+D3V8gUCXrm7qwAKCRD5uQ1E+D3V
8hv6AP447YQfhWVF5kMl6mEddg3Bm2tjKsujgaSg18UAh1ulHQEAvffT9yTzDueS
iAwa1HcGnTAlrio4aLZ/lo59iFEHtwU=
=Gw26
-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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ba2897b5-2bd1-b7a1-7052-2e680d497600%40zohomail.eu.

Re: [qubes-users] What's your flow for new templateVM?

['Elliot Killick' via qubes-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2020-05-11 14:26, 'Ryan Tate' via qubes-users wrote:
> Saw the new f31 templateVM (thanks for that) and just curious how
folks generally migrate to a new templateVM.
>
> I manually maintain this big text list of packages and just use
> that
to manually update the fresh templateVM to what I need. There's
typically also some non package installs, which I include basic pointers
for (think downloaded rpms and so forth), as well as some outside repos
to add (e.g. keybase). There's also typically some packages I forgot to
put on the list, which I can usually suss out by going through the bash
history for the old template, although often there's one or two that
slip through the cracks, which I find out about eventually and it's not
a huge deal.
>
> I'm particularly curious if anyone does anything more
> sophisticated
than that, using salt or some other automated deploy system to prep new
template images.
>
> Thanks for any tips!
>
I also keep a list of packages I want to have on each of my templates.
For the switching part of each AppVM to the new TemplateVM (e.g.
fedora-30 to fedora-31) I use a simple Python script that utilizes the
Qubes Admin API:

#!/usr/bin/python3

import qubesadmin
from qubesadmin.exc import *

from_templatevm = 'fedora-30'
to_templatevm = 'fedora-31'

qubes = qubesadmin.Qubes().app.domains

for qube in qubes:
if qube.name == from_templatevm:
appvms = qube.appvms
for appvm in appvms:
print('Changing TemplateVM of:', appvm.name)
try:
appvm.__setattr__('template', to_templatevm)
except QubesVMNotHaltedError:
print("Cannot change TemplateVM while qube is turned on!
")

I usually just run this after my next reboot when almost (don't forget
to shutdown the NetVMs) all my qubes will be turned off. This is much
better than switching them manually one by one in Qubes Manager.

After that all I do is clone, for example, fedora-30-dvm to
fedora-31-dvm with its template now changed.


-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQQBj7nebfoT+xj7VVL5uQ1E+D3V8gUCXrm5oQAKCRD5uQ1E+D3V
8qS/AQCtW8COW7f2ndgpDTAJD/VYRzfqgo333UeR7EmcC1JKqAD+O0Jh2Z3tseRn
cmEcBRFQyOYmPjvGCdHfq/Ypnj66VQo=
=9oMW
-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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b2444535-cd8c-ca3c-274e-e16f024e54b0%40zohomail.eu.

Re: [qubes-users] Re: qvm-create-windows-qube 2.0

['Elliot Killick' via qubes-users]

On 2020-01-26 12:37, Claudio Chinicz wrote:
> ׁHi Elliot,
>
> I've downloaded again and succeeded creating the HVM.
>
> I had a Windows 10 HVM I built manually just booting from the ISO and where 
> I did not succeed installing the QWT (boot after the QWT install would 
> freeze).
>
> Would you recommend building a Template from this HVM?
>
> The big advantage I saw in this implementation was that I can confortably 
> run my applications with 2GB (minimum) vs 6GB in my previous HVM. Another 
> advantage of the QWT is that I can send files from Windows to any other 
> PV/HPV VM using qrexec.
>
> What's intriguing me is that copy/paste between VMs is not working. When I 
> ctl+shift+C on my Windows VM I see the popup saying I can ctl+shift+V on 
> another VM but when I do so nothing is pasted. Any ideas?
>
> Thank you very much for this scripts/Windows VM builder.
>
> Regards

By freeze do you mean it stops on the part where QWT tries to create the
private disk? This is documented in the QWT Known Issues section of the
README. Just exit that window with the error message and the
installation will proceed as normal. Besides that for Windows 10/Windows
Server 2019, you should not have to interact with any window or part of
the installation. Sometimes, QWT may also just crash upon boot causing
Windows to crash. This doesn't happen often, however, it is also
documented in the README. This is more likely to happen if you installed
Windows manually as you said because unstable QWT features like Qubes
Memory Manager (qmemman) are enabled by default which we disable in the
qvm-create-windows-qube.sh script (Thanks to @brendanhoar for that one).

Due to that bug in making the private disk required, it's not possible
to create templates for Windows 10/Windows Server 2019 anyway.
Otherwise, I would recommend for must users to build a template with the
software they want pre-installed and make AppVMs from that.

Regarding copy/paste not working, it appears to work fine for others so
I would just suggest you restart the Windows qube or possibly make a new
one. If it's copying the data out correctly then there should be a
notification saying "Copied X bytes to the clipboard".

You're welcome, Claudio!


Regards,

Elliot



-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2de7254e-c22c-3275-cdfd-30cdacd86a67%40zohomail.eu.

Re: [qubes-users] Re: qvm-create-windows-qube 2.0

['Elliot Killick' via qubes-users]

On 2020-01-24 13:16, Claudio Chinicz wrote:
> Hi Elliot,
>
> I've followed the instruction, had to manually download win10x64.iso and
> when I ran the "./qvm-create-windows-qube.sh -n sys-firewall -oyp
> firefox,notepadplusplus,office365business -i win10x64.iso -a
> win10x64-pro.xml win10-work" command I got the following error:
>
> Error mounting /dev/loop2: GDBus.error:org.freedesktop.vdisk2.error
failed:
> error mounting /dev/loop2 at run/media/user/cccoma_x64fre_en-us_dv9:
wrong
> fs type, bad option, bad superblock on dev/loop2, missing codepage or
> helper program, or other error
>
> Any idea?
>
> Thanks


Yes, I believe I've gotten that error message before and it basically
means that the udisksctl command could not mount the ISO because the
filesystem is corrupted in some way. Where did you get the ISO from? If
you got if from the download-windows.sh script then make sure the
SHA-256 sum checks out with the one in the SHA256SUMS file. If the sums
don't match then just retry the download. The download-windows.sh script
will automatically verify the checksum.


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f5d05190-1ad5-24fc-8211-23f79cb7f40c%40zohomail.eu.

Re: [qubes-users] Re: qvm-create-windows-qube 2.0

['Elliot Killick' via qubes-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On 2020-01-23 23:10, Rafael Reis wrote:
> Wow. This is just outstanding.
>
> Just installed windows 10 pro (manually downloaded) and it went without a
> hitch. Only mistake I made was pressing no for the reboot prompt on the
> first VM boot, but I managed to work around it and the script picked up
> where it left off.
>
> Indeed the bugs mentioned on Readme.md are there. I had to take the steps
> to do the fixes, especially the cmd to load the gui, otherwise it
would not
> appear.
>
> Thank you very much for the incredible contribution. Let me know if I can
> debug / test anything, or help some other way.
>
>
> Em segunda-feira, 13 de janeiro de 2020 06:49:12 UTC-3, Elliot Killick
> escreveu:

>>

Thank you, Rafael. Glad it could help you! :)

If you're itching to test out something new then I just pushed a new
feature:

    - Followed (mainly) this Whonix documentation to create an
(unofficial) Windows-Whonix-Workstation that complies up to the "Even
more security" standard: https://www.whonix.org/wiki/Other_Operating_Systems

"Most security" is to use a default Whonix VM and build it from source.

And with that, another security/privacy improvement that further helps
in the isolating of Windows which is that the installation process is
now fully air gapped with the exception of installing any packages at
the very end (if any are desired). It was mostly air gapped before but
there was a small window of time during the "Completing setup of Qubes
Windows Tools..." where Windows had access to the Internet before
applying the disable telemetry script and now also the script for making
Windows into a Windows-Whonix-Workstation. Fixing this was not as simple
as just adding/removing the NetVM whenever due to Qubes Windows Tools
being a bit finicky. The solution I implemented was to use the Qubes
inbuilt Firewall to temporarily drop traffic which kept Windows securely
air gapped while still allowing QWT and packages to install fine.

Besides that just cleaning up a few things and a small bug here and there.

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQQBj7nebfoT+xj7VVL5uQ1E+D3V8gUCXi1FdQAKCRD5uQ1E+D3V
8p8UAP9IeLZUSpB+jOLt7QXHVzobnQPLhMwW4KhoHl1nKEWmFAEA8agqWjsuxBlP
LR8aEjtynsagALcGAAnktHFWmq3XFwA=
=35dc
-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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/57ca48b8-10b3-ddd4-e433-798326b446b0%40zohomail.eu.

Re: [qubes-users] Re: qvm-create-windows-qube 2.0

['Elliot Killick' via qubes-users]

On 2020-01-19 16:53, trueriver wrote:

> In version 4 of Qubes, the Debian templates need a little extra software to 
> run as templates for the sys-XXX Qubes. Best to is to pieced as if for the 
> minimal Debian template, and apt-install what's needed for the three sys-XXX 
> Qubes. Some of those packages are already installed but apt will just tell 
> you so, and install the missing ones

I'm a little lost. The windows-mgmt qube is not a "sys-XXX" qube and so
I'm not sure how "sys-XXX" qubes are relevant to what I said.

I have not tested qvm-create-windows-qube with a minimal template,
however, if you would like to do so then by all means go ahead. Just be
prepared to install some additional software manually. Just to clarify
for everyone, the only officially supported templates are fedora-30 and
debian-10.

Lastly, just to make sure I have all my ducks in a row, I have just
tested qvm-create-windows-qube with a fresh debian-10 template qube and
all seemed to work fine.


Thank you for your concern,

Elliot


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ccadaa73-9c3f-f0ea-843c-c6c08850efcd%40zohomail.eu.

Re: [qubes-users] Re: qvm-create-windows-qube 2.0

['Elliot Killick' via qubes-users]

On 2020-01-20 17:35, scall...@posteo.net wrote:
> I had installed Win10 Enterprise and everything was running well until
> I had to restart.
>
> Now I can't figure out how to get Windows GUI to appear. When I've
> installed Windows without this script I only have one menu option
> "Start" and that boots the Windows interface. With the install using
> this script I have three menu options: Command Prompt, Explorer,
> Internet Explorer. I can run any of those and the Win10 Qube starts,
> but there is no GUI interface for the selected app or for Windows in
> desktop in general. There is Qubes Settings. I thought this issue
> might be due to seamless mode, but clicking the button to disable it
> in Qubes Settings just gives me this error:

You'll be happy to know that the fixes to everything you just mentioned
are outlined in the README (appmenus and GUI).

Please read it. :)


Elliot


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0c950485-ea0d-688b-13ec-46b5727a0153%40zohomail.eu.

Re: [qubes-users] Re: qvm-create-windows-qube 2.0

['Elliot Killick' via qubes-users]

On 2020-01-15 01:36, shiftedreality wrote:

> You pointed me in the right direction. I was using Debian 10 as my default 
> Qubes template. 
Debian 10 is supposed to be supported as a template. I didn't realize
the Debian 10 template qube didn't come with cURL. Bug fixed, thanks for
catching 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/64c89ed3-c824-15e5-b0f5-055420eba578%40zohomail.eu.

Re: [qubes-users] qvm-create-windows-qube 2.0

['Elliot Killick' via qubes-users]

On 2020-01-17 13:25, M wrote:

> Can I create a Windows 10 Pro VM qube or does it have to be a Windows 10 
> Enterprise LTSC VM qube ?
>
Yes, Windows 10 Pro, Enterprise AND Enterprise LTSC are all supported.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/01511771-9e86-4991-ad43-83c0667cabe3%40zohomail.eu.

Re: [qubes-users] qvm-create-windows-qube 2.0

['Elliot Killick' via qubes-users]

On 2020-01-17 17:40, scall...@posteo.net wrote:
> Am I correct that the windows-mgmt qube is just for setting up the
Windows qube and can be deleted? Certainly keeping it would expedite
creating new Windows qubes in the future though.


Yes, that's correct. The windows-mgmt qube may be deleted afterwards if
you are sure that there are no more Windows qubes you would like to create.


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e3709038-e653-430b-38ee-10d298852b45%40zohomail.eu.

[qubes-users] qvm-create-windows-qube 2.0

['Elliot Killick' via qubes-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello, all!

Not too long ago I released qvm-create-windows-qube but quit pushing
changes for a while because I realized there was still a of work to be
done and I wanted to get it out of the dev/beta phase before releasing a
new version.

Well, it's over 200 commits later and I would say it's well out of
beta now.

Biggest new features include:

  * Use a much newer Windows 7 7601 ISO for Windows 7
  * Support Windows 8.1-10 Pro/Enterprise (ISO downloads from Microsoft
included)
  * Support Windows 10 Enterprise LTSC (Also download provided)
  * Support Windows Server 2008 R2 - Windows Server 2019 (Also downloads
provided)
  * Chocolatey integration
  * Option to slim down Windows installation (Similar to the following
but much more refined due to especially the disabling of services I
found could break things in a way that would result in a bad UX,
also expanded for Windows 10:
https://www.qubes-os.org/doc/windows-template-customization/)
  * Test signing Qubes GUI driver is now enabled during Windows
installation process to skip a reboot
  * Hardcoding trial product key in answer files (or anywhere) is no
longer necessary, Windows will use embedded trial key without any
user interaction by default
  * windows-mgmt is air gapped
  * Travis CI is being used for integration testing
  * Tons of code cleanup, reorganization and refactoring  (I'm of the
OpenBSD mindset where having clean (correct) code is just as
important as having functional code, so a lot of stuff just got
rewritten)
  * Everything is much more stable (No more lame sleeps for arbitrary
amounts of time)
  * MIT license

Additionally, I made a PGP key (also using Qubes Split GPG) so hopefully
my code and anything I else I make can reach you a lot more securely.

Repo can be found here, please star if you find it useful :)

https://github.com/elliotkillick/qvm-create-windows-qube

I'm working towards having this project be similar (or superior) to
VMWare's Windows "Easy Install" feature but on Qubes:
https://www.youtube.com/watch?v=1OpDXlttmE0

Regards,

Elliot
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQQBj7nebfoT+xj7VVL5uQ1E+D3V8gUCXhw9CQAKCRD5uQ1E+D3V
8iT9AQDlMN4TUEQV8SrvfBj3Df0utv3i/GIDLlt+6DpxnNmSAAD/Uz7tihtwjHXz
/Dl6qtbYhoph8DSHLKwIevhP/iKArw8=
=tnno
-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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/751f6bbd-087a-8d0d-70b9-1175e6f79d5d%40zohomail.eu.