[qubes-users] dispVM shuts down immediately after starting (I'm trying to run xterm)

['floasretch' via qubes-users]

On Qubes 4.0, when I try to start a dispVM, I get a popup notice that it's 
starting, then a popup that it started, then a popup that it halted. I get no 
error message, even when I specify --verbose:

[user@dom0 ~]$ qvm-run --verbose --autostart --dispvm=whonix-ws-dvm --service 
-- qubes.StartApp+xterm
Running 'qubes.StartApp+xterm' on $dispvm:whonix-ws-dvm
[user@dom0 ~]$

Is there a log somewhere to tell me what's going wrong?

-- 
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/cYnO-Vk2RuiJZhGOZg80tuu_ERnO0KGVuat06JeY2aZdUkiKGpn-Pf2ubPF3f2xcnJzar-t_qqnGyaD6M0dBmJPQo6xzcdiAyPPSk-bWwJU%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Post-install inability to create qube

[newpath7]

On Sunday, October 14, 2018 at 7:58:49 AM UTC-6, Chris Laprise wrote:
> On 10/12/2018 01:44 AM, 'awokd' via qubes-users wrote:
> > e on 10/12/18 5:37 AM:
> >> Hello,
> >>
> >> After completing install (for my first time), I was able to login.
> >>
> >> Going to the menu, "Create Qubes VM," getting the dialog box titled 
> >> "[Dom0] Create new qube," the Template select drop-down control only 
> >> has "default(none)," even if I select type Standalone rather than AppVM.
> >> Also, I don't see anything anywhere like work, personal and untrusted, 
> >> neither sys-net or sys-usb. /var/lib/qubes/vm-templates has a debian 
> >> and fedora folder, but it seems like these are not available when 
> >> trying to create qubes via CLI via qvm-create. journalctl all show an 
> >> AssertionError.
> >> Any ideas?
> > 
> > Did you receive any errors on the first post-install boot? There's a 
> > step there that is supposed to configure all those templates. Is it 
> > possible you skipped it? Otherwise, often a misbehaving network device 
> > causes sys-net creation to break, which then causes the rest to fail to 
> > get created. In that case, try disabling your wifi card temporarily, 
> > then reinstalling. You can re-enable it afterwards and add it back to 
> > your sys-net in Qube Settings/Devices.
> > 
> 
> Try 'sudo dnf list qubes-template*' to see a list of installed 
> templates. If there are none, try mounting the installation media, 
> locate a qubes-template*rpm file and install the rpm file directly. This 
> should be a lot less time-consuming than re-installing Qubes.
> 
> -- 
> 
> Chris Laprise, 
> https://github.com/tasket
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

I tried disabling wifi and reinstalling entire Qubes again (a 12 hour process 
on my USB 2.0 sticks) but ended up with same thing (actually, since I tried not 
creating root user this time, I had to manually start some services libvirtd 
relies on - had to add root user to qubes and libvirtd groups for that to work, 
and was finally back to the point, again, where the error is just default 
template missing).

The /var/lib/qubes directory had full pack of 2G+ of template and kernel files, 
and after tracing through python code to decode assertion errors, I was 
convinced something in the templates did not get completely installed or 
configured (ie in both full Qubes OS install instances). rpm -ihv 
Packages/q/qubes-templates (after mounting the installer) said templates were 
already installed, so I did an rpm --reinstall instead. Then instead of missing 
template error I started to get no default_kernel, so did similar to 
Packages/k/qubes-kernel and was finally able to select template in qube 
creation, and qvm-ls finally displayed more than just AdminVM. 
Now, I have to figure out how to configure sys-net and connect it to another 
VM, but this seems to be another matter (Salt, Networking and Template VM 
documents seem to cover that). BTW, rpm reinstall for both packages ended with 
errors, but the VM still launched.

Thanks for your suggestion - it helped a lot.

-- 
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/a72f03c3-700b-4458-8bac-c6362178d1ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 4.0 on high(er) end workstations?

[Yethal]

W dniu poniedziałek, 15 października 2018 18:14:26 UTC+2 użytkownik 
steve.coleman napisał:
> I had attempted to upgrade my HP machine at home to R4.0 a while back 
> and ran into a VT-d related message about reassignable interrupts not 
> being found, yet I do have the VT-d enabled in bios. I never had any 
> indication while running R3.2, or before, that there was any issue with 
> the VT-d functionality. No bios upgrades are available from the 
> manufacture and I can't really afford to be without a functional machine 
> should I need to spend time trying work out why, or to force an upgrade. 
> Since support for R3.2 will at some point be deprecated, I thought I 
> should start doing some investigation for some new hardware while I have 
> a chance and before I am pressured to move forward. If I stand up a new 
> machine I will be better able to investigate any issues on the older 
> machine later.
> 
> The selection of laptops looks good on the HCL, and there has been quite 
> a bit of discussion on various options. But it would appear that there 
> are very few Desktop machines on the Qubes 4.0 HCL list have been fully 
> tested and are green all the way across. In fact the one machine that is 
> green all the way across for R4.0 just happens to be my own HCL report, 
> for my work desktop system.  Even then its difficult to compare the 
> relative computational power that each entry has without searching for 
> each machines specs, one by one. The CPU identifier, if specified, might 
> give a relative ranking, thought the number or cores, ram, Ghz, and 
> disks are notably absent thus it hard to rank them.
> 
> Since my old and outdated Dell Optiplex 990 seems to be the only game in 
> town, I'm therefore stuck looking at the Dell Optiplex 7050, but then I 
> don't have any particular loyalty to Dell. I don't mind building a 
> system from scratch using a good motherboard, if I had to, but it seems 
> the motherboards listed on the HCL are even less well tested for R4.0 
> than the desktop systems are. Not a single board on that list is even 
> running R4.0!
> 
> So, I figured I should just ask here, What high end R4.0 systems work 
> for you? What Desktop systems are fairly high end (Cores, GB's DRAM, 
> ample disk storage bays, multiple monitors) that are working well under 
> R4.0?
> 
> Are there *any* systems with a tested TPM setup capable of the 
> Anti-Evil-Maid configuration that have not yet made it onto the HCL? Or 
> is it only laptops that are doing this? I could force a laptop work if 
> it is both dockable and can come with enough Dram/Disk space, but then I 
> would never undock it, and thus I would be paying big $$$ for something 
> I'm not even planning to use it for.
> 
> Oh, if there is something running good out there, and it passes all the 
> tests under R4.0, please consider helping to update the HCL with R4.0 
> machines that actually work! Its always nice to know which ones to 
> avoid, but knowing what works is a much better way to go.
> 
> Thank you for your consideration.
> 
> Steve.

I've been running 4.0 on a six-core i7 w/ 32GB of RAM and an nvme SSD. Runs 
perfectly aside from the very choppy GUI (but that's because of nvidia gpu 
being uncooperative, not because of the rest of the components). If you do 
decide to build workstation based on this config remember to buy an AMD card 
and not an Nvidia one. Runs pretty smoothly even with 20+ appvms open at once.

MB: Asrock x99 itx/ac
CPU: i7 6800K
RAM: Corsair Vengeance LPX 3000mhz 32GB
SSD: Samsung Pro 950 NVME 256GB
GPU: Nvidia GTX 750Ti (do not buy)

VT-x, VT-d, Interrupt Remapping works. Mobo has a TPM header. It also has a 
PS/2 port (extremely important in Qubes and often overlooked)

-- 
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/cbfa9837-e59f-4fbe-8c26-102a5d556560%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] UEFI boot problem

['awokd' via qubes-users]

Stephan Marwedel:
I have a Thinkpad T470p which is equipped with two SSDs. Archlinux is 
installed on one drive and Qubes on the other. I use the UEFI Boot Menu 
to switch between operating systems without using multi-boot from a boot 
manager. Qubes 4.0 runs very well on this machine.


Since the T470p is now supported by the Linux Firmware Vendor Service I 
did the last BIOS update from Archlinux using fwupdmgr. Everything went 
smoothly. Unfortunately, after the update I was no longer able to boot 
Qubes because the UEFI boot configuration for the second drive was 
somehow deleted.


How can one recover the UEFI boot environment of Qubes 4.0? I tried 
using the Qubes installer but there is no shell access to run 
grub-install or efibootmgr. Can I do it from the Archlinux drive or a 
Fedora boot media?


Yes, Fedora boot media should work. Try searching this list for 
"efibootmgr"- should get the magic string for it in there somewhere.


--
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/3d8598d3-00dd-f6ab-7ab9-3b1f81fcf727%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] dispVM shuts down immediately after starting (I'm trying to run xterm)

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Oct 15, 2018 at 07:03:50PM +, 'floasretch' via qubes-users wrote:
> On Qubes 4.0, when I try to start a dispVM, I get a popup notice that it's 
> starting, then a popup that it started, then a popup that it halted. I get no 
> error message, even when I specify --verbose:
> 
> [user@dom0 ~]$ qvm-run --verbose --autostart --dispvm=whonix-ws-dvm --service 
> -- qubes.StartApp+xterm
> Running 'qubes.StartApp+xterm' on $dispvm:whonix-ws-dvm
> [user@dom0 ~]$
> 
> Is there a log somewhere to tell me what's going wrong?

The +xterm part should be a base name of .desktop file in
/usr/share/applications (or other directory per XDG standard). xterm on
Debian happens to have debian-xterm.desktop, so it should be
qubes.StartApp+debian-xterm.

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlvFB/wACgkQ24/THMrX
1ywowwf/bf65pAOtUDDGUHoyO0gyGtZ+yNDDJ4/64PmSF8bl3V3I4tU6QSoj1y/X
2fJnWWfO2bNm7iopizYConl+5msRZRhbY514vG/vJdhkLI1ZMiExUUoYSUqiO7tE
//oyX5CNW1L1egGVoxB4H6uv3bf6UrW9HfBEttIaKSpuaPg1PLagsMssPmyxUBBJ
oFcTn9iLI8LrMJR4bNXXatK94deD3NhXyRHZ26udKDi1nKmIq6N2zZIk5p8QuKrg
rhWbPawQj58I6oW7v5wFcO5d+wtSVGpOCJs5mhvlg/NAFVwohhQ+iHQDNL5CliKN
/6s0QsLbOJ7PJ0cKcpKXNVG9YA6a2Q==
=3FCa
-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/20181015213452.GB4138%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] how to switch Background Dom0 Qubes 4.0

[English USA]

how can I change the screen background of the official Qubes OS 4.? Please
help me, I am new to the IT world. maybe someone knows how to copy in Qubes
4 directly to Dom0 or connect the USB stick directly to Dom0? ask for
instructions with a detailed explanation. Thank you in advance !;)

-- 
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/CAGhU_PJA6GtF-fc7v-mT2d6fpejyaNBo677iO%2BLhp8Ekcr_KsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] dispVM shuts down immediately after starting (I'm trying to run xterm)

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Oct 15, 2018 at 11:19:54PM +, floasretch wrote:
> ‐‐‐ Original Message ‐‐‐
> On Monday, October 15, 2018 4:52 PM, Marek Marczykowski-Górecki 
>  wrote:
> 
> > > Same result with qubes.StartApp+debian-xterm
> > > Per your response, I verified that whonix-ws-dvm does have 
> > > /usr/share/applications/debian-xterm.desktop (and whonix-ws-dvm itself 
> > > starts and runs with no problem).
> >
> > I've tried the same command on my whonix-ws-14-dvm and it works...
> > Is your whonix-ws-dvm Whonix 13, or updated to Whonix 14?
> 
> Whonix 14. Originally was 13 (installed with Qubes 4.0), then updated when 14 
> was released.
> 
> I verified /etc/whonix_version in both whonix-ws and whonix-ws-dvm. They're 
> both 14.
> 
> BTW, I haven't been using disposable VMs at all for the past couple months, 
> so I have no idea whether my problem is recent or old. In fact, the last time 
> I did was with the Fedora DVM, and I've deleted it since then. Today was the 
> first time I ever tried using any DVM other than Fedora.
> 
> Qubes and all templates are fully updated.
> 
> Is there a log somewhere?

You can add --pass-io, to see service stdout/stderr. Maybe this will
give some hints.

Alternatively, you can try doing the same in non-disposable VM, for example
whonix-ws-dvm itself. Simply drop --dispvm and add VM name before
service name, like this:
qvm-run --service -- whonix-ws-dvm qubes.StartApp+debian-xterm

And see if xterm will launch. Then, you can inspect ~/.xsession-errors
in that VM, or various logs in /var/log. If no terminal is started at
all, you can access VM console with `sudo xl console whonix-ws-dvm`
(exit with Ctrl+]).

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlvFIsgACgkQ24/THMrX
1yyjIQf/Sp92zf8JWH+uydtWBzd9nlMjHBwlfPsV/nhCDK72ZbMMlVzb7kCP2OIE
oKkFO3IRTXvDbx/Yw1x1GG8Jkx/zH1inYsFU7KHJbPNUuOadq/rsp75gisKwzSqs
cDpTSXF00VjIpIYGYWHZQ4lqZp7IFenlXPBxfaxQdC7FnwWDw1J+vJHj04D6YtiS
62Fu2AyLrEibI5yTK4JRPcn1h3JV/e/L3Jor0ybOY9gYjNCzq2Rtf/wWCBHsBF/g
lHW7PBSBVJbvDF+sR+JoV50UUY3UIsn6Elq2cyS2/CkWA1hPIp12rtlRqMrtiXFt
9Pnu59dZWBiLSWcIldN4lCIreyHoaw==
=gaHd
-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/20181015232912.GL19709%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes / Xen i5 and i7 socket LGA1151 mobo recomendations

[taii...@gmx.com]

On 10/15/2018 12:38 PM, Aaron Gray wrote:
> Hi,
> 
> I have found my Intel based Z270 Motherboards do not support Qubes, or Xen as 
> of yet.

No consumer board will without difficulty.

> Therefore I am asking for suggestions for i5 and i7 socket LGA1151 DDR4 based 
> motherboards that will run Qubes / Xen; as a stop gap until they do.
> 
> Regards,
> 
> Aaron
> 

Why do you want that black box wintel junk?

Get a libre motherboard instead (see my recent post "Re: [qubes-users]
Qubes 4.0 on high(er) end workstations?" for info and very affordable
yet quality suggestions.

-- 
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/4b816481-88cf-6c07-7a61-24c6dbc4b715%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes Canary #17

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Qubes Community,

We have published Qubes Canary #17. The text of this canary is
reproduced below. This canary and its accompanying signatures will
always be available in the Qubes Security Pack (qubes-secpack).

View Qubes Canary #17 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-017-2018.txt

Learn about the qubes-secpack, including how to obtain, verify, and read
it:

https://www.qubes-os.org/security/pack/

View all past canaries:

https://www.qubes-os.org/security/canaries/

```
---===[ Qubes Canary #17 ]===---


Statements
- ---

The Qubes core developers who have digitally signed this file [1]
state the following:

1. The date of issue of this canary is October 15, 2018.

2. There have been 43 Qubes Security Bulletins published so far.

3. The Qubes Master Signing Key fingerprint is:

427F 11FD 0FAA 4B08 0123  F01C DDFA 1A3E 3687 9494

4. No warrants have ever been served to us with regard to the Qubes OS
Project (e.g. to hand out the private signing keys or to introduce
backdoors).

5. We plan to publish the next of these canary statements in the first
two weeks of January 2019. Special note should be taken if no new canary
is published by that time or if the list of statements changes without
plausible explanation.

Special announcements
- --

None.

Disclaimers and notes
- --

We would like to remind you that Qubes OS has been designed under the
assumption that all relevant infrastructure is permanently
compromised.  This means that we assume NO trust in any of the servers
or services which host or provide any Qubes-related data, in
particular, software updates, source code repositories, and Qubes ISO
downloads.

This canary scheme is not infallible. Although signing the declaration
makes it very difficult for a third party to produce arbitrary
declarations, it does not prevent them from using force or other
means, like blackmail or compromising the signers' laptops, to coerce
us to produce false declarations.

The news feeds quoted below (Proof of freshness) serves to demonstrate
that this canary could not have been created prior to the date stated.
It shows that a series of canaries was not created in advance.

This declaration is merely a best effort and is provided without any
guarantee or warranty. It is not legally binding in any way to
anybody. None of the signers should be ever held legally responsible
for any of the statements made here.

Proof of freshness
- ---

$ date -R -u
Mon, 15 Oct 2018 12:56:41 +

$ feedstail -1 -n5 -f '{title}' -u 
https://www.spiegel.de/international/index.rss
Merkel's Bavaria Headache: Berlin Coalition Emerges Even Weaker
A European IMF: The New Face of the Eurozone Bailout Fund
Social Design Award: Vote For Your Favorite Neighborhood Project
Rape Allegations: Ronaldo's Defense Team Develops a Strategy
Operation Mekong: China Solidifies Its Influence in Southeast Asia

$ feedstail -1 -n5 -f '{title}' -u 
https://rss.nytimes.com/services/xml/rss/nyt/World.xml
‘Our Hands Can Reach You’: Khashoggi Case Shakes Saudi Dissidents Abroad
Brazil Edges Toward Bolsonaro as a ‘Last Resort’ Leader
How to Attract a Killer Tigress? Try a Man’s Cologne
Kim Jong-un Invites Pope Francis to North Korea
Bulgarian Journalist, Host of Anticorruption TV Show, Is Raped and Killed

$ feedstail -1 -n5 -f '{title}' -u https://feeds.bbci.co.uk/news/world/rss.xml
Jamal Khashoggi: Turkey to search Saudi consulate in Istanbul
France weather: Red alert as flash floods kill 13 in south-west
Buckethead the bear cub's head freed from jar after three days
Hostage held at Cologne main train station
China star detained for 'anthem insult'

$ feedstail -1 -n5 -f '{title}' -u http://feeds.reuters.com/reuters/worldnews
Jordan and Syria reopen Nassib border crossing
U.S. still aiming to cut Iran oil sales to zero, market well-supplied: U.S. 
envoy for Iran
Saudi king orders probe in Khashoggi case, Turkey to search consulate
Bavaria election shakes Merkel's coalition, far-right rejoices
Merkel vows to regain trust after conservative losses in Bavaria


$ python3 -c 'import sys, json; 
print(json.load(sys.stdin)['\''blocks'\''][10]['\''hash'\''])'
$ curl -s 'https://blockchain.info/blocks/?format=json'
00201919eaab0aa9d10b9f1458d84f60434533d7cb915192

Footnotes
- --

[1] This file should be signed in two ways: (1) via detached PGP
signatures by each of the signers, distributed together with this
canary in the qubes-secpack.git repo, and (2) via digital signatures
on the corresponding qubes-secpack.git repo tags. [2]

[2] Don't just trust the contents of this file blindly! Verify the
digital signatures!
```

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2018/10/15/canary-17/

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS

Re: [qubes-users] Qubes Warrant Canary Overdue

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/15/18 10:26 AM, giantessgnos...@gmail.com wrote:
> This might seem like a serious thing to say, but Canary 16 has
> expired, and I'm getting worried, as I do rely on Qubes.
> 
> What's going on? Is there a comprimise or not?
> 

Sorry about that! The truth is that everyone got really busy and just
forgot (and also forgot to make a calendar reminder for it before
that). The new canary (#17) is up now.

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlvFNZ4ACgkQ203TvDlQ
MDAR7hAAxbVo6nlK0+rWHkMVgU+FXnVgnzHLvU3Xdzlazz1KroSXcFRhUOJO4Ecv
KEJfyaYg7RvKJ8YD1wgBoO8QjwynZcSSd/0eQoRqXGO0SMicShIX6nCzj26ZQoic
5WRhLFthK/TFkqjoypk4pqFQQPxsDNFMnIQYc49np9fGbxJdyZsyFxGwuWjqLOXk
srZu4U8JhaS7s7jJrCQ4byc5m15BSB4vnR3satL+fkggaWQlAQa2VN7OR3DDpAQI
iBcXzgsegXWKuZ3HSPLOypeOf0A0NQI6Qt3c/NWO+4O9e/jexj4AvWqO8e95zBQx
BG8vEpEKZ171eRdxKOT3kEGWkKmmvsnqu4EbzYtug85TmNx54FkTdy9y9gawJd3h
TOvvvbRhtKYdTM/vfYKiaV1wW0wa2PQZPUnBZd8vxask4EJKbAyfnyiTDCSmwQv6
+Pbf2SQx613evcCHzEB/+vHfqc5aExx+MU0J3A2T1dBvrOeTzeDK9tXdtWQvBieG
aIxR9d13VeB1fPoSNrbWctY/Gm3cawk6jLdImenc6PNUrch33IaHcgTlBI1qzMVm
xdjkpNPo3OqZDJckTIpj7FEa0mRnELWlhbPo1nPAfPfOGo19M4Uobx+z+IWYvyIk
9KN9YPbbTjeT7hVmEV8CcvBSFBb2YDKHO1VyIjLNygc2t1VJnvE=
=Dab4
-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/5a48e1f1-9c5c-4c35-e89e-fced95d29f65%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes 4.0 on high(er) end workstations?

[taii...@gmx.com]

On 10/15/2018 02:09 PM, Yethal wrote:> It also has a PS/2 port
(extremely important in Qubes and often overlooked)
Misinformation.

You instea dwant more than one USB controller on a system so you can
have both trusted for keyboard/mice and untrusted for random stuff (all
my recs in my other reply have this, the D16/D8's have a second
controller via a few onboard usb headers)

PS/2 is not secure at all - your keystrokes are outputted on the ground
wire.

I suggest purchasing a usb keyboard that doesn't have firmware such as
the excellent us made unicomp model m mechanical keyboard, to prevent
use of a keyboard virus.

Definitely agreed with not buying nvidia junk though, they artificially
hamper virt with their geforce stuff and they also hate linux drivers
and FOSS.

-- 
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/a0badb09-b836-05d4-d370-98110a27fe72%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] dispVM shuts down immediately after starting (I'm trying to run xterm)

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Oct 15, 2018 at 10:41:45PM +, floasretch wrote:
> ‐‐‐ Original Message ‐‐‐
> On Monday, October 15, 2018 3:34 PM, Marek Marczykowski-Górecki 
>  wrote:
> > > [user@dom0 ~]$ qvm-run --verbose --autostart --dispvm=whonix-ws-dvm 
> > > --service -- qubes.StartApp+xterm
> > > Running 'qubes.StartApp+xterm' on $dispvm:whonix-ws-dvm
> > > [user@dom0 ~]$
> > > Is there a log somewhere to tell me what's going wrong?
> >
> > The +xterm part should be a base name of .desktop file in
> > /usr/share/applications (or other directory per XDG standard). xterm on
> > Debian happens to have debian-xterm.desktop, so it should be
> > qubes.StartApp+debian-xterm.
> 
> Same result with qubes.StartApp+debian-xterm
> 
> Per your response, I verified that whonix-ws-dvm does have 
> /usr/share/applications/debian-xterm.desktop (and whonix-ws-dvm itself starts 
> and runs with no problem).

I've tried the same command on my whonix-ws-14-dvm and it works...
Is your whonix-ws-dvm Whonix 13, or updated to Whonix 14?

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlvFGhgACgkQ24/THMrX
1yx0vwgAlI5BIB+VuC+ibNcPQdFhPXzJm7X0YNEV0T8Ex03sbmeLcEfWe5JKpLII
KMSQIIkGtGfVcRAZwnllv18HNls1KxLdXFb3yER/XXAnm89aQcM1IfUmcpT2Eggs
mM1YcdXR5fqPKolZZSujTF3mFJBx2QEqnjyPrrSAvPfUFSiljy6cM5Eab+BxVfUV
TyX6BztEEKFUEZtErPM07QXLmIpLT6Q8QHA/7UInYdJj56Ih8u6dqvR4xyhHIwkV
17lZFtnvIaX5F3Zja2YR9gPyXRCti+Zpyt9PSi7pIaAdjy3h0BVNIUnSQTiiaS7t
maVT8bm/+VMVt0O8lLzXwXuN7QNDaA==
=OgQw
-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/20181015225209.GK19709%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0 on high(er) end workstations?

[taii...@gmx.com]

I have many posts on this but since you have an .edu and made a long
post yourself here are two great options.

You wanna assemble stuff yourself which is pretty easy - I did my first
at age 12 and it worked on the first power on.

Libre motherboards that work with qubes 4:

* KCMA-D8 (90 used on fleabay from china) and one or two 8 core socket
C32 4386 opteron CPU's plus ECC RDIMM RAM in 8GB sticks (for 64 total)
or 16gb (for 128 total)

* KGPE-D16 ($130 on fleabay brand new) and one or two 16 core 6386 CPU's
or 8 core 6328 CPU's (60 on fleabay brand new) which supports up to
192GB RAM.

Since they support libre firmware it doesn't matter that you are getting
used hardware although I believe newegg still has the KGPE-D16 if you
must have new hardware.

Both support Crossfire xDMA and IOMMU-GFX for gaming or cad in a VM, all
the devices have their own IOMMU groups and it supports ACS.

The D8 and D16 are the last and best owner controlled x86 motherboards
and they support coreboot-libre or libreboot, and also OpenBMC for
secure libre remote access with the ASMB4 or ASMB5 chip - it comes with
the new in box KGPE-D16 but they also crop up time to time on fleabay
for a few bucks.

I would say that TPM's/AEM is a not needed if you implement
kernel/initramfs code signing in grub as a coreboot payload, set the
write lock bit on the flash chip and then put a lock on your case but if
you still want a TPM it has a header for a v1.2 device make sure to buy
a supported model.

Other options are the Raptor Computing Systems Libre Firmware OpenPOWER
systems such as the TALOS 2 and the more affordable Blackbird which are
the future of owner controlled computing[1] although currently qubes/xen
doesn't have a POWER port so you would have to use POWER-KVM which
arguably is better security wise than xen+black boxed x86 junk and again
is the future not a dead platform.

I am an expert on this topic, let me know if you need any help and if
you think my advice is patron-grade.

[1]x86 is dead freedomwise, both AMD and intel have a variety of
anti-features that make you just a licensee not an owner - OpenPOWER is
the only owner controlled performance CPU arch luckily it is now more
affordable than equivilant x86 performance enterprise hardware and you
get more features+freedom :D

It is impossible to disable ME/PSP or make libre firmware for a new gen
x86 system.

-- 
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/febf11d7-74fe-63fc-142a-02f3ae7009a7%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] dispVM shuts down immediately after starting (I'm trying to run xterm)

['floasretch' via qubes-users]

‐‐‐ Original Message ‐‐‐
On Monday, October 15, 2018 4:52 PM, Marek Marczykowski-Górecki 
 wrote:

> > Same result with qubes.StartApp+debian-xterm
> > Per your response, I verified that whonix-ws-dvm does have 
> > /usr/share/applications/debian-xterm.desktop (and whonix-ws-dvm itself 
> > starts and runs with no problem).
>
> I've tried the same command on my whonix-ws-14-dvm and it works...
> Is your whonix-ws-dvm Whonix 13, or updated to Whonix 14?

Whonix 14. Originally was 13 (installed with Qubes 4.0), then updated when 14 
was released.

I verified /etc/whonix_version in both whonix-ws and whonix-ws-dvm. They're 
both 14.

BTW, I haven't been using disposable VMs at all for the past couple months, so 
I have no idea whether my problem is recent or old. In fact, the last time I 
did was with the Fedora DVM, and I've deleted it since then. Today was the 
first time I ever tried using any DVM other than Fedora.

Qubes and all templates are fully updated.

Is there a log somewhere?

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

Re: [qubes-users] dispVM shuts down immediately after starting (I'm trying to run xterm)

['floasretch' via qubes-users]

‐‐‐ Original Message ‐‐‐
On Monday, October 15, 2018 5:29 PM, Marek Marczykowski-Górecki 
 wrote:
> You can add --pass-io, to see service stdout/stderr. Maybe this will
> give some hints.

vchan connection timeout

LOL. I changed qrexec-timeout for whonix-ws-dvm to 120 (from default of 60), 
and that fixed it.

Thanks.

A bit disturbing that 60 seconds isn't enough, though. It's a reasonably modern 
system. Intel Core i3 (Haswell generation) with 16GB RAM, and not overloaded. 
(CPU and disk are idle until I start the DVM, and not too many qubes are 
running.)

-- 
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/H8gakPcWZ7TBrGWs5t2gX_9m6WZGbi9XnmvpWjnzMnHM8ITc-SIMd_j0rkEgtwP9VsIAt6a7VrFx4tMZPOUP1mgUOaSQHjCFeUP-qr-YykU%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Cannot open anything from templateVM/appVM after moving to 4.x

[Teqleez Motley]

Hi all, I suspect that I need to change the "Main Qubes update repository"
of templateVMs that originates from Qubes 3.x?

I have exported both templateVMs and stand-alone appVMs from 3.2,
and restored them seemingly successfully on 4.x as far as the
backup/restore process is concerned.

Now, I can actually run updates from the Qubes Manager (GUI) on both the
templateVMs and the stand-alone appVM, but I cannot open any windows from
them.
Cannot even open terminal in the templateVM. When trying, nothing happens
other than the VM is started and showing green status, and remains open
until I shut it down from the Qubes Manager.

I think that the file /etc/apt/sources.list.d/qubes-r3.list needs to be
updated/replaced.
I can see in the terminal window that appears briefly during updates (it
closes afterwards, and is not possible to edit/enter), that it queries

"http://deb.qubes-os.org/r3.2/vm stretch main"

, which I would assume is not the correct one when running that templateVM
on 4.x, right?

So; Is there a dom0 command that can fix this on a running templateVM
without having a native Terminal?

Regards,

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

Re: [qubes-users] Guide: Monero wallet/daemon isolation w/qubes+whonix

[mk]

> 
> If you are using gateway sys-whonix then all of your traffic is always
> using Tor.

Ok ! I had begun to doubt..

> Not sure what you mean about "make it work", but I'm having some
> stalling/connection issues[1][2] on the newly released version (v0.13.0).

Sorry, I was meaning "syncing".
 
> At first connection issues were solved by adding torsocks to monerod
> when using Whonix gateway or binding p2p ip to 0.0.0.0 if not using a
> Whonix gateway. Next I started to experience stalls, which I still
> haven't found a solution for yet.
> 
> [1] https://github.com/monero-project/monero/issues/4468
> [2] https://github.com/monero-project/monero/issues/4469

Exactly the same issue.
Running monerod with torsocks was working for me too.

-- 
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/dfca17b2-fb2d-4828-8b17-273276a9bfd4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes 4.0: Device Widget disappeared

[fabrizio]

On Friday, October 12, 2018 at 7:13:56 AM UTC+2, awokd wrote:
> fabri...@statebox.io wrote on 10/11/18 9:40 AM:
> > On Friday, May 4, 2018 at 5:05:45 PM UTC+1, gaxi...@gmail.com wrote:
> >> The system tray device widget is not visible anymore. It was there after a 
> >> fresh 4.0 install but disappeared after some days. How can i get it back?
> > 
> > Bad news!: After today's Dom0 update, I got exactly this problem. Trace is 
> > the same as reported above. I never encountered it before. Is there 
> > something I can do?
> 
> Looks like that's a recent bug that has already been fixed: 
> https://github.com/QubesOS/qubes-issues/issues/4386, so the device 
> widget should reappear after the next round of updates.

I updated from the qubes-dom0-current-testing repo but the problem is still 
there :( 

-- 
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/a4eb20b6-d7a7-4eaf-b907-feb1c04a929e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Tails does not connect to the network

[Teqleez Motley]

Hi all, I have followed the instructions here:
https://www.qubes-os.org/doc/tails/

But on Qubes 4.x I cannot seem to make it connect to the network.
I can start Tails fine, and change the Wired network connections, also make
new profile, but it does not connect when I use the info provided from dom0
with the "qvm-ls -n Tails" command.

I have tried both with dynamic DNS but static IP, and with setting the DNS
to the same IP as the gateway, as also is suggested in the documentation.

(I am using the default (sys-firewall) as the network connection.)

Apart from that main problem, a couple of related questions:
It seems that:
a) No way to make these settings stick, so the network must be reconfigured
on each Tails start, is that correct?
b) No way to make the AppVM remember the ISO file as the starting point;
each time either have to locate it manually in the GUI, or (re-)use a
command in dom0 to start it?

Regards,

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

Re: [qubes-users] traveling change time how ?

[unman]

On Sun, Oct 14, 2018 at 12:30:00AM +, Vasilis wrote:
> Hi,
> 
> reby:
> > I guess it should be evident but apparently not ?  I've changed the timezone
> > manually on the taskbar to the new TZ  , however I see that when I update a
> > Template it is still using my home TZ not my current TZ
> > 
> > 
> > what are the steps to correctly change to a new TZ  when travelling with 
> > Q4.0
> > and a laptop  please ?
> 
> 
> You should be able to change the timezone with the `timedatectl` tool in dom0.
> An example to set the system timezone Europe/London:
> 
> # sudo timedatectl set-timezone 'Europe/London'
> 
> For time changes to take effect in other VMs be sure to restart them after
> updating the time or perhaps there is a better that I'm unaware of.
> 
> 
> Cheers,
> ~Vasilis


In KDE you do this by R-click on clock widget and selecting "Adjust
Date and Time",or from System Settings.
On my 4.0 that *does* update the time in templates and qubes, as one
would expect. And that has always been the case. I don't know why this
wouldn't work for you, reby. 

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

[qubes-users] vault color (black?) & window decorations

[brendan . hoar]

Hi folks,

Regarding the default R4 color scheme...

...does anyone else find that the default color for vault (black?) makes it 
nearly impossible to see the window titles and/or windows controls (close, 
maximize, minimize)? 

Why does that color scheme set the window title (and controls) to dark 
text/controls on a dark background?

Thanks,
Brendan

-- 
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/56cdcaa2-841d-42b6-9418-b951c8bddd90%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Using an OnlyKey

[John Maher]

On Friday, October 12, 2018 at 1:17:37 AM UTC-4, awokd wrote:
> g80vmgm...@riseup.net wrote on 10/12/18 5:07 AM:
> > John Maher:
> >> I have an OnlyKey and have been unable to figure out how to make use of it 
> >> in Qubes OS 4.0.
> >>
> >> Relevant info:
> >>
> >> * OnlyKey requires either its app being opened on the computer or one's 
> >> ability to go to https://apps.crp.to (simply via a browser) in order to 
> >> set its time.
> >> * I used info from this page 
> >> https://www.qubes-os.org/doc/usb/#how-to-use-a-usb-keyboard to get the 
> >> OnlyKey to operate as a USB keyboard. Doing this resulted in the OnlyKey 
> >> being attached to sys-usb and outputting text (password info) in dom0 and 
> >> any other qube.
> >> * Although the OnlyKey can output like a USB keyboard in any qube, it 
> >> cannot get its time set without being specifically attached to an appVM 
> >> that either has the OnlyKey app or can access https://apps.crp.to, so TOTP 
> >> will not function.
> >> * Using the yellow drop down icon to attach the OnlyKey to a qube that has 
> >> the app results in (1) the time on the OnlyKey being set, and (2) the 
> >> OnlyKey no longer working as a USB keyboard anywhere.
> >> * Detaching from the qube does not restore the OnlyKey's ability to 
> >> function as a USB keyboard.
> >>
> >> Short of installing the OnlyKey app in sys-usb, is there anything else I 
> >> can try? (And I don't even know if that would work.)
> >>
> >> Even if I decided it was ok to install the app in sys-usb, sys-usb is 
> >> based on Fedora, and OnlyKey only has a deb package. Installing on Fedora 
> >> has proven to be very problematic.
> >>
> >> Thanks for any help you can provide.
> >>
> >> John
> >>
> > 
> > Hi John,
> > 
> > I don't have an OnlyKey and unfortunately probably can't really help you
> > to debug the issues with it not being able to act again as an HID device
> > after attaching it directly to a VM.
> > 
> > However, you can absolutely use a Debian-based VM as your sys-usb qube;
> > just install the Debian 9 template and set your sys-usb qube to use it
> > as its template.  Also make sure the qubes-usb-proxy package is installed.
> > 
> > As for the HID issues, I do have one suggestion: have you tried not only
> > detaching the device from the AppVM, but also physically removing the
> > USB device and re-inserting it?
> 
> No OnlyKey either, but I think it is possible to have two USB 
> "keyboards" in Qubes if you edit the file described here: 
> https://www.qubes-os.org/doc/usb/#r32-manual.

Thanks for your responses. I figured out a solution.

I figured out a way to use OnlyKey with Qubes OS. I suspect I've violated some 
basic security principles relative to how Qubes is intended to be used, but I 
accept the compromise, which I think (hope) is minimal.

Because an OnlyKey needs a time source in order for its TOTP feature to 
function, either the OnlyKey app (standalone or Chrome extension) or navigating 
to https://apps.crp.to, after the OnlyKey is inserted into a USB port, need to 
be available. In Qubes, I discovered that inserting the OnlyKey (and unlocking 
it with the PIN) and attaching it to the appVM where I want to use it resulted 
in the OnlyKey not functioning as a keyboard, which is needed to do its job. In 
dom0, adding this line to the top of /etc/qubes-rpc/policy/qubes.InputKeyboard 
(see https://www.qubes-os.org/doc/usb/#how-to-use-a-usb-keyboard) allowed the 
OnlyKey to operate as a keyboard in all VMs (without attaching the OnlyKey to a 
VM):

  sys-usb dom0 allow,user=root

However, to use TOTP it still needed access to the app or to 
https://apps.crp.to. But, again, when I attached the OnlyKey to an appVM, the 
OnlyKey stopped functioning as a keyboard, even when I detached it from the 
appVM.

So, I did the following:

1. Temporarily provided Internet access to sys-usb.
2. Opened Chrome and installed the OnlyKey extension.
3. Disabled the sys-usb VM's Internet access.

Now, after inserting the OnlyKey and entering its PIN, I can open the OnlyKey 
Chrome app (which does not need Internet access to function), resulting in the 
OnlyKey getting its time set. Because of the previous edit of 
"qubes.InputKeyboard", the OnlyKey functions as a keyboard and all is well.

I'm happy to hear comments or cautions regarding this.

John

-- 
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/2e34c68f-8488-4188-a2f2-a6e5e68ad118%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Moving Qubes R4 between two machines on regular basis

[brendan . hoar]

Hi folks,

My understanding is that modern linux distros *mostly* perform device 
configuration on boot (as opposed to during installation) with the exception of 
X11 configuration and passing custom kernel parameters (e.g. blacklisting 
problematic hardware). Correct me if I am wrong about this.

So...

1. If a user wants to use a single boot device (e.g. a single SSD) on a 
workstation, move it to a laptop for travel, then move it back to the 
workstation on return...how feasible is this?

2. Besides likely having to create custom scripts to detect and swap X11 
configurations, for GPU or display size, what else would likely end up being 
issues to resolve that are not addressed by boot-time driver assignment?

3. Does feasibility increase if the user chose the workstation/travel laptop 
pair based on the same (or similar) manufacturer, chipset and CPU family?

Thanks,
Brendan

-- 
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/99555446-a726-4e0d-9372-ae7a8765ecea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Networking between qubes and HVMs

[unman]

On Thu, Oct 11, 2018 at 06:02:55PM -0700, jmarkdavi...@gmail.com wrote:
> I guess to further clarify what I want to try to do is have sys net be 
> connected to the interface that is connected to my modem(to the ISP/world). 
> 
> I would like another vm to control all(or some) other 
> physical interfaces on my machine (access points/etc..).
> 
> I would like a qubeVM from within the machine running qubes to be able to 
> connect via those physical interfaces as if they were also attached to the 
> physical interface.
> 
> Ideally so that the qubes OS is segregating physical NICs along with 
> applications.
> 
> So lets say FreeNAS is running inside qubes. And someone near my access point 
> wants to use freeNAS via wifi, they would log in via ssh or whatever over the 
> access point.
> 
> But if that same someone is somewhere else they can ssh or whatever to 
> freeNAS via the internet and the wan NIC that sys-net controls.
> 

That makes it much clearer to me. Thanks.

There are a number of different ways to approach this, but the one that
seems easiest would be something like this:

sys-net -- sys-fw -- freeNAS
  |   -- qube1
  |   -- wifi -- qube2

wifi is set up to "provide network" - ie it's a NetVM, and acts as
access point via attached wifi.

Setting up access via sys-net to freeNAS is straightforward, and already
documented, as you know. I suggest you get that working first.

Provisioning the wifi qube should be straightforward. 
You will need to set up the wifi access point, and then configure port
forwarding to freeNAS. sys-fw should be the default route set on wifi
qube. Depending on whether you want downstream clients (like qube2) you
may want to change this.
You will need to set fw rules to allow traffic between these vif
interfaces.
You will need to adjust routes to ensure that traffic arriving at
freeNAS via wifi does not get sent out via sys-net. The simplest way to
achieve this will be to use source NAT on wifi, or Masquerade, depending
on your configuration.

Note that qube2 can connect EITHER to freeNAS port OR to external IP of
sys-net. If you don't want this, either have no qubes connected
downstream of wifi, or adjust fw on wifi to block traffic from all vif
interfaces to eth0.

If you need help with the details, just ask.

unman

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

Re: [qubes-users] Moving Qubes R4 between two machines on regular basis

['awokd' via qubes-users]

brendan.h...@gmail.com:

Hi folks,

My understanding is that modern linux distros *mostly* perform device 
configuration on boot (as opposed to during installation) with the exception of 
X11 configuration and passing custom kernel parameters (e.g. blacklisting 
problematic hardware). Correct me if I am wrong about this.

So...

1. If a user wants to use a single boot device (e.g. a single SSD) on a 
workstation, move it to a laptop for travel, then move it back to the 
workstation on return...how feasible is this?


Expect similar to most distributions, like Debian, but haven't done 
frequently.



2. Besides likely having to create custom scripts to detect and swap X11 
configurations, for GPU or display size, what else would likely end up being 
issues to resolve that are not addressed by boot-time driver assignment?


I could see EFI boot being an annoyance. If the mobile SSD is the only 
"fixed" disk on both laptop and workstation, that would be an easier 
scenario because in that case there's only a single EFI partition. Might 
have to rerun efibootmgr on the device not used for install. Hardware 
behaviour with multiple EFI partitions seems to be undefined and/or 
implemented poorly. Legacy boot on both would be simpler, but:



3. Does feasibility increase if the user chose the workstation/travel laptop 
pair based on the same (or similar) manufacturer, chipset and CPU family?


If using legacy boot, you'll want to make sure the SSD presents as the 
same boot device/sequence on both; for example /dev/sda0. Having similar 
designs etc. should also help simplify this.


That's my thoughts at least.

--
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/37a89226-7eef-43e7-7d25-6d8d103d13fa%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes 4.0: Device Widget disappeared

['awokd' via qubes-users]

fabri...@statebox.io:

On Friday, October 12, 2018 at 7:13:56 AM UTC+2, awokd wrote:

fabri...@statebox.io wrote on 10/11/18 9:40 AM:

On Friday, May 4, 2018 at 5:05:45 PM UTC+1, gaxi...@gmail.com wrote:

The system tray device widget is not visible anymore. It was there after a 
fresh 4.0 install but disappeared after some days. How can i get it back?


Bad news!: After today's Dom0 update, I got exactly this problem. Trace is the 
same as reported above. I never encountered it before. Is there something I can 
do?


Looks like that's a recent bug that has already been fixed:
https://github.com/QubesOS/qubes-issues/issues/4386, so the device
widget should reappear after the next round of updates.


I updated from the qubes-dom0-current-testing repo but the problem is still 
there :(


Probably best to mention that on issue 4386, if it's not resolved.

--
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/ee8eb3f1-1139-6b20-9e3f-96f6526b3735%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] vault color (black?) & window decorations

['awokd' via qubes-users]

brendan.h...@gmail.com:

Hi folks,

Regarding the default R4 color scheme...

...does anyone else find that the default color for vault (black?) makes it 
nearly impossible to see the window titles and/or windows controls (close, 
maximize, minimize)?

Why does that color scheme set the window title (and controls) to dark 
text/controls on a dark background?

Have noticed it but it hasn't bothered me enough yet to change it! I 
think there's an issue somewhere out there mentioning it.


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3ecd9488-1a42-db4f-42b9-316d7de541d0%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Cannot open anything from templateVM/appVM after moving to 4.x

['awokd' via qubes-users]

Teqleez Motley:

Hi all, I suspect that I need to change the "Main Qubes update repository"
of templateVMs that originates from Qubes 3.x?

I have exported both templateVMs and stand-alone appVMs from 3.2,
and restored them seemingly successfully on 4.x as far as the
backup/restore process is concerned.

Now, I can actually run updates from the Qubes Manager (GUI) on both the
templateVMs and the stand-alone appVM, but I cannot open any windows from
them.
Cannot even open terminal in the templateVM. When trying, nothing happens
other than the VM is started and showing green status, and remains open
until I shut it down from the Qubes Manager.

I think that the file /etc/apt/sources.list.d/qubes-r3.list needs to be
updated/replaced.
I can see in the terminal window that appears briefly during updates (it
closes afterwards, and is not possible to edit/enter), that it queries

"http://deb.qubes-os.org/r3.2/vm stretch main"

, which I would assume is not the correct one when running that templateVM
on 4.x, right?

So; Is there a dom0 command that can fix this on a running templateVM
without having a native Terminal?

>
There are multiple steps to using 3.2 templates on 4.0. You found a 
couple of them, but see 
https://github.com/Qubes-Community/Contents/blob/master/docs/system/restore-3.2.md 
for some more.


--
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/2154e478-ed43-7fc7-3409-4e16069a9b7d%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Guide: Monero wallet/daemon isolation w/qubes+whonix

[qubenix]

> Exactly the same issue.
> Running monerod with torsocks was working for me too.
> 

Check my comment here:
https://github.com/monero-project/monero/issues/4468#issuecomment-429671939

Running monerod like that from systemd or the command line (with or
without --non-interactive doesn't matter, only with systemd needs it) is
the best experience I've had with it on Whonix in years.

-- 
qubenix
PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
OTR: qube...@chat.freenode.net
OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765

-- 
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/d28d837a-6120-c54a-52cf-91b363f24fe8%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How to see what Qubes is doing during boot?

[unman]

On Thu, Oct 11, 2018 at 10:00:51PM +0300, Ivan Mitev wrote:
> 
> 
> On 10/11/18 9:45 PM, 'floasretch' via qubes-users wrote:
> > Booting Qubes 4.0 on a five-year-old Core i3 laptop, it always sits for 
> > several minutes with a grey screen, white Q logo, and slowly advancing 
> > progress bar. Is there some textual boot report I can watch instead, to see 
> > why it takes so long?
> 
> hiting the `esc` key when you see the grey screen should switch to text.
> Alternatively you can boot without the 'quiet' option (edit the kernel
> options when you're presented with the grub menu at boot).
> 
> A long startup time is usually the consequence of (auto)starting many VMs.
> 

Hitting the L-R arrows toggles between graphical and text boot.

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

Re: [qubes-users] Re: If you get "no authenticators available" with mutt

[unman]

On Sun, Oct 14, 2018 at 09:01:25AM -0700, rbhlin...@gmail.com wrote:
> On Friday, February 9, 2018 at 11:02:21 PM UTC+5:30, Konstantin Ryabitsev 
> wrote:
> > If you are trying to use mutt with the default Fedora-26 template and 
> > can't figure out why authenticated smtp sending is giving you a "No 
> > Authenticators Available" error, you need to install cyrus-sasl-plain.
> > 
> > Drove me half-mad before I figured that out. Hopefully it saves you a 
> > bunch of clicks (and hair).
> > 
> > -K
> 
> Any reason as to why installing this package worked?
> 

SASL is a protocol that provides an authentication framework. (Simple
Authentication and Security Layer)
It's commonly used in email protocols, SMTP, IMAP, POP etc.
The cyrus-sasl-plain package provides a library which implements that
protocol.

If you are trying to use authenticated smtp, you must have some way of
providing that authentication - sending your username/password to
the SMTP server. cyrus-sasl gives you a framework that lets you do
it.
Why cyrus? It was developed for cyrus IMAP server
-https://www.cyrusimap.org

Why plain? Because it doesn't provide a secure method of authentication.
It's meant to be used where something else is encrypting the traffic.

Why isn't it included with mutt? My guess is that it's because until
quite recently mutt couldn't send mail. It handed off sending to a MTA,
so didn't need to bother about the mechanism of how mail would be sent.

unman

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

Re: [qubes-users] Changing USB Controllers

[unman]

On Sun, Oct 14, 2018 at 04:54:05PM -0400, Alex Winter wrote:
> The laptop I have is a MSI WT70 20K.  I have 5 USB ports total on it. Three
> USB3 ports and two USB2 ports.
> 
>  I have tryed making a sys-usb from the default settings and it crashes the
> install(probably because qubes is installed on a usb and its grabbing all
> the USB controllers).   Installing without sys-usb works without any issues.
> 
> following these instructions
> https://www.qubes-os.org/doc/assigning-devices/#finding-the-right-usb-controller
> i am seeing that all the ports I plug a USB storage device in use the same
> controller as my qubes OS (dom0) which is the XHCI controller.
> 
> 
> On Wed, Oct 10, 2018, 10:18 AM unman  wrote:
> 
> > On Mon, Oct 08, 2018 at 07:27:23PM -0700, Alex Winter wrote:
> > > Here are the usb controllers when I type in 'sudo lspci -v'
> > >
> > > 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
> > Family USb xHCI (Rev 05) (prog-if 30 [XHCI])
> > >  Subsystem: Micro-Star International Co., Ltd. [MSI] Device 10ec
> > >  Flags: bus master, medium devsel, latency 0, IRQ 57
> > >  Memory at f7b0 (64-bit, non-prefetchable) [size=64k]
> > >  Capabilities: [70] Power Management version 2
> > >  Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
> > >  Kernel driver in use: xhci_hcd
> > >  Kernel modules: xhci_pci
> > >
> > > 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
> > Family USb EHCI #2 (Rev 05) (prog-if 20 [EHCI])
> > >  Subsystem: Micro-Star International Co., Ltd. [MSI] Device 10ec
> > >  Flags: bus master, medium devsel, latency 0, IRQ 16
> > >  Memory at f7b18000 (32-bit, non-pcopy and pasterefetchable) [size=1k]
> > >  Capabilities: [50] Power Management version 2
> > >  Capabilities: [58] Debug port: BAR=1 offset=00a0
> > >  Capabilities: [98] PCI Advanced Features
> > >  Kernel driver in use: ehci-pci
> > >  Kernel modules: ehci_pci
> > >
> > > 00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
> > Family USb EHCI #1 (Rev 05) (prog-if 20 [EHCIReciever])
> > >  Subsystem: Micro-Star International Co., Ltd. [MSI] Device 10ec
> > >  Flags: bus master, medium devsel, latency 0, IRQ 23
> > >  Memory at f7b17000 (32-bit, non-prefetchable) [size=1k]
> > >  Capabilities: [50] Power Management version 2
> > >  Capabilities: [58] Debug port: BAR=1 offset=00a0
> > >  Capabilities: [98] PCI Advanced Features
> > >  Kernel driver in use: ehci-pci
> > >  Kernel modules: ehci_pci
> > >
> > > when I type in 'sudo lsusb -v' Here are the buses.
> > >
> > > Bus 002 Device 002: ID 8087:8000 Intel Corp.
> > >
> > > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > > iProduct 2 EHCI Host Controller
> > > iSerial  1 :00:1d.0
> > >
> > > Bus 001 Device 002: ID 8087:8008 Intel Corp.
> > >
> > > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > > iproduct 2 EHCI Host Controller
> > > iSerial  1 :00:1a.0
> > >
> > > Bus 004 Device 002: ID 04e8:61f5 Samsung Electronics Co., Ltd
> > >
> > > Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> > > iProduct 2 xHCI Host Controller
> > > iSerial  1 :00:14.0
> > >
> > > Bus 003 Device 007: ID 1770:ff00
> > >
> > > Bus 003 Device 005: ID 8087:07dc Intel Corp.
> > >
> > > Bus 003 Device 004: ID 045e:00e1 Microsoft Corp. Wireless Laser Mouse
> > 6000 receiver
> > >
> > > Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > > iProduct 2 xHCI Host Controller
> > > iSerial  1 :00:14.0
> > >
> >
> > Without knowing your laptop or exact setup I'm working a bit blind.
> > I think you say you have a usbVM and are running qubes from a USB stick
> > - is that right?
> > You haven't said *which* controller your ports all use.
> >
> > From the listing it's clear you have usb2 and usb3 controllers, and it
> > may be that ALL your ports are 2/3. More info needed please.
> > I'll throw out some wild suggestions:
> >
> > Hide one of the controllers on the kernel command line(say the xhci).
> > Disable ehci in usbVM, and use only USB3 devices with the usbVM.
> >
> > It might be possible to delete one of the devices in dom0, and still have
> > it available in qubes. (I mean literally rm /dev/bus/usb/001)
> >
> > You could unbind a pci device early in boot. I've done this with Xen
> > before, to have one port in dom0 and the rest available to xen-pciback,
> > but haven't tried it with Qubes.
> >
> > You could use udev to block two of the ports in dom0, so that they are
> > only available in the usbVM.
> >
> > unman
> >

Hi Alex

There's something strange here because the two ports on the right hand
side should definitely be USB2, so should not use xhci at all. If they
are all using the same controller, what's the point in shipping both?

Since you are booting from USB, you probably want to keep Qubes running
from USB3. I had thought that you could mask the USB2 controllers from
dom0, but if all your ports are using xhci as you report, that 

[qubes-users] Qubes / Xen i5 and i7 socket LGA1151 mobo recomendations

[Aaron Gray]

Hi,

I have found my Intel based Z270 Motherboards do not support Qubes, or Xen as 
of yet. Therefore I am asking for suggestions for i5 and i7 socket LGA1151 DDR4 
based motherboards that will run Qubes / Xen; as a stop gap until they do.

Regards,

Aaron

-- 
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/2137accb-4dd0-4d00-8469-0f12a89968ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] UEFI boot problem

[Stephan Marwedel]

I have a Thinkpad T470p which is equipped with two SSDs. Archlinux is 
installed on one drive and Qubes on the other. I use the UEFI Boot Menu 
to switch between operating systems without using multi-boot from a boot 
manager. Qubes 4.0 runs very well on this machine.


Since the T470p is now supported by the Linux Firmware Vendor Service I 
did the last BIOS update from Archlinux using fwupdmgr. Everything went 
smoothly. Unfortunately, after the update I was no longer able to boot 
Qubes because the UEFI boot configuration for the second drive was 
somehow deleted.


How can one recover the UEFI boot environment of Qubes 4.0? I tried 
using the Qubes installer but there is no shell access to run 
grub-install or efibootmgr. Can I do it from the Archlinux drive or a 
Fedora boot media?


Any hints are appreciated.

Regards,

Stephan

--
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/35e3ea4d-2f2a-fa8e-0d3d-2e6748002271%40jucara.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes 4.0 on high(er) end workstations?

[Steve Coleman]

I had attempted to upgrade my HP machine at home to R4.0 a while back 
and ran into a VT-d related message about reassignable interrupts not 
being found, yet I do have the VT-d enabled in bios. I never had any 
indication while running R3.2, or before, that there was any issue with 
the VT-d functionality. No bios upgrades are available from the 
manufacture and I can't really afford to be without a functional machine 
should I need to spend time trying work out why, or to force an upgrade. 
Since support for R3.2 will at some point be deprecated, I thought I 
should start doing some investigation for some new hardware while I have 
a chance and before I am pressured to move forward. If I stand up a new 
machine I will be better able to investigate any issues on the older 
machine later.


The selection of laptops looks good on the HCL, and there has been quite 
a bit of discussion on various options. But it would appear that there 
are very few Desktop machines on the Qubes 4.0 HCL list have been fully 
tested and are green all the way across. In fact the one machine that is 
green all the way across for R4.0 just happens to be my own HCL report, 
for my work desktop system.  Even then its difficult to compare the 
relative computational power that each entry has without searching for 
each machines specs, one by one. The CPU identifier, if specified, might 
give a relative ranking, thought the number or cores, ram, Ghz, and 
disks are notably absent thus it hard to rank them.


Since my old and outdated Dell Optiplex 990 seems to be the only game in 
town, I'm therefore stuck looking at the Dell Optiplex 7050, but then I 
don't have any particular loyalty to Dell. I don't mind building a 
system from scratch using a good motherboard, if I had to, but it seems 
the motherboards listed on the HCL are even less well tested for R4.0 
than the desktop systems are. Not a single board on that list is even 
running R4.0!


So, I figured I should just ask here, What high end R4.0 systems work 
for you? What Desktop systems are fairly high end (Cores, GB's DRAM, 
ample disk storage bays, multiple monitors) that are working well under 
R4.0?


Are there *any* systems with a tested TPM setup capable of the 
Anti-Evil-Maid configuration that have not yet made it onto the HCL? Or 
is it only laptops that are doing this? I could force a laptop work if 
it is both dockable and can come with enough Dram/Disk space, but then I 
would never undock it, and thus I would be paying big $$$ for something 
I'm not even planning to use it for.


Oh, if there is something running good out there, and it passes all the 
tests under R4.0, please consider helping to update the HCL with R4.0 
machines that actually work! Its always nice to know which ones to 
avoid, but knowing what works is a much better way to go.


Thank you for your consideration.

Steve.




--
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/8f8fcf40-1024-61ec-d63d-43f068d511d7%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Fedora 28 has no audio on Qubes!

[unman]

On Mon, Oct 15, 2018 at 03:50:45PM +, mmo...@disroot.org wrote:
> Hi Everyone,
> 
> I've just updated my template to Fedora 28 and although everything is working 
> fine. It seems that sound is not working by any means (each VM based on 
> Fedora 28 is not even listed in the volume control). In all the previous 
> versions of Fedora this was working fine.
> Having a appvm with no audio it's a no deal for me.
> 
> Is there a way to have audio working on Fedora 28 ?
> 
> Thank you.
> 
> Moris
> 

There was an issue with pulseaudio in Fedora28, bit an updated package
was shipped in August. Can you check you've completely updated the
template and have pulseaudio-qubes installed?

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

Re: [qubes-users] Thoughts on Salt in Qubes in practice?

[Kushal Das]

On Mon, Jul 2, 2018 at 12:13 PM Marek Marczykowski-Górecki
 wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Mon, Jul 02, 2018 at 05:17:31PM +0200, Johannes Graumann wrote:
> > Would there be possibilities to bring a in my experience much more
> > approachable ansible option closer to the core and integrate it into
> > the code base overseen by Invisible Things? Maybe by contracting Rudd-
> > O?
>
> I think yes. But someone would need to implement it. Having Ansible as
> first-class citizen in Qubes requires:
>
> 1. Direct integration with Admin API / qvm-* commands / qubesadmin python
> module, instead of converting ansible -> salt -> qvm-* commands.
> Generally make managing VMs with Ansible independent of Salt. Admin API
> allows to do all that from selected VM, instead of dom0 (as it was
> before Qubes 4.0).
>
> 2. Make VM management more isolated - namely do not parse complex data
> returned from managed VM. Displaying success/fail info and a text
> message should be ok, but an interactive protocol is not.
> Salt (namely: salt-ssh) provides a method to package all the
> required configuration into a single tarball, which then can be send
> and executed - this was AFAIR one of main reasons why we've chosen Salt.
> But later it turned out making that tarball needs some input from "remote"
> system ("grains" - things like what OS is there, various tools versions etc), 
> so
> we've added an intermediate DispVM which gets all salt configuration,
> ask target VMs for "grains", then create a tarball and sends it there.
> Each target VM have own DispVM for that created on demand.
> This way if anything compromise the code parsing "grains" (or any
> related structure), it will not gets an access to neither dom0, nor
> other VMs. See relevant ticket[1] for design discussion about this.
> We need something with similar properties for Ansible. If there is a
> mode with uni-directional communication with target VM, it should be
> enough, otherwise a similar scheme as for Salt needs to be done.
>
> Manuel, would you be interested in working on this?
>
Over the weekend I actually thought over the problem, and wanted to have
something as close as possible to the upstream Ansible for the same.

The result is is availble at [1]. This has three major things.

1. One *qubes* connection plugin for Ansible
   This allows dom0 and any domU (with proper policy) to do things
 inside of a VM. Means installing packages, copy/fetch files etc.

I have also opened a PR to the upstream Ansible to add this in the
core.

2. To make 1 happen, I added a small qrexec service *qubes.Ansible*.
To do things from dom0, we only need that service in the target AppVMs
or templates. There is also a command line tool (basically service
name changed from
qvm-run-vm command) *qvm-ansible* which will be used by domU VMs to connect
and do things inside of other VMs.

3. A pure Python Ansible module (named: qubesos) to
create/destroy/manage state of the
VMs.

Now, for now I have tested point 3 only from dom0. Point was tested
from both dom0 and domU VMs.

The Python module will require a lot of other things to make it 100%
compatible with
standard qvm*/qubes-* tools.

I have added examples in the repo. I managed to ran random playbooks
(which I use
in other places) using this. I would love to have feedback on this.

Note: This does not use Salt anywhere.

[1] https://github.com/kushaldas/qubes_ansible


Kushal
--
Staff, Freedom of the Press Foundation
CPython Core Developer
Director, Python Software Foundation
https://kushaldas.in

-- 
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/CAAzeMbzH5Z%2BQY_J%3DVRoxHCCP1yGR9QV_tSVAV66w6JFni%3DE4dQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes Warrant Canary Overdue

[giantessgnostic]

This might seem like a serious thing to say, but Canary 16 has expired, and I'm 
getting worried, as I do rely on Qubes.

What's going on? Is there a comprimise 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/d3cfa815-4fa5-4d4b-a4ed-b7541744b877%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Fedora 28 has no audio on Qubes!

[mmoris]

Hi Everyone,

I've just updated my template to Fedora 28 and although everything is working 
fine. It seems that sound is not working by any means (each VM based on Fedora 
28 is not even listed in the volume control). In all the previous versions of 
Fedora this was working fine.
Having a appvm with no audio it's a no deal for me.

Is there a way to have audio working on Fedora 28 ?

Thank you.

Moris

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

Re: [qubes-users] dispVM shuts down immediately after starting (I'm trying to run xterm)

['floasretch' via qubes-users]

‐‐‐ Original Message ‐‐‐
On Monday, October 15, 2018 3:34 PM, Marek Marczykowski-Górecki 
 wrote:
> > [user@dom0 ~]$ qvm-run --verbose --autostart --dispvm=whonix-ws-dvm 
> > --service -- qubes.StartApp+xterm
> > Running 'qubes.StartApp+xterm' on $dispvm:whonix-ws-dvm
> > [user@dom0 ~]$
> > Is there a log somewhere to tell me what's going wrong?
>
> The +xterm part should be a base name of .desktop file in
> /usr/share/applications (or other directory per XDG standard). xterm on
> Debian happens to have debian-xterm.desktop, so it should be
> qubes.StartApp+debian-xterm.

Same result with qubes.StartApp+debian-xterm

Per your response, I verified that whonix-ws-dvm does have 
/usr/share/applications/debian-xterm.desktop (and whonix-ws-dvm itself starts 
and runs with no problem).

-- 
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/1YkWrPit5VaYwhB41JfX0zXdYL78wu_VH4f6ucS3TI68kkjWctOT2K5Pp4y8-FADu7_G75LmEku-FAAWqzVmo6hiJeOIOlzZru4NA8B0bLA%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] how to switch Background Dom0 Qubes 4.0

[Steve Coleman]

On 10/15/18 6:45 PM, English USA wrote:
how can I change the screen background of the official Qubes OS 4.? 


Right click on the desktop and from the menu select "Desktop Settings"

Please help me, I am new to the IT world. maybe someone knows how to 
copy in Qubes 4 directly to Dom0 or connect the USB stick directly to 
Dom0? ask for instructions with a detailed explanation. Thank you in 
advance !;)


To mount a USB stick in dom0, insert the USB stick, and then open up 
nautilus in Dom0 (Menu/System Tools/Files) and look on the left pane for 
your USB stick. If you do not see a label for it there, the stick may be 
formatted in exFat format which may need some extra drivers in dom0 in 
order to read it.


Be very cautious what you allow to attach to or run in dom0.



--
You received this message because you are subscribed to the Google 
Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to qubes-users+unsubscr...@googlegroups.com 
.
To post to this group, send email to qubes-users@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAGhU_PJA6GtF-fc7v-mT2d6fpejyaNBo677iO%2BLhp8Ekcr_KsQ%40mail.gmail.com 
.

For more options, visit https://groups.google.com/d/optout.


--
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/de880228-1436-14f4-c3f7-2cc6cce6d0a3%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] dispVM shuts down immediately after starting (I'm trying to run xterm)

['floasretch' via qubes-users]

‐‐‐ Original Message ‐‐‐
On Monday, October 15, 2018 4:52 PM, Marek Marczykowski-Górecki 
 wrote:

> > Same result with qubes.StartApp+debian-xterm
> > Per your response, I verified that whonix-ws-dvm does have 
> > /usr/share/applications/debian-xterm.desktop (and whonix-ws-dvm itself 
> > starts and runs with no problem).
>
> I've tried the same command on my whonix-ws-14-dvm and it works...
> Is your whonix-ws-dvm Whonix 13, or updated to Whonix 14?

Whonix 14. Originally was 13 (installed with Qubes 4.0), then updated when 14 
was released.

I verified /etc/whonix_version in both whonix-ws and whonix-ws-dvm. They're 
both 14.

BTW, I haven't been using disposable VMs at all for the past couple months, so 
I have no idea whether my problem is recent or old. In fact, the last time I 
did was with the Fedora DVM, and I've deleted it since then. Today was the 
first time I ever tried using any DVM other than Fedora.

Qubes and all templates are fully updated.

Is there a log somewhere?

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