Re: [qubes-users] Re: qrexec demon fails to load any VM when I attach any device

['awokd' via qubes-users]

On Mon, March 5, 2018 10:18 pm, Allen Larocque wrote:
> OK, we've made progress. However, I'm not sure why this change has
> happened.
>
> Now aplay -l sees two audio devices - one built-in, one HDMI.
>
>
> Dom[0] volume control now sees a 'built in audio Analog Stereo'
> (hardware) and 'Simultaneous output to built-in Audio' (virtual?).
>
>
> When sound is playing , the volume bars fluctuate as expected, but still
> no sound coming out.
>
> - A
>
>
>
> On Sunday, 4 March 2018 18:43:51 UTC-8, awokd  wrote:
>
>> On Mon, March 5, 2018 2:34 am, Allen Larocque wrote:
>>
>>
>>
>>> 00:1b.0 Audio device: Intel Corporation 7 Series/C216 Chipset Family
>>> High
>>> Definition Audio Controller (rev 04)
>>>
>>
>>> Kernel driver in use: snd_hda_intel
>>> Kernel modules: snd_hda_intel
>>>
>>
>> Looks like it loaded fine. In Dom0 volume control, is it selected as
>> your Output Device? Can't think of any other reason why it wouldn't show
>> in aplay -l.

My R3.2 system has similar issues with multiple HDMI audio devices. In my
case, I think it's sending it over DP to one of the monitors' headphone
jacks; haven't figured out a way to steer it where I want it to go.

In your case, again in dom0 volume control, scroll all the way to the
right to the Configuration tab and try setting it to different Profiles.
You may also need to assign individual VMs under Playback to the correct
audio adapter if it doesn't default to it. If that still doesn't fix it,
you might be running into the same thing as me. Maybe there's some command
line magic.

-- 
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/3cc4a133a84e4f45ecfe93058f37f598.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: I broke Qubes with template reinstall...

[sevas]

Reference:
https://groups.google.com/forum/#!topic/qubes-users/5eJF__5UBAc

Apparently many people suffer from this problem. 
After reinstalling the a few dire programs, everything seems to be working.
Only problem is that the dom0 applications menu is gone. 
Possible solution here:
https://groups.google.com/forum/#!topic/qubes-users/lsED7b1qVjw

Im not messing with it. 
I reinstalled.

Qubes Installation media does not (and did not previously) like partitions with 
things on them. A quik trip over to the bash prompt and a little fdisk and 
mkfs.ext4 and were right as rain!

reinstalling templates seem very unstable... Im not doing that .ever. again.

-- 
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/7a72c8c6-21f3-40a5-828d-c9ad08008bf6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Install Android-x86 on HVM

[msgheap]

On Tuesday, March 6, 2018 at 12:40:13 PM UTC+7, Tim W wrote:
> On Thursday, March 1, 2018 at 11:17:25 AM UTC-5, msg...@gmail.com wrote:
> > On Thursday, March 1, 2018 at 7:50:44 PM UTC+7, Yuraeitha wrote:
> > > On Thursday, March 1, 2018 at 11:11:44 AM UTC+1, msg...@gmail.com wrote:
> > > > Hello,
> > > > 
> > > > I want to install Android-x86 on Qubes OS 4.0rc4 StandaloneVM (HVM), 
> > > > but the Android installer can't recognize the VM drives.
> > > > I can run the Android Live from the iso and it works.
> > > > I've tried to install Android-x86 7.1-rc1/6.0-rc3/4.4-rc5 but they 
> > > > can't recognize the VM drives.
> > > > Based on some messages from mailing list/github issues, it was possible 
> > > > to install Android-x86 on HVM in Qubes OS 3.2 (or pre 4.0rc4?) but I 
> > > > can't do it in Qubes 4.0rc4.
> > > > Maybe someone have some clues on how to make the Android-x86 installer 
> > > > recognize VM drives?
> > > 
> > > Could it be because of the kernel is loaded in a similar way to how it 
> > > for example prevents Windows to install? I'd guess any standalone shares 
> > > this issue in Qubes 4 and not just Windows. Linux or not, if it tries to 
> > > use its own kernel rather than the one provided by dom0, then it would 
> > > probably not work. 
> > > 
> > > This should disable the VM's kernel, though I never used it my self, try 
> > > adjust if the citation marks are different.
> > > qvm-prefs android-vm-name kernel ''
> > > 
> > > I can confirm from personal experience that Android remix was possible to 
> > > be installed during Qubes 3.2., though I didn't try on Qubes 4 yet. 
> > > Generally it should work though, you probably just need to bypass some 
> > > issues, like the kernel issue above, and perhaps you need to adjust the 
> > > virt_mode too qvm-prefs android-vm-name virt_mode. Try change it to HVM 
> > > if it isn't already. I'm not sure if the GUI VM Settings has been fixed 
> > > for the Virt_mode, otherwise just use the dom0 terminal with above 
> > > command to change it.
> > 
> > I've already set the kernel to '', virt_mode to HVM, disabled memory 
> > balancing and set memory to 4GB, it didn't help.
> > I've installed Windows 7/10 without any problems on this same Qubes OS 
> > 4.0rc4 but I can't install Android-x86 with the same config.
> 
> I do not think the mouse  behavior issue has ever been able to be addressed.  
> It is mentioned in most of the android attempt threads.  There have been 
> numerous requests for actual android auppprt but without fully functional 
> mouse behavior it prevents proper use function.  As far as I know it has been 
> an issue in ever successful install of android on qubes but I could be wrong.

Yes, I know about this issue, but with the changed vm mouse config from  to type='mouse' I can more or less work in the 
Android even with the mouse acceleration problem.
The main reason why I wanted to install Android in Qubes is to use telegram 
with secret chat so I don't really need the mouse that much.
Right now I can't install Android-x86/CM-x86 because android installer can't 
detect the xen drive.
Also the network is not working in Android-x86 Live (tried Android-x86 7/6/4.4 
and CM-x86 14.1).

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

Re: [qubes-users] Security questions (templates and kde)

[Tim W]

On Tuesday, March 6, 2018 at 12:23:10 AM UTC-5, Yuraeitha wrote:
> On Tuesday, March 6, 2018 at 5:24:50 AM UTC+1, sevas wrote:
> > Thank you both for this enlightening talk, and especially Yuraeitha for 
> > such a lengthy researched opinion!
> > 
> > We speak of stability. Stability and vulnerability go hand in hand, dont 
> > they?
> > 
> > I love the kde plasma desktop and I would like to have it. But it looks 
> > like a complicated GUI that probably is not as secure as something more 
> > simple. But again, the non-root GUI is not going to connect to the 
> > internet. 
> > 
> > My previous feelings were to use one template for internet access and one 
> > for background/desktop/personal use. But that may not be needed since 
> > applications available in a template are not necessarily used in the appVM. 
> > Is that correct or would there be some data leak?
> > 
> > XFCE is something I havent used in a long time, but I will surely look into 
> > my customization techniques before I make a big move.
> 
> About the stability going hand in hand with vulnerability, I view it the same 
> way too, though it's not always the case if it isn't possible to exploit it, 
> which also isn't always possible too.
> 
> Qubes once used KDE btw, you can find the discussion that made the change 
> from KDE to XFCE5 here https://github.com/QubesOS/qubes-issues/issues/2119
> Some of these issues I believe have changed though, what is perceived as 
> "ugly" was back then a bit of an unlucky controversial statement due to 
> different subjective opinions and it caused a bit of a stir in the KDE 
> community. But I believe KDE also corrected some of those issues since then? 
> 
> It's a good idea to keep your critical offline app's and data in an offline 
> VM btw, keep doing that. You can also find multiple of official Qubes 
> recommendations suggesting this offline AppVM move. For example the Split GPG 
> guide in the Qubes doc's recommend this approach in order to keep your GPG 
> keys more secure from being hacked. For example if only one application makes 
> an outgoing opening in the firewall in the AppVM, then data in that AppVM 
> might be opened to risk through exploits and attacks to that established 
> connection. I have about 15-17 AppVM's which I use, not including the ones I 
> don't use or templates, and I'm probably a light AppVM user compared to the 
> more extreme ones. If it seems overwhelming though, try start with a set 
> smaller number of VM's, then as you get used to it, try expand with a couple 
> of VM's at a time. Think about what it adds to security or practical 
> use-cases, and keep reviewing your VM layout :)
> 
> I believe there should be no issue switching between XFCE4 and KDE though, 
> since the guide to KDE doesn't mention deleting XFCE4, just disabling it (at 
> least it didn't at the time I read it). So presumably you should be able to 
> switch between them with 2-3 commands in the tty terminal. You mihgt want to 
> double-check that though, for example can you keep switching between them 
> multiple of times without causing any harm to the system?

Correct.  I have had both on and functioned fine.

For secuirty I see little difference other than maybe the amount of code.  The 
more code ,all things being equal, the more possible holes errors surface area 
to attack. 
  

-- 
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/5a9babef-ccf3-44d9-89f5-4b4b3640e745%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: I broke Qubes with template reinstall...

[Tim W]

On Monday, March 5, 2018 at 11:29:30 PM UTC-5, sevas wrote:
> dom0$ sudo qubes-dom0-update --action=reinstall qubes-template-debian-9
> 
> Now my dom0 menu is gone. No more terminal. No more Qubes Manager. No more... 
> anything... 
> 
> 
> I gave up immediately and thought I would reinstall Qubes. 
> 
> Well, that was a fail too. Qubes installer freezes when I click Continue on 
> the first page. 
> 
> Any suggestions??

As far as I know there is nothimg you could do inside qubes such as you have 
described that cwould also effect reinstalling qubes fresh.  After all you are 
booting from  Usb or dvd media.  My guess is maybe you changed something in 
system firmware/BIOS or maybe a step you had to do the first install but maybe 
forgot this time?

Just trying to throw ideas out there as nothing on the hd should  effect a 
install from external boot source.

Are you usimg the same install media and version i.e. you did not download a 
fresh QUBES OS ISO etc where possible updated changes could have been made 
etc.. vs your previous install.

When I do something that seems to screw up many subsys5ems etc I like you did 
prefer to just do a reinstall and restore data.  But prior to that I still try 
to fix the issue first to learn what I broke and how.  That is if time allows 
of course.  Then I wipe and install to be sure there is nothing left over from 
the issue that could cause phant9m issues later.  Mayne not necessary but a 
habit I can not shake after supporting numerous Microsoft shops for over 25 
yrs.  

-- 
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/8449ef4b-ad30-4dc8-bbca-eecf3a931775%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: I broke Qubes with template reinstall...

[sevas]

dom0$ qubes-dom0-update --clean #Clean yum repos...
dom0$ qubes-dom0-update qubes-core-dom0*
## find: '/var/lib/qubes/dom0-updates/var/cache/yum': No such file/directory
## Installing *linux-debug *vaio-fixes(1/2)
dom0$ qubes-dom0-update --gui
## xterm: cannot load font '-misc-fixed-medium-r-semicondensed--##-##--
dom0$ qubes-dom0-update --action=downgrade
## yum version in sys-firewall does not support --downloadonly option
## Error: downgrade not supported
dom0$ qubes-dom0-update --action=install
## find: '/var/lib/qubes/dom0-updates/var/cache/yum': No such file/directory
dom0$ qubes-dom0-update --action=upgrade
## No upgrade available


...
wait for it
.

DOOM
dom0$ qubes-dom0-update qubes*
##

-- 
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/0623ce6b-c779-423d-8bbc-3836818c45d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Install Android-x86 on HVM

[Tim W]

On Thursday, March 1, 2018 at 11:17:25 AM UTC-5, msg...@gmail.com wrote:
> On Thursday, March 1, 2018 at 7:50:44 PM UTC+7, Yuraeitha wrote:
> > On Thursday, March 1, 2018 at 11:11:44 AM UTC+1, msg...@gmail.com wrote:
> > > Hello,
> > > 
> > > I want to install Android-x86 on Qubes OS 4.0rc4 StandaloneVM (HVM), but 
> > > the Android installer can't recognize the VM drives.
> > > I can run the Android Live from the iso and it works.
> > > I've tried to install Android-x86 7.1-rc1/6.0-rc3/4.4-rc5 but they can't 
> > > recognize the VM drives.
> > > Based on some messages from mailing list/github issues, it was possible 
> > > to install Android-x86 on HVM in Qubes OS 3.2 (or pre 4.0rc4?) but I 
> > > can't do it in Qubes 4.0rc4.
> > > Maybe someone have some clues on how to make the Android-x86 installer 
> > > recognize VM drives?
> > 
> > Could it be because of the kernel is loaded in a similar way to how it for 
> > example prevents Windows to install? I'd guess any standalone shares this 
> > issue in Qubes 4 and not just Windows. Linux or not, if it tries to use its 
> > own kernel rather than the one provided by dom0, then it would probably not 
> > work. 
> > 
> > This should disable the VM's kernel, though I never used it my self, try 
> > adjust if the citation marks are different.
> > qvm-prefs android-vm-name kernel ''
> > 
> > I can confirm from personal experience that Android remix was possible to 
> > be installed during Qubes 3.2., though I didn't try on Qubes 4 yet. 
> > Generally it should work though, you probably just need to bypass some 
> > issues, like the kernel issue above, and perhaps you need to adjust the 
> > virt_mode too qvm-prefs android-vm-name virt_mode. Try change it to HVM if 
> > it isn't already. I'm not sure if the GUI VM Settings has been fixed for 
> > the Virt_mode, otherwise just use the dom0 terminal with above command to 
> > change it.
> 
> I've already set the kernel to '', virt_mode to HVM, disabled memory 
> balancing and set memory to 4GB, it didn't help.
> I've installed Windows 7/10 without any problems on this same Qubes OS 4.0rc4 
> but I can't install Android-x86 with the same config.

I do not think the mouse  behavior issue has ever been able to be addressed.  
It is mentioned in most of the android attempt threads.  There have been 
numerous requests for actual android auppprt but without fully functional mouse 
behavior it prevents proper use function.  As far as I know it has been an 
issue in ever successful install of android on qubes but I could be 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/94e81362-c458-4b81-963a-194537efdb01%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Security questions (templates and kde)

[Yuraeitha]

On Tuesday, March 6, 2018 at 5:24:50 AM UTC+1, sevas wrote:
> Thank you both for this enlightening talk, and especially Yuraeitha for such 
> a lengthy researched opinion!
> 
> We speak of stability. Stability and vulnerability go hand in hand, dont they?
> 
> I love the kde plasma desktop and I would like to have it. But it looks like 
> a complicated GUI that probably is not as secure as something more simple. 
> But again, the non-root GUI is not going to connect to the internet. 
> 
> My previous feelings were to use one template for internet access and one for 
> background/desktop/personal use. But that may not be needed since 
> applications available in a template are not necessarily used in the appVM. 
> Is that correct or would there be some data leak?
> 
> XFCE is something I havent used in a long time, but I will surely look into 
> my customization techniques before I make a big move.

About the stability going hand in hand with vulnerability, I view it the same 
way too, though it's not always the case if it isn't possible to exploit it, 
which also isn't always possible too.

Qubes once used KDE btw, you can find the discussion that made the change from 
KDE to XFCE5 here https://github.com/QubesOS/qubes-issues/issues/2119
Some of these issues I believe have changed though, what is perceived as "ugly" 
was back then a bit of an unlucky controversial statement due to different 
subjective opinions and it caused a bit of a stir in the KDE community. But I 
believe KDE also corrected some of those issues since then? 

It's a good idea to keep your critical offline app's and data in an offline VM 
btw, keep doing that. You can also find multiple of official Qubes 
recommendations suggesting this offline AppVM move. For example the Split GPG 
guide in the Qubes doc's recommend this approach in order to keep your GPG keys 
more secure from being hacked. For example if only one application makes an 
outgoing opening in the firewall in the AppVM, then data in that AppVM might be 
opened to risk through exploits and attacks to that established connection. I 
have about 15-17 AppVM's which I use, not including the ones I don't use or 
templates, and I'm probably a light AppVM user compared to the more extreme 
ones. If it seems overwhelming though, try start with a set smaller number of 
VM's, then as you get used to it, try expand with a couple of VM's at a time. 
Think about what it adds to security or practical use-cases, and keep reviewing 
your VM layout :)

I believe there should be no issue switching between XFCE4 and KDE though, 
since the guide to KDE doesn't mention deleting XFCE4, just disabling it (at 
least it didn't at the time I read it). So presumably you should be able to 
switch between them with 2-3 commands in the tty terminal. You mihgt want to 
double-check that though, for example can you keep switching between them 
multiple of times without causing any harm to the 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/3abb784a-7596-4fce-9f2b-5eeec293d94f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: non qubes

[Tim W]

On Sunday, March 4, 2018 at 1:58:44 PM UTC-5, awokd wrote:
> On Sun, March 4, 2018 5:34 am, Tim W wrote:
> > On Saturday, March 3, 2018 at 6:33:27 AM UTC-5, awokd wrote:
> 
> >> Buying items through Tor means using your real identity through Tor.
> >> Some
> >> people use Tor for everything including banking. Some use Tor for all
> >> browsing except anything involving their real identity. Others just use
> >>  Tor occasionally for some sites. Try searching tor-users mailing list
> >> for questions similar to yours; you'll need to develop your own answer.
> >
> > That is how 99.9% of those caught using tor are found.  Its from bad
> > opsec not actually breaking of tor itself.Tech even the way silk road
> > was brought down was via a spoof more than 100% of breaking tor.  but
> > like anything layers.  Whats great about qubes is it helps in numerous
> > ways from being resistant to the spread of malware its easy integration
> > oh whonix.  It ability to string numerous network tunneling chains
> > together to creating multiple layers if done correctly have the effect of
> > indecent cells working to a common goal with only the end user knowing
> > all parts.  Qubes is but one part but its configuration allows for
> > numerous ways and layer for security and or if done with proper opsec
> > anonymity
> 
> Agree with what you say except I want to redefine "caught" to "security
> failure". In the case of someone using Tor in conjunction with their real
> identity, for example, they aren't worried about the site or any third
> party trackers knowing WHO they are during that particular session. Their
> primary concern (aka a security failure for them) might be revealing their
> location by their real IP (or in the third party trackers case,
> link-ability across sessions/other sites by super cookies etc.). The trade
> off, though, is their traffic may get routed through network path that is
> less trusted than user -> ISP -> ISP -> site; would be user -> Tor ->
> random exit node -> random exit node's ISP -> ISP -> site. That's why
> there is no comprehensive, simple answer on the "right" way to use Tor. It
> varies by what you are trying to accomplish. See
> https://www.torproject.org/docs/faq.html.en#WhatProtectionsDoesTorProvide
> , or https://www.torproject.org/docs/documentation.html.en for more
> details and support options.

I could not agree more.  Also very well put and easy to understand example.  
You always have to define the use and what you are protecting and from who.  No 
one way for everything.

-- 
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/48bb8093-3fce-4f21-a3a3-2d60decdfb30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: I broke Qubes with template reinstall...

[sevas]

A little more info...

Qubes 4.0 rc4.

Starting Debian-9 returns error that /var/lib/qubes/something doesnt exist.

Is there a keyboard command for opening the dom0$terminal?

This is crazy. Im afraid to work on it now. 

dom0$ for VM in `qvm-ls --raw-list`; do qvm-prefs -s $VM kernel 4.14.13-3; done 
dom0$ for VM in `qvm-ls --raw-list`; do qvm-prefs -s $VM kernel default; done 
## kernel not installed
## qubesadmin.exc.QubesPropertyValueError: Kernel 'default' not installed
dom0$ qubes-dom0-update
## No updates available. 
sys-net$ ping google.com
## good
dom0$ qubes-dom0-update kernel
## Complete!
dom0$ restart
dom0$ for VM in `qvm-ls --raw-list`; do qvm-prefs -s $VM kernel 4.14.13-3; done 
## qvm-prefs: error: no such property: 'kernel'
dom0$ qubes-dom0-update kernel-qubes-vm
## Complete!
dom0$ restart

-- 
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/820918db-4858-4ab9-a81e-ae85a1649e24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: High spec laptop for Qubes OS

[Tim W]

On Sunday, March 4, 2018 at 3:32:15 PM UTC-5, tai...@gmx.com wrote:
> On 03/02/2018 10:13 PM, Tim W wrote:
> 
> > Everyone knows those issues on this board and its understood.  Point being 
> > he asked for present day high end laptop but at the same time I will agree 
> > with you that for most basic use models its not so much the processor as it 
> > is ram amount but one thing for sure is you can not recommend a PC that one 
> > is not a laptop and two has no xen or qubes support i.e talon/powerpc.
> >
> > I think its rather moot talking about intel backdoors when its 100% 
> > plausible that countless firmwares are backdoored.
> Considering that the TALOS 2, KGPE-D16, KCMA-D8 and the G505S's 
> firmwares are open source and every component such as pci-e addon cards 
> that aren't are restricted by the IOMMU - again you give dangerous 
> advice and suggest that people focus on some vague theoretical backdoor 
> rather than what is a proven fact (that intel machines are owned by 
> intel, not you) and thus tell them they shouldn't even bother with security.
> 
> I mean by those standards why use qubes at all? it probably has 
> backdoors from all the worlds governments so you might as well just use 
> windows 10!
> > Its been mentioned numerous times by Joanna Marek and others that at some 
> > point at this current point in consumer computing ayou must accept trust.  
> > Whatever that point is may be different for different people but unless you 
> > are going to make a computer from silicon up and every line of code to 
> > include a compiler etc you must trust at some level.  Thus the whole idea 
> > of picking and choosing which of the possible violation is unacceptable is 
> > rather moot
> So what you are saying is that because someone could have theoretically 
> slipped some super clever backdoor in to an open source firmware it 
> doesn't matter at all and why not just get a closed source firmware 
> laptop with ME?
> 
> That is not at all what they are saying.
> 
> What exactly are your professional qualifications on this matter? Do you 
> own at least one computer with open source firmware? If you are so 
> concerned with your privacy why do you use gmail?

Wownfine I give up h you ha e read so much into my commemts that I never 
intnnded whatever.  Tell the guy that wants a high end laptop to buy a power pc 
or a talonto run qubes ofc it.  Or to use those ausu boards as that will make 
angreat laptop. Since every piiece of hardware you use om those syztems is 
100% opensource I guess that includes the harddrive firmware w.  As this op 
wants a laptop though please name a single open that meets the standards you 
speak of with no close sourced  firmware and drivers.  Becuase no LE agencies 
in the USA ha e ever used backdoor firmware on hardrives.

Actually do not bother as I am done distruptiong this ops threads with such off 
topic drivel.   

There are plenty of choices for high end laptops that have been suggested or 
can be found on the compatbility list.  

-- 
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/de4c0c57-6c09-43f1-ae99-8219ae2a0bed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Security questions (templates and kde)

[Yuraeitha]

On Tuesday, March 6, 2018 at 5:24:50 AM UTC+1, sevas wrote:
> Thank you both for this enlightening talk, and especially Yuraeitha for such 
> a lengthy researched opinion!
> 
> We speak of stability. Stability and vulnerability go hand in hand, dont they?
> 
> I love the kde plasma desktop and I would like to have it. But it looks like 
> a complicated GUI that probably is not as secure as something more simple. 
> But again, the non-root GUI is not going to connect to the internet. 
> 
> My previous feelings were to use one template for internet access and one for 
> background/desktop/personal use. But that may not be needed since 
> applications available in a template are not necessarily used in the appVM. 
> Is that correct or would there be some data leak?
> 
> XFCE is something I havent used in a long time, but I will surely look into 
> my customization techniques before I make a big move.

I recommend you listen to Chris here though. As mentioned some people are much 
more knowledgeable than I about security while I'm still only an early learner 
(and he's one of those who are much more knowledgeable). I also learned from 
reading his post as well. You can use my post to put forward new questions 
though (keep learning and dig deeper over time), but use Chris post for actual 
answers here regarding the security, he's way more credible. Notice too how he 
legit dismantles my argument "that Fedora is the slightly more secure one", 
when it turns out Debian appears ahead of Fedora in terms of security, and it 
seems like it might not be by just a little either. I stand corrected, I need 
to read more on this topic.

Keep learning though, it's awesome you ask and try find answers to questions 
like these.

-- 
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/b9dcc60e-e397-4ec6-b8fb-4c5cc8c20646%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: I broke Qubes with template reinstall...

[sevas]

A little more info... 

Qubes 4.0 rc4. 

Starting Debian-9 returns error that /var/lib/qubes/something doesnt exist.

Is there a keyboard command for opening the dom0$terminal?

This is crazy. Im afraid to work on it now. 

-- 
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/3614616f-2058-4f6f-b735-2385a2384111%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] I broke Qubes with template reinstall...

[sevas]

dom0$ sudo qubes-dom0-update --action=reinstall qubes-template-debian-9

Now my dom0 menu is gone. No more terminal. No more Qubes Manager. No more... 
anything... 


I gave up immediately and thought I would reinstall Qubes. 

Well, that was a fail too. Qubes installer freezes when I click Continue on the 
first page. 

Any 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/cdb1543a-6c97-45e7-ab2e-d95c19393115%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Security questions (templates and kde)

[sevas]

Thank you both for this enlightening talk, and especially Yuraeitha for such a 
lengthy researched opinion!

We speak of stability. Stability and vulnerability go hand in hand, dont they?

I love the kde plasma desktop and I would like to have it. But it looks like a 
complicated GUI that probably is not as secure as something more simple. But 
again, the non-root GUI is not going to connect to the internet. 

My previous feelings were to use one template for internet access and one for 
background/desktop/personal use. But that may not be needed since applications 
available in a template are not necessarily used in the appVM. Is that correct 
or would there be some data leak?

XFCE is something I havent used in a long time, but I will surely look into my 
customization techniques before I make a big move. 

-- 
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/189c4ff2-0d71-4244-a51f-0a6f0dec1f3a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Locked screen message "This version of XScreenSaver is very old! Please upgrade!"

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2018-03-05 13:31, Unman wrote:
> On Mon, Mar 05, 2018 at 08:15:45PM +0100, 'Max Andersen' via
> qubes-users wrote:
>> 
>> On 03/05/2018 08:09 PM, Unman wrote:
>>> On Mon, Mar 05, 2018 at 07:32:47PM +0100, 'Max Andersen' via
>>> qubes-users wrote:
 Hi everyone,
 
 Qubes 3.2 displays the message "This version of XScreenSaver
 is very old! Please upgrade!", when the screen is locked with
 Xscreensaver 5.36
 
 I haven't seen an update to Dom0 when running sudo
 qubes-dom0-update, so is this just annoying or an actual
 issue?
 
 Sincerely
 
 Max
 
 
>>> It's just a reflection of the fact that dom0 is still using
>>> fedora 23, which is long past eol. SO no updates for the
>>> screensaver. Is it an issue? I don't think there have been
>>> advisories since 34, so 5.36 should be fine.
>> 
>> Didn't think so either, but why did I get the message in the
>> first place? Does it check for newer versions or is it just a
>> timer ?
>> 
>> Sincerely Max
> 
> Just a timer.
> 

Already reported here:

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

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqd9JAACgkQ203TvDlQ
MDBlpw/+K4dOxKhc7fjZOo2uWo0EPM9MUu+8FCfQhejfhqnSgyDq+K6sXqpZNBRN
D0j/Q9k5TAGYY8Jd9c5rbaj0lwMHpBXw9otp0ARbHtue1algmBG/n5YKaamX+Sd3
q1RZVewQulf53pm2VABPPbKNGpvN/rmjd1EGBmxLgZQe80WsdFvUsO1S4qC/7tmZ
Y7LRmAKTXiXHhMmtMHkSoDLQpIGANa8w9KuQrQ6pYqEWJz9xuy0CrHnuOHCfYt0E
gRFIoAA+T7ED3IirASGt6rbHcNhYJjgIfISIybiNvGMgr8EL2NpkG2OPP7u5mj04
yF4ijQzWiUB8tAvDMlOEZltCryJBZ5CU86lBigFkCdDHLsLECl+GRYEBaXJDoP0d
nsMzm0OsHFnsVY4SoQn1SMznteYQ9Oa5eYK4vRoJtDIy9opCXd5yoYegPYFfDyVi
hqHtrwBBuZtFLhFzXeMJ8xMR3sP4PFuR/EXh9Ls5Dq4hNANsEobHQQd1Gjk84Hjt
ILq+CtwCFJr14Y+Q24PSH9NVm114+QbxnX81kZDtP1idJ8QpGbwR4ZKFY1MAb+ci
uKWgxYI/7RIFHnMQ48O9jFzAeEEoQqXCLkAMkkUB+xyYt4XyG25lMTSkeIzdt9kN
smbn3JY1erFDI0imcTwx3mBFdQDBFAkHXRYx8T9W/Bi/kv/gEkk=
=O9h8
-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/5c871223-9f2b-0509-0e3e-3ea3ea0e9d6f%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Help: preparing a SD-Card for Rasperryan under Qubes

[Yuraeitha]

On Monday, March 5, 2018 at 11:09:53 PM UTC+1, [ 799 ] wrote:
> Hello,
> 
> I'm trying to setup my raspberry pi from qubes as I want to reinstall/write a 
> coreboot howto and I am using a raspberry pi + pomodo clip to flash the bios 
> chip.
> Honestly I must admit that I have setup my raspberry under windows in the 
> past:
> 
> - Download ISO
> - copy ISO to the SD-card
> 
> I would like to so under Qubes OS, but I am confused as my internal 
> SD-Card-Reader in my laptop is not be recognized by my USB qubes.
> If in insert the SD-Card I can see all partitions as blockdevices.
> 
> what is the best approach to access the SD-Card reader from an appvm and 
> finish the provisioning of coreboot?
> 
> I would like to dd the .iso to the SD-card as it is described in the 
> raspberryan howto:
> https://www.raspberrypi.org/documentation/installation/installing-images/linux.md
> 
> dd bs=4M if=raspbian-stretch.img of=/dev/sdX conv=fsync
> 
> [799]

I can confirm it can work with qvm-block at least, when I made a raspberry pi 
(quite recently too) on Qubes 4 RC-3 (updated to RC-4), through the Card Reader 
and qvm-block, and performed the install inside the AppVM without a hitch.

Does any of these suggestions help?

- Is it certain that this Card Reader is run through a USB controller and not 
another type of controller? the block devices show up in the USB VM? lsusb? if 
not, maybe the issue might be whichever controller is responsible for the 
SD-Card Reader needs to be moved away from dom0, given some types of 
qvm-usb/qvm-block flaws in dom0, which are bugs that may not appear if the 
controller is located in VM's.

- Does dd command work in the same AppVM (or dom0) where the controller 
responsible for your SD-Card Reader is located, without using qvm-block to 
another AppVM? It could give better clues as to whats wrong. It might not be 
desired, but it could also serve as a last resort to just use the USB VM itself 
as a work-around to execute 'dd' if everything else fails.

- The USB VM is not a minimal template right? If so, all the required packages 
installed?

- I wonder about this one (probably not the issue), but it might be worth 
trying making a new partition tables with fdisk command in whichever domain you 
the controller. 

- You could temporarily move the controller away from the USB VM and onto the 
AppVM where you want to run the dd command, and then back again once you're 
done. Troublesome to restart without the PCI memory reset though, and doesn't 
fix the issue and is more a work-around right :/

-- 
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/e385d6d1-363a-4851-ac2e-57b124220a80%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2018-03-05 16:28, Alex Dubois wrote:
>> On 5 Mar 2018, at 21:07, 799  wrote:
>> 
>> Hello,
>> 
> On Sun, March 4, 2018 8:04 pm, 799 wrote: Can't we just 
> create a new "community" repo where Pull request get 
> reviewed by us but finally approved by more experienced 
> Power Users (this group can include Qubes OS Team, but also
> experienced community members selected by the Qubes 
> Team/David)?
 
 On 4 Mar 2018, at 21:44, awokd  wrote: I
 wouldn't mind helping out on reviews on something like this,
 as well as contributing my own half-baked ideas.
>>> 
>>> On 5 March 2018 at 08:57, Alex Dubois  
>>> wrote: True we could have sandbox per person, or each person 
>>> fork (the fork) and we have a page with list of forks Once idea
>>> is ready, do a PR to the community fork...
>>> 
>>> This is the spirit of git
>> 
>> can't we just start to fork qubes-doc to qubes-community-doc and
>>  start there. If we think we need to rearrange the content or get
>>  rid of it, because it just doesn't make sense, we can still do 
>> so.
>> 
>> In the main qubes-doc repository it seems that some skilled users
>> are able to approve Pull Requests, I don't know enough about
>> github how this works? Are those special permissions for trusted
>> users or can it be anyone? I would like to see Andrew David Wong
>> or marmarek as power users supporting this - by at least maybe
>> giving feedback. If there are any other skilled persons which are
>> happy to gibr feedback to improve the scripts which are collected
>> there, this is even better - just mentioned those two as they
>> were super helpfull when I wrote my first Qubes Docs hey, ho -
>> let's go.
> 
> Give David a bit of time. His schedule might be busy, he may need 
> to sync with a number of other persons, they may discuss what’s 
> best. There is no rush. He is doing a great work as community 
> manager.
> 

Thanks. :}

Currently, qubes-doc PRs have to be approved by a member of the Qubes
team before being merged into the master branch, which is the live
version. (Usually, I'm the one who does the merge. In those cases, if
you don't see explicit approval from another member of the team, it
just means that I'm the one who has reviewed and approved the PR.)
This system is great for maintaining high standards of security (as a
first priority) and quality (as a second priority) for the docs.
However, it's very time-consuming, since (at least) one of us has to
review every single PR that gets merged (as well as many of those that
ultimately get rejected, which are a small minority).

Currently, we barely have enough time to keep up with the stream of
PRs that get submitted to qubes-doc, so it's very unlikely that we'd
also have time to review or provide substantive feedback on PRs for a
second, community-run version of qubes-doc that receives even more PRs
(if I'm understanding the proposal correctly).

However, I do like the sound of a fully-community-run version that
serves to collaboratively improve content before it is submitted to
qubes-doc. Currently, most contributors just submit their work
directly to qubes-doc, and the quality tends to vary. Perhaps the
community-run version could be an optional (but recommended,
especially for first-time contributors) place where work is polished
up with feedback from the community before it's submitted as a PR to
qubes-doc to be reviewed by the team. This could make things easier
for contributors, improve the quality of the docs, and save the team's
time.


P.S. - You can call me "Andrew." "David" is my middle name. :)

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqd7psACgkQ203TvDlQ
MDDzqRAAlppp00e/YixAnaLJgyNEYbZgxA9ZlVABBxUJwUX7Ede0MAHeiLHLiR0E
PqdvVBSBi1rt0XYROka44IJ8amj1pM3tc5UroE4rhG8yxY7TPnul0tAHeTH5rTk2
rCPOsHLSuv/nwqdzhvcCK2cC9SKYgJF7IGdgtRnaMg56JEYkn7HISKFxMfL6m8L9
quU4dRdBJnWEk16lYHxQBd3JtVeBtHjCppHh9CFn5XYdbPvbPd8qYwOVMdSOaG0k
0adeue8gI8G6Mkf3pzJt7Etjr8xjlHB4JKaMy7VCN7PekdkrITbQCwPH24PLQHP9
+pFQu2ShBZgOFyNQ+itDPW70r/1Jfc0mpRu16Dz85/VTew/ROrdOlizLqHtbS6L4
i0ZG6vbFAw0H4/kPzOWz3xxRukbXtOWBL6kx1a8Sj+JZSs5B5mbSGkg5S4vOEXrg
p+PBzt5jfuwg9ZrJCqBOWy56JfPqpmb37ooqC94oTYeXX2utRFQg8QyA/NRMgduM
pkRNOVOpO81OIiUYvzM9eY2zYhWa3LUY4x0OdkiO9hcZ7tVQ17iurgBE8KFy6drj
dKd4nLPiXUMF6mGXt+6fksaKhhSAxyMcWSUb094PXhZjcqiMKEaP+7hd0tZeNSE8
R/zFQJyd6VPaervecyKvcMw9mXt2Mal/OBRlyMHbJcyNqLpucLs=
=WFKk
-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 

[qubes-users] Re: Security questions (templates and kde)

[Yuraeitha]

On Monday, March 5, 2018 at 11:39:37 PM UTC+1, sevas wrote:
> Does choosing a TemplateVM have any tactical advantage to security?
> 
> 
> Does installing KDE have any tactical disadvantage to security?

There are people more knowledgeable than I here, some much more, so I may be 
corrected on some points, but the overall picture should be correct.

First you would want to split up the comparison further first, for example the 
security that prevents an attacking from breaching fedora/debian/whonix and 
gain unauthorized access to dom0 "should" be about the same no matter which 
template you choose for your AppVM's, it should be the same hard to breach 
security. Of course an attacker would first have to breach an AppVM before they 
can try breach dom0, but the way I understand it, if dom0 can be breached, then 
so too can the AppVM's security which is supposedly easier to attack, than it 
is to attack dom0 from the VM. But having extra security in the AppVM won't 
harm and adds some extra layers of protection to dom0. If you're a low profile 
target, then it may not be worth the trouble for the attacker to get at you 
without some kind of pay-off or reward at the end. The more tricky you make it 
for them, with the less motivation incentives, the more secure you are. Of 
course making it too tricky might also serve as a challenge to be broken, so 
don't become a target by making yourself stand out as a challenge to be cracked 
either. Try mingle in the crowd, i.e. act the same way as other Qubes/Linux/WWW 
users do. It may also be worth it to hide that you're a Qubes user, or even 
that you're Linux user, whereever possible, so that you don't attract unwanted 
challenge attention.

As for the templates, Fedora has more frequent release cycles, while Debian is 
more slow release cycle based.

Debian - As far as I'm aware, the Debian Project Leader is voted on annually by 
a democratic community of developers and maintainers. Debian is more slowly 
releasing, and generally focus on stability and reliability.

Fedora - On the other hand, is acting like a test-bed for Red Hat Enterprise 
and CentOS, and release updates and new features quicker in order to test them 
out. Some of the leaders, including the Project Leader, are appointed by Red 
Hat, while seemingly a lot of the leadership is community based. 

In general it seems Debian relies on longer testing periods to ensure 
reliability, while Fedora puts in more effort and does it quicker. Which is 
best is probably a matter of which approach you deem more reliable. If you 
trust open source review, editing and testing, then debian is more reliable and 
secure. But if you trust experts to be able to put it together better than open 
source reviews can manage in a relatively short time-frame, then fedora is more 
secure. Generally the belief that many open source projects take time to 
review, which goes to say that Fedora can act quicker on issues than Debian can 
do, because Fedora is more centralized and focused, while Debian is more 
decentralized and community dependent.

Personally, I don't believe the open source aspect is always living up to its 
name, code is not always being reviewed and checked for errors and security 
flaws, and maybe some are so sophisticated that the reviwer don't see them 
until years later when someone else discoveres them, and in all that time 
in-between you have no idea if some skilled hackers, groups or organizations 
have used these exploits to their own gain and interest. More time won't 
nessicarily change open source code reliability and security, it also needs 
people actually looking at the code too, which is a given but often forgotten 
element. Fedora is in that sense better as more ressources are initially 
invested into the test-bed, but it still preserves the open source aspect as 
well for long-term open source reviews from third-parties. The pre-zero-day 
attacks disvocered from Fedora are also less likely to be spread wide and far, 
and may likely be exotic among the group of the very, very skilled 
hackers/orgnisations, but not so common-place on the internet. The odds of you 
being the target of a zero-day here is therefore less.

Debian also patch up security issuered discovered as time go on, but is as I 
understand it less quick to have their own code reveiwed, and features are 
slower released too. The stability is a strength towards Debian, security 
updates from third-party code is also quick, but the review of own code is 
likely not as fast as Fedora's. But with fedroa you have to sacrifice some 
stability, although not much, but some nonetheless.

It's an subjective evaluation, but honestly I feel fedora is more secure, while 
debian may be more stable, but in the end they are still somewhat close to each 
others in terms of security and reliability.

Of course beyond that, the normal firewall policy and security oversight 
implemented in normal Linux use-cases, should also be done in the Qubes 

[qubes-users] Security questions (templates and kde)

[sevas]

Does choosing a TemplateVM have any tactical advantage to security?


Does installing KDE have any tactical disadvantage to security?

-- 
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/32ffe776-6876-4b12-8a21-e76d6dd74818%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Alex Dubois]

Sent from my mobile phone.

> On 5 Mar 2018, at 21:42, awokd  wrote:
> 
>> On Mon, March 5, 2018 9:07 pm, 799 wrote:
>> Hello,
>> 
>> 
> On Sun, March 4, 2018 8:04 pm, 799 wrote:
> 
> Can't we just create a new "community" repo where Pull request get
> reviewed by us but finally approved by more experienced Power Users
>>> (this
>>> 
> group can include Qubes OS Team, but also experienced community
> members selected by the Qubes Team/David)?
 
 On 4 Mar 2018, at 21:44, awokd  wrote:
 I wouldn't mind helping out on reviews on something like this, as well
 as contributing my own half-baked ideas.
>>> 
>>> On 5 March 2018 at 08:57, Alex Dubois  wrote:
>>> True we could have sandbox per person, or each person fork (the fork)
>>> and we have a page with list of forks Once idea is ready, do a PR to the
>>> community fork...
>>> 
>>> This is the spirit of git
>>> 
>>> 
>> 
>> can't we just start to fork qubes-doc to qubes-community-doc and start
>> there. If we think we need to rearrange the content or get rid of it,
>> because it just doesn't make sense, we can still do so.
> 
> I was picturing an empty repo with relaxed editing requirements (can
> Github do this?) for new content only. Think forking existing might be
> confusing short and long term. :)

I provided my input earlier on this in case you missed it. What others think?

> 
>> In the main qubes-doc repository it seems that some skilled users are
>> able to approve Pull Requests, I don't know enough about github how this
>> works? Are those special permissions for trusted users or can it be
>> anyone?
> 
> In the official repo, I believe only Andrew and marmarek (and probably
> other Qubes members) can merge. This responsibility should stay with
> official Qubes reps. due to the sensitivity. However, there are some
> (Whonix, template maintainers) who might also authoritatively review
> related commits.
> 
>> I would like to see Andrew David Wong or marmarek as power users
>> supporting this - by at least maybe giving feedback.
> 
> adw's stated elsewhere they are happy with a community run site but
> wouldn't have the resources to support it.
> 
>> If there are any
>> other skilled persons which are happy to gibr feedback to improve the
>> scripts which are collected there, this is even better - just mentioned
>> those two as they were super helpfull when I wrote my first Qubes Docs
> 
> 
> 

-- 
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/AE67729B-1060-4551-9D45-B2BE24B2687A%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Alex Dubois]

Sent from my mobile phone.

> On 5 Mar 2018, at 21:07, 799  wrote:
> 
> Hello,
> 
>> >> On Sun, March 4, 2018 8:04 pm, 799 wrote:
>> >> Can't we just create a new "community" repo where Pull request get
>> >> reviewed by us but finally approved by more experienced Power Users (this
>> >> group can include Qubes OS Team, but also experienced community members
>> >> selected by the Qubes Team/David)?
>> >
>> > On 4 Mar 2018, at 21:44, awokd  wrote:
>> > I wouldn't mind helping out on reviews on something like this, as well as
>> > contributing my own half-baked ideas.
>> 
>> On 5 March 2018 at 08:57, Alex Dubois  wrote:
>> True we could have sandbox per person, or each person fork (the fork) and we 
>> have a page with list of forks
>> Once idea is ready, do a PR to the community fork...
>> 
>> This is the spirit of git
> 
> can't we just start to fork qubes-doc to qubes-community-doc and start there.
> If we think we need to rearrange the content or get rid of it, because it 
> just doesn't make sense, we can still do so.
> 
> In the main qubes-doc repository it seems that some skilled users are able to 
> approve Pull Requests, I don't know enough about github how this works?
> Are those special permissions for trusted users or can it be anyone?
> I would like to see Andrew David Wong or marmarek as power users supporting 
> this - by at least maybe giving feedback. If there are any other skilled 
> persons which are happy to gibr feedback to improve the scripts which are 
> collected there, this is even better - just mentioned those two as they were 
> super helpfull when I wrote my first Qubes Docs
> hey, ho - let's go.

Give David a bit of time. His schedule might be busy, he may need to sync with 
a number of other persons, they may discuss what’s best. There is no rush. He 
is doing a great work as community manager. 

In the mean time, I certainly don’t want to break your enthusiasm, anybody who 
wants can fork the Qubes-doc to work on his bits and once things are decided 
either raise issues and PR either to main Qubes OS or the community one.

We can discuss here ideas and agree on the way to proceed.

At the moment I am trying to help on the QWT as I think it essential for Qubes, 
most users have a leg in the windows world professionally.
After that, I would like to finish my Qubes-yubikey app
And finally do a proposal for a daemon-service (service+AppVM+firewall rules), 
as I feel a lot of users are compromising their system by doing the wrong thing 
(already mentioned I think)
Or work on Qubes-manager replacement but I have never done Linux client dev...

Maybe others can also share their plans...

> 
> [799]
>   
> 

-- 
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/1FE16220-B6F8-4F06-B1DE-E7718831615E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: qrexec demon fails to load any VM when I attach any device

[Allen Larocque]

OK, we've made progress. However, I'm not sure why this change has happened.

Now aplay -l sees two audio devices - one built-in, one HDMI.

Dom[0] volume control now sees a 'built in audio Analog Stereo' (hardware) and 
'Simultaneous output to built-in Audio' (virtual?). 

When sound is playing , the volume bars fluctuate as expected, but still no 
sound coming out.

- A 


On Sunday, 4 March 2018 18:43:51 UTC-8, awokd  wrote:
> On Mon, March 5, 2018 2:34 am, Allen Larocque wrote:
> 
> 
> > 00:1b.0 Audio device: Intel Corporation 7 Series/C216 Chipset Family High
> > Definition Audio Controller (rev 04)
> 
> > Kernel driver in use: snd_hda_intel
> > Kernel modules: snd_hda_intel
> 
> Looks like it loaded fine. In Dom0 volume control, is it selected as your
> Output Device? Can't think of any other reason why it wouldn't show in
> aplay -l.

-- 
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/4ad8ed11-7a9d-46b5-aad9-636f0763fe40%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Help: preparing a SD-Card for Rasperryan under Qubes

[799]

Hello,

I'm trying to setup my raspberry pi from qubes as I want to reinstall/write
a coreboot howto and I am using a raspberry pi + pomodo clip to flash the
bios chip.
Honestly I must admit that I have setup my raspberry under windows in the
past:

- Download ISO
- copy ISO to the SD-card

I would like to so under Qubes OS, but I am confused as my internal
SD-Card-Reader in my laptop is not be recognized by my USB qubes.
If in insert the SD-Card I can see all partitions as blockdevices.

what is the best approach to access the SD-Card reader from an appvm and
finish the provisioning of coreboot?

I would like to dd the .iso to the SD-card as it is described in the
raspberryan howto:
https://www.raspberrypi.org/documentation/installation/installing-images/linux.md

dd bs=4M if=raspbian-stretch.img of=/dev/sdX conv=fsync

[799]

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

Re: [qubes-users] Re: Setting up privateinternetaccess on qubes 3.2

[Chris Laprise]

On 03/05/2018 11:04 AM, vel...@tutamail.com wrote:

Again I have been using the Tasket VPN setup with Fedora 26 for a few weeks and 
it works well...love the kill switch element!

I was hoping to beef up the security(maybe compromise the privacy) of the VPN 
service by adding OpenDNS or Quad9 DNS addresses to this configuration.

My questions I was hoping to get some thoughts on were:

1) I was presented with a Phishing site the other day...understand I am being 
targetted so I am not suprised. Is OpenDNS, Quad9 better then others? Are there 
others that would provide just as good filtering?


Does this mean PIA's DNS converted a good domain name into a phishing IP 
address? Or was the phishing site arrived at by some other means (email, 
typo)?


My inclination is to view the VPN provider's nameservers as the safer 
option, but not if its serving wrong IPs.


Not sure what OpenDNS users would say on the subject...




2) Tasket I found some documentation in the Qubes-vpn-support-master (README.md 
file) and references the ability to change your DNS address:

You can manually set your VPN's DNS addresses with:
```
export vpn_dns=""
sudo /rw/config/vpn/qubes-vpn-ns up
```

How would I specifically change this? Is this a command? Would this be the 
specific command I would enter into my VPN VM if I was using OpenDNS:

export vpn_dns="208.67.222.222 208.67.220.220"
sudo /rw/config/vpn/qubes-vpn-ns up


I am asking here in the spirit of maybe providing some help to people trying to 
do the same thing...


Those shell commands could be used manually for testing purposes, for 
example. But the placement and phrasing is confusing so I'll change it.


For your purposes -- forcing particular DNS addresses despite the 
numbers that the VPN provider sends over DHCP -- the setenv example in 
the qubes-vpn-ns script comments is better. So if you want to use DNS 
8.8.8.8 you can put this in your openvpn config file:


   setenv vpn_dns '8.8.8.8'

Then whenever openvpn calls qubes-vpn-ns script it will see the vpn_dns 
variable is already set and will use that instead.


-

And since DNS is now the subject.

Both the VPN doc and Qubes-vpn-support 1.3 force all DNS requests to go 
through the tunnel (or else blocked). However, this does not mean an 
appVM will always send requests to the DNS server you want; it could 
conceivably try to use some other DNS server for nefarious purposes 
(although the threat model for this is weak).


TheirryIT was looking for a way to make sure the proper DNS servers were 
addressed for all DNS requests, so in 1.4beta2 I changed the dnat rules 
to convert all addresses for DNS request packets to the proper servers.


So my advice is to use the 1.4beta2 from the 'qubes4' branch (not 
currently 'master') if you aren't already. Only caveat is that, although 
its intended to still be compatible with Qubes 3.2, I haven't tested it 
yet on 3.2.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/b7a59ffa-4f27-36a3-82ef-d5a420df5bae%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] fw for network printer setup

['awokd' via qubes-users]

On Mon, March 5, 2018 9:39 pm, yreb...@riseup.net wrote:
> is there any harm in leaving Template fedora-26-clone-printer-only
> connected to sys-net directly Not to sys-firewall ?

It's not really good practice. You shouldn't have to do anything special
to change it to sys-firewall, besides maybe shutting it down first.

> as of now it is working , I just made the Template the default for  DVMs
> and print documents  from  the "open in DVM"

Great!



-- 
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/9e2695e248eeca3098bff0264d44733d.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

['awokd' via qubes-users]

On Mon, March 5, 2018 9:07 pm, 799 wrote:
> Hello,
>
>
>>> On Sun, March 4, 2018 8:04 pm, 799 wrote:
>>>
 Can't we just create a new "community" repo where Pull request get
 reviewed by us but finally approved by more experienced Power Users
>> (this
>>
 group can include Qubes OS Team, but also experienced community
 members selected by the Qubes Team/David)?
>>>
>>> On 4 Mar 2018, at 21:44, awokd  wrote:
>>> I wouldn't mind helping out on reviews on something like this, as well
>>> as contributing my own half-baked ideas.
>>
>> On 5 March 2018 at 08:57, Alex Dubois  wrote:
>> True we could have sandbox per person, or each person fork (the fork)
>> and we have a page with list of forks Once idea is ready, do a PR to the
>> community fork...
>>
>> This is the spirit of git
>>
>>
>
> can't we just start to fork qubes-doc to qubes-community-doc and start
> there. If we think we need to rearrange the content or get rid of it,
> because it just doesn't make sense, we can still do so.

I was picturing an empty repo with relaxed editing requirements (can
Github do this?) for new content only. Think forking existing might be
confusing short and long term. :)

> In the main qubes-doc repository it seems that some skilled users are
> able to approve Pull Requests, I don't know enough about github how this
> works? Are those special permissions for trusted users or can it be
> anyone?

In the official repo, I believe only Andrew and marmarek (and probably
other Qubes members) can merge. This responsibility should stay with
official Qubes reps. due to the sensitivity. However, there are some
(Whonix, template maintainers) who might also authoritatively review
related commits.

> I would like to see Andrew David Wong or marmarek as power users
> supporting this - by at least maybe giving feedback.

adw's stated elsewhere they are happy with a community run site but
wouldn't have the resources to support it.

> If there are any
> other skilled persons which are happy to gibr feedback to improve the
> scripts which are collected there, this is even better - just mentioned
> those two as they were super helpfull when I wrote my first Qubes Docs



-- 
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/3c3770d0a78a441b1008a1f2e751647b.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[taii...@gmx.com]

On 03/04/2018 04:17 PM, 799 wrote:


Hello Taiidan,

What does "zero qualification" means and what does "advice" stands for?
If this is going to be a wiki letting anyone edit it irregardless of 
skill level will result in poor quality.

It's not about advicing (advice to me means: I know something better then
someone else or at least I feel knowledgeable enough to tell other people
what they should do).

If so, those users should be given constructive feedback and guidance. Keep
in mind that those "users" are still more likely to listen than the
"average" user, who has no interest in privacy at all.


I don't see how qualification is "certified" by running Coreboot/Libreboot?
It is an easy way to prove that someone has a decent level of linux 
experience as the installation of coreboot is considered difficult.

You need a way to separate the wheat from the chaff.

I am running coreboot does this qualifies me?
If you compiled installed it yourself then yes - it proves you have a 
decent skill level.

Keep also in mind that there
might be users who need to run recent hardware or hardware that are not on
the Coreboot Hardware Compatibility List (HCL).
By your standards why not let windows users comment too? after all not 
everyone has hardware that supports qubes right?


If your goal is to have a wiki that contains safe high quality advice 
you aren't going to be able to accomplish your mission if you let anyone 
edit it regardless of skill level.


If someone can't afford a $100 laptop they probably have nothing worth 
stealing (personal data or otherwise) and thus have no reason to use 
qubes or even have a computer at all.

Writing from my Googlemail address which is only there for Qubes+Coreboot
Mailinglist because Protonmail doesn't offer IMAP:
There are way more than just two email providers even if you don't wish 
to pay a very reasonable $5/mo for paid email there are free providers 
that don't abuse you to the level that google does.

Not using Google doesn't make someone superior
No it really does, not using google means you have skills and have put 
in the research and effort to find a superior provider - ie: you care 
about your security.

and even if you are right
that there are reasons not (!) to use Google for personal E-Mails:
There are many including AI research, datamining, no real security and 
the lack of customer service.


Not to mention google recently choosing politics over profit which is 
not what a publicly held for-profit company should be doing.

If you don't allow them to comment,there is no possibility for a discussion
and convincing them to try something different.
I am not referring to a discussion forum I am referring to a wiki where 
letting anyone edit it is dangerous, the good advice of skilled user is 
easily edited and ruined by a microsoft fanboy who thinks that owner 
controlled hardware is too dangerous for just anyone to own (remember 
that hardware enforced code signing is a very recent development, owner 
controlled was the superior norm for the first half century of 
computing) and that everyone should use "secure" boot for "security".

And if so, then Qubes should not run this Google group/Mailinglist ;-)
I have complained about this - I really don't like giving google carte 
blanche to use my data to for instance eventually put me out of work via 
their AI research.


--
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/583350bf-1f93-f4b8-912e-3134ca5395a2%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] fw for network printer setup

[yrebstv]

is there any harm in leaving Template fedora-26-clone-printer-only  
connected to sys-net directly Not to sys-firewall ?

as of now it is working , I just made the Template the default for  DVMs
and print documents  from  the "open in DVM"

I am using Q3.2 , yes. 


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

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[799]

Hello,

>> On Sun, March 4, 2018 8:04 pm, 799 wrote:
> >> Can't we just create a new "community" repo where Pull request get
> >> reviewed by us but finally approved by more experienced Power Users
> (this
> >> group can include Qubes OS Team, but also experienced community members
> >> selected by the Qubes Team/David)?
> >
> > On 4 Mar 2018, at 21:44, awokd  wrote:
> > I wouldn't mind helping out on reviews on something like this, as well as
> > contributing my own half-baked ideas.
>
> On 5 March 2018 at 08:57, Alex Dubois  wrote:
> True we could have sandbox per person, or each person fork (the fork) and
> we have a page with list of forks
> Once idea is ready, do a PR to the community fork...
>
> This is the spirit of git
>

can't we just start to fork qubes-doc to qubes-community-doc and start
there.
If we think we need to rearrange the content or get rid of it, because it
just doesn't make sense, we can still do so.

In the main qubes-doc repository it seems that some skilled users are able
to approve Pull Requests, I don't know enough about github how this works?
Are those special permissions for trusted users or can it be anyone?
I would like to see Andrew David Wong or marmarek as power users supporting
this - by at least maybe giving feedback. If there are any other skilled
persons which are happy to gibr feedback to improve the scripts which are
collected there, this is even better - just mentioned those two as they
were super helpfull when I wrote my first Qubes Docs
hey, ho - let's go.

[799]

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

Re: [qubes-users] Re: Can I hope to run Qubes OS on Macbook Air 2013

[taii...@gmx.com]

On 03/05/2018 03:01 PM, andrewashbac...@gmail.com wrote:


  > Purism is a scam, their laptops are not at all libre or open source and

they never will be for a variety of reasons.
https://www.reddit.com/r/linux/comments/3anjgm/on_the_librem_laptop_purism_doesnt_believe_in/

https://goblinrefuge.com/mediagoblin/u/onpon4/m/what-purism-s-road-to-fsf-ryf-endorsement-chart-should-look-like/
Don't buy from them, you gain no security and you are supporting a bunch
of scumbags.

These links are about two years old and Purism has made significant headway in 
that time.

Wrong - both are still 100% accurate.

"Headway" so what exactly? They still use FSP, they still have a blobbed 
EC, video, power etc and disabling ME is still not only impossible but 
illegal too.
Their coreboot ports do zero hardware init all of it is done by Intel's 
FSP binary blob.


It isn't as if it is impossible to make real freedom hardware but thanks 
to them the idea of a libre laptop has been ruined in the average 
persons head and the freedom hardware movement is set back by a decade 
or more - now everyone expects absolutely brand new x86_64 hardware 
instead of POWER, ARM, or older AMD x86_64 hardware and they also 
believe that you can disable ME and have real freedom on intel hardware.


They could have admitted they fucked up and for instance collaborated 
with raptor engineering to offer a POWER laptop, but instead they 
continue to double down and keep making false claims.

   I encourage you to seek updated information and others to do their own 
research.

How much are they paying you?

--
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/20b76a1c-683b-2756-9df4-0d84ed0ba0f7%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Can I hope to run Qubes OS on Macbook Air 2013

[andrewashbacher]

 > Purism is a scam, their laptops are not at all libre or open source and 
> they never will be for a variety of reasons.
> https://www.reddit.com/r/linux/comments/3anjgm/on_the_librem_laptop_purism_doesnt_believe_in/
> 
> https://goblinrefuge.com/mediagoblin/u/onpon4/m/what-purism-s-road-to-fsf-ryf-endorsement-chart-should-look-like/
> Don't buy from them, you gain no security and you are supporting a bunch 
> of scumbags.

These links are about two years old and Purism has made significant headway in 
that time.  I encourage you to seek updated information and others to do their 
own research.

-- 
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/9b41d769-5d03-4373-ad26-9d6084e84fd2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Locked screen message "This version of XScreenSaver is very old! Please upgrade!"

[Unman]

On Mon, Mar 05, 2018 at 08:15:45PM +0100, 'Max Andersen' via qubes-users wrote:
> 
> On 03/05/2018 08:09 PM, Unman wrote:
> > On Mon, Mar 05, 2018 at 07:32:47PM +0100, 'Max Andersen' via qubes-users 
> > wrote:
> >> Hi everyone,
> >>
> >> Qubes 3.2 displays the message "This version of XScreenSaver is very
> >> old! Please upgrade!", when the screen is locked with Xscreensaver 5.36
> >>
> >> I haven't seen an update to Dom0 when running sudo qubes-dom0-update, so
> >> is this just annoying or an actual issue?
> >>
> >> Sincerely
> >>
> >> Max
> >>
> >>
> > It's just a reflection of the fact that dom0 is still using fedora 23,
> > which is long past eol. SO no updates for the screensaver.
> > Is it an issue?
> > I don't think there have been advisories since 34, so 5.36 should be fine.
> 
> Didn't think so either, but why did I get the message in the first
> place? Does it check for newer versions or is it just a timer ?
> 
> Sincerely
> Max

Just a timer.

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

Re: [qubes-users] Locked screen message "This version of XScreenSaver is very old! Please upgrade!"

['Max Andersen' via qubes-users]

On 03/05/2018 08:09 PM, Unman wrote:
> On Mon, Mar 05, 2018 at 07:32:47PM +0100, 'Max Andersen' via qubes-users 
> wrote:
>> Hi everyone,
>>
>> Qubes 3.2 displays the message "This version of XScreenSaver is very
>> old! Please upgrade!", when the screen is locked with Xscreensaver 5.36
>>
>> I haven't seen an update to Dom0 when running sudo qubes-dom0-update, so
>> is this just annoying or an actual issue?
>>
>> Sincerely
>>
>> Max
>>
>>
> It's just a reflection of the fact that dom0 is still using fedora 23,
> which is long past eol. SO no updates for the screensaver.
> Is it an issue?
> I don't think there have been advisories since 34, so 5.36 should be fine.

Didn't think so either, but why did I get the message in the first
place? Does it check for newer versions or is it just a timer ?

Sincerely
Max

-- 
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/97a5d8bc-87e3-8dba-288e-432ce2c770d7%40militant.dk.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Locked screen message "This version of XScreenSaver is very old! Please upgrade!"

[Unman]

On Mon, Mar 05, 2018 at 07:32:47PM +0100, 'Max Andersen' via qubes-users wrote:
> Hi everyone,
> 
> Qubes 3.2 displays the message "This version of XScreenSaver is very
> old! Please upgrade!", when the screen is locked with Xscreensaver 5.36
> 
> I haven't seen an update to Dom0 when running sudo qubes-dom0-update, so
> is this just annoying or an actual issue?
> 
> Sincerely
> 
> Max
> 
> 

It's just a reflection of the fact that dom0 is still using fedora 23,
which is long past eol. SO no updates for the screensaver.
Is it an issue?
I don't think there have been advisories since 34, so 5.36 should be fine.

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

[qubes-users] Locked screen message "This version of XScreenSaver is very old! Please upgrade!"

['Max Andersen' via qubes-users]

Hi everyone,

Qubes 3.2 displays the message "This version of XScreenSaver is very
old! Please upgrade!", when the screen is locked with Xscreensaver 5.36

I haven't seen an update to Dom0 when running sudo qubes-dom0-update, so
is this just annoying or an actual issue?

Sincerely

Max



-- 
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/294ac4df-58c1-f61c-9f4c-d1e67c55341d%40militant.dk.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: WordPress on Qubes

[Yuraeitha]

On Sunday, March 4, 2018 at 4:46:53 PM UTC+1, brandonm...@gmail.com wrote:
> Hi,
> 
> So I'm running Qubes on 2 different machines it's amazing. One thing I have 
> never been able to figure out though is how to run WordPress to develop 
> multiple sites.
> 
> I am familiar with Vagrant but it requires Virtualbox however since you can 
> run HVM's you shouldn't need vVirtualbox.
> 
> Any assistance would be much appreciated.
> 
> Kind Regards,

I'm not entirely sure I understand the question though, maybe it's because of 
my lack of insight on this kind of development. But isn't what you seek just a 
matter of making multiple of VM's and run them next to each others? But you 
already seem aware of this right? So what is the question?

As for multiple VM's for development, you can take this a step further and 
isolate them in their own little Qubes network 'playground or sandbox', so that 
one or more VM's acts as a server, and the other VM's acts as a clients 
accessing your server(s), to see how the website behaves on different system 
environments. I've never gotten around to try this though, nor seen anyone do 
this separate network in practice, but it should be possible and is one of the 
things I got on my list to try on Qubes, but that I haven't gotten around to 
yet. It shouldn't be too hard to do though.

It remains uncertain what kind of unknown security attack vectors a separate 
network has on Qubes, I don't believe much security information has been shared 
on this kind of Qubes use-case. For example, if it's two completely isolated 
networks on Qubes, would it make a difference in terms of security? It should 
be possible to answer, but it's an answer we need from security researchers to 
answer as it's a deep and complex question. However, you most certainly don't 
want to allow inter-VN networking on your primary Qubes network though, if you 
can help it, as even with HVM/PVH removing the older inter-VM PV virt_mode 
attack exploits, a inter-VM network might still introduce other exploits or 
make more VM's vulnerable than just the ones you connect together. For example 
if it can use two VM's to attack sys-net/sys-firewall/sys-whonix/VPN's/etc. 
which is also an issue (like how the PV exploit happened), so you might want to 
make a completely separate Qubes network next to each others, with no ties 
in-between them, whatsoever. If you got another LAN port, all the better, 
though I'm not sure how far you need to go to maximize security here, this is 
something you need a security researcher like Joanna or an advanced developer 
like Marek to answer you. But it's vital you don't open up inter-VM networking 
on critical or remotely important VM's, and it might also be a bad idea to mix 
the two networks in general if the sys-firewall/etc. can be attacked from the 
inside-out, instead of outside-in attacks. 

Think carefully if you do something like this, and some security aspects of it 
remains unknown for now. Possibly though, if you completely isolate the two 
networks, it seems feasible that you can do it without opening a caveat can of 
worms (in terms of security). The question remains though, at which point is 
enough isolation, can the networks share the same sys-net? or do they need each 
their own sys-net with each their own physical pass-through network card/cable?

At least if you have the same sys-net, and use two firewalls, then you're still 
protected by the firewalls between the two or more Qubes networks. Qubes is 
also if sys-net/sys-firewall will play nice with other firewalls/networks here. 

Either way, here are some things to dive into if you want to develop this kind 
of things where you need network to see how it behaves. You might only need one 
computer to have multiple of isolated servers/clients.

-- 
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/dee08a72-90f6-41c1-9a0e-65bc03933e91%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] fw for network printer setup

[Unman]

On Mon, Mar 05, 2018 at 09:52:28AM -0800, Yuraeitha wrote:
> On Friday, March 2, 2018 at 9:51:00 PM UTC+1, yre...@riseup.net wrote:
> > On 2018-03-01 18:47, awokd wrote:
> > > On Fri, March 2, 2018 4:20 am, yreb...@riseup.net wrote:
> > >> On 2018-03-01 18:16, awokd wrote:
> > >>
> > >>> On Fri, March 2, 2018 4:10 am, yreb...@riseup.net wrote:
> > >>>
> > >>>
> >  When you see the message "Will you specify the DeviceURI ?",
> > 
> > 
> > 
> >  For USB Users: Choose N(No)
> >  For Network Users: Choose Y(Yes) and DeviceURI number.
> >  ---
> > 
> > 
> > 
> >  So, I chose "yes" then it wanted something like the IPP:// address
> >  ;
> > 
> > >>>
> > >>> You have to put your printer's IP address in here.
> > >>>
> > >>>
> >  I
> >  may have put in the gateway address  and got nowhere I guess your
> >  saying it doesn't matter if it didn't work in the Template ,
> > >>>
> > >>> Right, doesn't matter it doesn't work, but put in the right IP address.
> > >>>
> > >>>
> > >>>
> >  And for the IP address of the printer in the AppVM use the gateway of
> >   the AppVM ?
> > 
> >  in system-config-printer  there are various options  in settings->
> >  device URI: usb://dev/usblp0  is  filled in ,  and in printer state it
> >   say "waiting for printer to become available"
> > >>>
> > >>> Change this to IPP:// and your printer's address.
> > >>>
> > >>>
> > >>>
> >  perhaps I DONT need to tweak the fw settings in the VM Manager,  but
> >  how or do I need to input the IP of the printer  (I have a DDWRT
> >  router fwiw, if I'm supposed to assign a static IP somehow, and if
> >  that is not going to mess up the other computers using the network
> >  printer)
> > >>>
> > >>> Check what IP address they are printing to.
> > >>>
> > >>>
> >  As a final option,  I don't use sys-usb qubes,  so maybe I could
> >  connect the USB cable  and try it that way instead ... sigh
> > 
> > 
> > >>
> > >>
> > >> thanks for responding , as you can see the common theme, is I've no clue,
> > >> how to find my printer IP , and apparently  it may change if it's not
> > >> static?
> > > 
> > > Look in system-config-printer on one of your working systems. Yes, it
> > > might change if it's not static. How did you set up the other system?
> > > 
> > >> I had been told that the gateway address Was the printer IP  , but I've
> > >> really no idea
> > > 
> > > That's usually incorrect, unless the printer is connected directly to your
> > > router by USB.
> > 
> > The working Linux Mint system says :
> > dnssd://Brother%20HL-L2360D%20series._ipp._tcp.local/ 
> > 
> > I pasted that into the AppVM as root with system-printer-config  ->
> > settings-> change -> IPP (ipp)  
> > and IPP (ipps)   with no luck 
> > 
> > I did notice when I launched system-printer-config in terminal I see:
> > Error creating proxy: The connection is closed (g-io-error-quark, 18)
> > 
> > doing a web search on it but not hopeful 
> > 
> > 
> > 1) does it matter is system-printer-config runs as root or user in AppVM
> > 
> > 2) will re running the driver setup /cups etc tarball package conflict
> > with what I already did in the fedora-26-cloneprinter Template VM ?
> > 
> > 3) I'm afraid static IPs  are going to be a nonstarter  for  chronic 
> > newb as myself  https://dd-wrt.com/phpBB2/viewtopic.php?t=263998
> > 
> > 
> > 4) so much for  qubes printing is so easy  posts I've seen .. even
> > without a sys-usb  :P
> 
> 1) As memory serves, no root required. If it doesn't in a legitimate 
> situation ask for root access, don't use it.
> 
> 2) It might be better to just make a new template, this way you cut away 
> clutter and you're sure you don't introduce new issues. As an alternative, 
> you can make CUPS active in your AppVM instead of your Template, by editing 
> this file /rw/config/rc.local which even has an example inside it for CUPS, 
> all you need to do is remove the three # marks. But keep in mind that this 
> will introduce additional exploit/attack surfaces to your AppVM, since CUPS 
> management will stay permanent between AppVM reboots. But in contrast it will 
> allow you easier management to printer changes, which may be important if you 
> make frequent printer adjustments or use it as a remote printer server which 
> requires server changes on the CUPS server. If you just need to install a 
> printer rarely, then it might be better to keep CUPS in the template, and put 
> the driver/IP-address in the template, so that the AppVM can find it.
> 
> 3) Try see if your printer has a Network or System feature that allows you to 
> print out a print of your printers status and information. Many modern 
> printers, and many of a few years old printers too, have this feature today. 
> It might tell you various good things, like for example a name such as DNS 
> name you can use, which stays the same even if the IP changes dynamically.
> 

Re: [qubes-users] fw for network printer setup

[Yuraeitha]

On Friday, March 2, 2018 at 9:51:00 PM UTC+1, yre...@riseup.net wrote:
> On 2018-03-01 18:47, awokd wrote:
> > On Fri, March 2, 2018 4:20 am, yreb...@riseup.net wrote:
> >> On 2018-03-01 18:16, awokd wrote:
> >>
> >>> On Fri, March 2, 2018 4:10 am, yreb...@riseup.net wrote:
> >>>
> >>>
>  When you see the message "Will you specify the DeviceURI ?",
> 
> 
> 
>  For USB Users: Choose N(No)
>  For Network Users: Choose Y(Yes) and DeviceURI number.
>  ---
> 
> 
> 
>  So, I chose "yes" then it wanted something like the IPP:// address
>  ;
> 
> >>>
> >>> You have to put your printer's IP address in here.
> >>>
> >>>
>  I
>  may have put in the gateway address  and got nowhere I guess your
>  saying it doesn't matter if it didn't work in the Template ,
> >>>
> >>> Right, doesn't matter it doesn't work, but put in the right IP address.
> >>>
> >>>
> >>>
>  And for the IP address of the printer in the AppVM use the gateway of
>   the AppVM ?
> 
>  in system-config-printer  there are various options  in settings->
>  device URI: usb://dev/usblp0  is  filled in ,  and in printer state it
>   say "waiting for printer to become available"
> >>>
> >>> Change this to IPP:// and your printer's address.
> >>>
> >>>
> >>>
>  perhaps I DONT need to tweak the fw settings in the VM Manager,  but
>  how or do I need to input the IP of the printer  (I have a DDWRT
>  router fwiw, if I'm supposed to assign a static IP somehow, and if
>  that is not going to mess up the other computers using the network
>  printer)
> >>>
> >>> Check what IP address they are printing to.
> >>>
> >>>
>  As a final option,  I don't use sys-usb qubes,  so maybe I could
>  connect the USB cable  and try it that way instead ... sigh
> 
> 
> >>
> >>
> >> thanks for responding , as you can see the common theme, is I've no clue,
> >> how to find my printer IP , and apparently  it may change if it's not
> >> static?
> > 
> > Look in system-config-printer on one of your working systems. Yes, it
> > might change if it's not static. How did you set up the other system?
> > 
> >> I had been told that the gateway address Was the printer IP  , but I've
> >> really no idea
> > 
> > That's usually incorrect, unless the printer is connected directly to your
> > router by USB.
> 
> The working Linux Mint system says :
> dnssd://Brother%20HL-L2360D%20series._ipp._tcp.local/ 
> 
> I pasted that into the AppVM as root with system-printer-config  ->
> settings-> change -> IPP (ipp)  
> and IPP (ipps)   with no luck 
> 
> I did notice when I launched system-printer-config in terminal I see:
> Error creating proxy: The connection is closed (g-io-error-quark, 18)
> 
> doing a web search on it but not hopeful 
> 
> 
> 1) does it matter is system-printer-config runs as root or user in AppVM
> 
> 2) will re running the driver setup /cups etc tarball package conflict
> with what I already did in the fedora-26-cloneprinter Template VM ?
> 
> 3) I'm afraid static IPs  are going to be a nonstarter  for  chronic 
> newb as myself  https://dd-wrt.com/phpBB2/viewtopic.php?t=263998
> 
> 
> 4) so much for  qubes printing is so easy  posts I've seen .. even
> without a sys-usb  :P

Also as far as I know, Qubes firewall only acts as a NAT, which means it blocks 
in-coming network, but not out-bound network. So if you initiate the connection 
to the printer, it should then allow a full connection for the printer to reach 
back to the AppVM. Last time I did a printer VM, I didn't need anything fancy 
here, it just worked by putting the printers IP (or its DNS network name 
address). So I don't think you need to mess with firewall networking, I'm 
almost sure you only need the address, which the printer should be able to 
print out for you in its settings menu.

-- 
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/2bc856a3-832a-4532-b61f-c09261a15f1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] fw for network printer setup

[Yuraeitha]

On Friday, March 2, 2018 at 9:51:00 PM UTC+1, yre...@riseup.net wrote:
> On 2018-03-01 18:47, awokd wrote:
> > On Fri, March 2, 2018 4:20 am, yreb...@riseup.net wrote:
> >> On 2018-03-01 18:16, awokd wrote:
> >>
> >>> On Fri, March 2, 2018 4:10 am, yreb...@riseup.net wrote:
> >>>
> >>>
>  When you see the message "Will you specify the DeviceURI ?",
> 
> 
> 
>  For USB Users: Choose N(No)
>  For Network Users: Choose Y(Yes) and DeviceURI number.
>  ---
> 
> 
> 
>  So, I chose "yes" then it wanted something like the IPP:// address
>  ;
> 
> >>>
> >>> You have to put your printer's IP address in here.
> >>>
> >>>
>  I
>  may have put in the gateway address  and got nowhere I guess your
>  saying it doesn't matter if it didn't work in the Template ,
> >>>
> >>> Right, doesn't matter it doesn't work, but put in the right IP address.
> >>>
> >>>
> >>>
>  And for the IP address of the printer in the AppVM use the gateway of
>   the AppVM ?
> 
>  in system-config-printer  there are various options  in settings->
>  device URI: usb://dev/usblp0  is  filled in ,  and in printer state it
>   say "waiting for printer to become available"
> >>>
> >>> Change this to IPP:// and your printer's address.
> >>>
> >>>
> >>>
>  perhaps I DONT need to tweak the fw settings in the VM Manager,  but
>  how or do I need to input the IP of the printer  (I have a DDWRT
>  router fwiw, if I'm supposed to assign a static IP somehow, and if
>  that is not going to mess up the other computers using the network
>  printer)
> >>>
> >>> Check what IP address they are printing to.
> >>>
> >>>
>  As a final option,  I don't use sys-usb qubes,  so maybe I could
>  connect the USB cable  and try it that way instead ... sigh
> 
> 
> >>
> >>
> >> thanks for responding , as you can see the common theme, is I've no clue,
> >> how to find my printer IP , and apparently  it may change if it's not
> >> static?
> > 
> > Look in system-config-printer on one of your working systems. Yes, it
> > might change if it's not static. How did you set up the other system?
> > 
> >> I had been told that the gateway address Was the printer IP  , but I've
> >> really no idea
> > 
> > That's usually incorrect, unless the printer is connected directly to your
> > router by USB.
> 
> The working Linux Mint system says :
> dnssd://Brother%20HL-L2360D%20series._ipp._tcp.local/ 
> 
> I pasted that into the AppVM as root with system-printer-config  ->
> settings-> change -> IPP (ipp)  
> and IPP (ipps)   with no luck 
> 
> I did notice when I launched system-printer-config in terminal I see:
> Error creating proxy: The connection is closed (g-io-error-quark, 18)
> 
> doing a web search on it but not hopeful 
> 
> 
> 1) does it matter is system-printer-config runs as root or user in AppVM
> 
> 2) will re running the driver setup /cups etc tarball package conflict
> with what I already did in the fedora-26-cloneprinter Template VM ?
> 
> 3) I'm afraid static IPs  are going to be a nonstarter  for  chronic 
> newb as myself  https://dd-wrt.com/phpBB2/viewtopic.php?t=263998
> 
> 
> 4) so much for  qubes printing is so easy  posts I've seen .. even
> without a sys-usb  :P

1) As memory serves, no root required. If it doesn't in a legitimate situation 
ask for root access, don't use it.

2) It might be better to just make a new template, this way you cut away 
clutter and you're sure you don't introduce new issues. As an alternative, you 
can make CUPS active in your AppVM instead of your Template, by editing this 
file /rw/config/rc.local which even has an example inside it for CUPS, all you 
need to do is remove the three # marks. But keep in mind that this will 
introduce additional exploit/attack surfaces to your AppVM, since CUPS 
management will stay permanent between AppVM reboots. But in contrast it will 
allow you easier management to printer changes, which may be important if you 
make frequent printer adjustments or use it as a remote printer server which 
requires server changes on the CUPS server. If you just need to install a 
printer rarely, then it might be better to keep CUPS in the template, and put 
the driver/IP-address in the template, so that the AppVM can find it.

3) Try see if your printer has a Network or System feature that allows you to 
print out a print of your printers status and information. Many modern 
printers, and many of a few years old printers too, have this feature today. It 
might tell you various good things, like for example a name such as DNS name 
you can use, which stays the same even if the IP changes dynamically.

4) Are you on Qubes 4? That might be why it's a bit more tricky now, since the 
template has no network access to verify if it works or not, while Qubes 3.2. 
templates had network access.

Another work-around, which is by no means official approach, is to disable your 
networks internet access 

Re: [qubes-users] WordPress on Qubes

[799]

Am 05.03.2018 1:34 nachm. schrieb "'awokd' via qubes-users" <
qubes-users@googlegroups.com>:

On Sun, March 4, 2018 3:46 pm, brandonmaytha...@gmail.com wrote:
> One thing I have never been able to figure

out though is how to run WordPress to
> develop multiple sites.
> I am familiar with Vagrant but it requires Virtualbox


Don't have experience with Wordpress in particular, but in general you
could:
1. Create new standalone VM based on debian-9 (or your favorite) template
2. Set up web server on it
3. Set up Wordpress on it
4. Follow
https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes


I don't know what Vagrant is doing for you. If you give me a few hints what
"setting up a development WordPress" looks like, I am pretty sure that we
can script a solution that will do the provisioning for you.

Are you only asking for setting up new AppVMs with a webserver/WordPress in
it which might be reachable from another AppVM or do you need additional
tweaking within the WordPress installation?

[799]

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

Re: [qubes-users] kernel panic after upgrade

[maiski]

yes this was a typo.
it was simple as running grub2-mkconfig again to fix the issue
but thanks for the answer

Quoting awokd :


On Fri, March 2, 2018 8:22 am, mai...@maiski.net wrote:

Hello,


Unfortunately after the last update of Qubes 4.0 I have a kernel
panic: "unable to mount root fa on unknown block" and would appreciate
if somebody here could give me a tip.


I think there is a typo here, try searching on "unable to mount root fs on
unknown block" instead. Looks like there are several possible causes,
especially if you are dual/multi-booting.




--
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/20180305181649.Horde.6UsSzEFInQAgJMbfZUfkNg1%40webmail.df.eu.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Setting up privateinternetaccess on qubes 3.2

[velcro]

Again I have been using the Tasket VPN setup with Fedora 26 for a few weeks and 
it works well...love the kill switch element!

I was hoping to beef up the security(maybe compromise the privacy) of the VPN 
service by adding OpenDNS or Quad9 DNS addresses to this configuration.

My questions I was hoping to get some thoughts on were:

1) I was presented with a Phishing site the other day...understand I am being 
targetted so I am not suprised. Is OpenDNS, Quad9 better then others? Are there 
others that would provide just as good filtering?

2) Tasket I found some documentation in the Qubes-vpn-support-master (README.md 
file) and references the ability to change your DNS address:

You can manually set your VPN's DNS addresses with:
```
export vpn_dns=""
sudo /rw/config/vpn/qubes-vpn-ns up
```

How would I specifically change this? Is this a command? Would this be the 
specific command I would enter into my VPN VM if I was using OpenDNS:

export vpn_dns="208.67.222.222 208.67.220.220"
sudo /rw/config/vpn/qubes-vpn-ns up


I am asking here in the spirit of maybe providing some help to people trying to 
do the same thing...

Gratefully,
V

-- 
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/b3725e34-23d7-4f11-9fc8-e6a3e607f57c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: split gpg failing after moving appvm from debian 8 to debian 9

[cubit]

1. Mar 2018 20:13 by cu...@tutanota.com:


> 1. Mar 2018 20:01 by > un...@thirdeyesecurity.org> :
>
>
>> Which Qubes version are you using?
>> Do you get the Gpg dialog popup?
>
>  
>
>
>
>
> Qubes 3.2 with all templates and dom0 updated as of today.   Yes I get pop up 
> asking do I want to give access to keys for the time period defined by 
> QUBES_GPG_AUTOACCEPT in .bash_profile in work qube (if vault qube is not 
> running it will be started).  I say yes to this and it just errors with 
>
>
>
>
>
> "Error - no matching private/secret key found to decrypt message; click on 
> details button for more information"
>
>
>
>
>
> Clicking on the details button in thunderbird, shows that the message is 
> encrypted to my key
>
>
>
>
> gpg key is a master / sub key set up with the master private key offline if 
> that makes any difference.
>







Here is some type of  answer if anyone else runs into this problem, I did not 
manage to fix this but did work around it.  





 - I created a brand new vault VM based on Debian 9, 


- exported all my keys from old vault

- imported into new vault 


- updated work VM to call new vault




everything works again.




I guess I'll never know why simply changing my original vault VM template from 
Debian 8 to 9 did not work.





Cubit
















-- 
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/L6q_vRC--3-0%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] WordPress on Qubes

['awokd' via qubes-users]

On Sun, March 4, 2018 3:46 pm, brandonmaytha...@gmail.com wrote:
> Hi,
>
>
> So I'm running Qubes on 2 different machines it's amazing. One thing I
> have never been able to figure out though is how to run WordPress to
> develop multiple sites.
>
> I am familiar with Vagrant but it requires Virtualbox however since you
> can run HVM's you shouldn't need vVirtualbox.

Don't have experience with Wordpress in particular, but in general you could:
1. Create new standalone VM based on debian-9 (or your favorite) template
2. Set up web server on it
3. Set up Wordpress on it
4. Follow
https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes


-- 
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/de6dd4719e698a4afc4b9f83a6e08e5a.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Alex Dubois]

Sent from my mobile phone.

> On 5 Mar 2018, at 07:59, 799  wrote:
> 
> Hello Alex,
> 
> 05.03.2018 8:28 "Alex Dubois" wrote:
> 
> I think it is important to keep it as a fork for few reasons:
> - most importantly we focus on helping the Qubes team 
> - if not it would be hard to clean-up what is in Qubes-doc, in the community 
> repo, and if the Qubes-doc get improved directly, it won’t be ported to 
> community, leading to not up to date info
> 
> Valid points, I agree.
> 
> However I think my suggestion is only to be taken with Qubes team validation.
> And if they feel it is not the best way and prefer the mailing lists and 
> existing infrastructure it is important to respect that and get back in line. 
> 
> I love the work of the Qubes Team, don't get to me wrong, but I don't 
> understand why and how they could block the community effort to create a fork?
> Some of use have already forked the docs and are currently developing their 
> own improved scripts.
> Doing so in a collaborative and centralized way would be much better.
> But - I would like to see of course - that Qubes Team is also supporting this 
> idea and knows about it.
Same
> One reason was also to indicate clearly which part of the documentation is 
> official and thereof reasonable secure and which is unofficial and maybe less 
> secure.
> I definitely like the idea of an index page / rating system.
> 
> too much resources discussing this, but rather contribute directly
> 
> Let's go, I am ready to start.
> @David (in his role of the community manager):
> What do you think?
> 
> I feel that a pair/trio need to be “responsible” per area or subject. With a 
> person helped by one or two for the overall. 
> 
> Yes, but we have already some interested people here, I think we only need to 
> discuss the approvement process and how and if of those ideas/scripts might 
> be placed more visible (maybe as a link) somewhere on the Qubes website which 
> is the main area for new users (?).
I agree

Approvement process should have:
- initial Issue exposing the idea and the work proposed = requirements (so that 
we collaboratively shape what will be done, how and by who)
- once this phase is done, a proper concise and precise issue can be raised to 
Qubes 
- work executed with a number of PR on Qubes-doc community (possible individual 
working on their own fork)
- PR approved by interested moderator
- once issue is felt resolved, submit PR to Qubes project (if issue was 
accepted by Qubes)

Some issues may fall outside of official doc (issue or PR get rejected). 
Moderator modify issue to store the result of the work in a community doc with 
the disclaimer you mention (for the one where the issue is accepted by Qubes 
team) we put a work in progress instead. 

> At least a link to it, with maybe a disclaimer:
> 
> "Take a look what is happening in the Qubes Community.
> 
> DISCLAIMER: the content there should be treated as work in progress and has 
> not been reviewed by the Qubes OS Team and maybe thereof less "reasonable 
> secure" or maybe even opening attack vectors to your Qubes installation.
> Even more if you implement a script which you haven't reviewed (and 
> understood) and which has not been marked as meeting the Qubes OS quality 
> standards.
> WARNING:
> If you implement changes in dom0 or the sys-VMs (sys-net, sys-firewall, 
> sys-usb) this might result in a total loss of security"
> 
> For example in the Qubes-doc, there are pages to put dns, http-proxy or vpn 
> in line (I.e. sys-firewall). This is a bad practice as the attack surface of 
> one protocol is exposing the entier Qubes system. 
> A better way is to have these hosted on app-vm and have sys-firewall 
> intercepting and routing the traffic. 
> Even having sys-firewall doing the download rather than a dispvm is 
> increasing the attack surface (not sure if still the case)
> 
> This is a good example, is there a disclaimer or security rating on the 
> qubes-doc pages?

No that I am aware of, and this is were I slap myself on the wrist as I should 
have raised an issue or PR (but this may have wasted time from Qubes team) and 
this could be one of the issue we work collaboratively in the community repo 
shape and refine before sending upstream.

> 
> [799]

-- 
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/96D15406-2197-4284-94D3-DC5860E959C7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Yuraeitha]

On Monday, March 5, 2018 at 9:43:19 AM UTC+1, Yuraeitha wrote:
> This isn't directed directly at anyone in particular, but I don't get why 
> there is all the fuss about a quality issue though, after all, these 
> guides/scripts are meant to have many eyes on them and critical views. Like 
> others have said too. Take for example the suggestion with the multiple 
> sub-forums having moderator volunteers (who have proper insight) moving them 
> along as they mature. This would heighten the quality, by only accepting 
> guides/scripts which had proper review of knowledgeable people, would be put 
> forward. Similar can be done with individual works too, which can be put 
> under review before acknowledged. 
> 
> NASA is doing something similar to this for their research projects, although 
> it does hinder their innovation, but it does increase efficiency on cost and 
> reliability of projects, while still preserving some levels of innovation in 
> it.
> 
> The point here, is that nothing gets through the process before it had proper 
> review, it will only come through if it has a certain quality to it. If 
> creators misses something important, or ignores vital security/reliability 
> implications, this will more likely than not be caught in the review process. 
> Also the review system could be made so that it can withdraw it's 
> acknowledgments, thereby if anyone should ever finds a reliability/security 
> issue, it can be taken back as well.
> 
> If people run un-reviewed or criticized guides/scripts, despite being warned 
> not to, or to be careful and try to understand what the script/guides does 
> before executing it, then if they don't do that, it's their own fault.
> 
> What worries me a bit, are self-fulfilling prophecies, by being worried about 
> an issue, that the person essentially creates the issue by focusing too hard 
> on it. Many of these issues we can solve, it's not rocket science, they're 
> not impossible obstacles that can't be overcome. The problem though, is if 
> some don't want to consider the whole full complete picture, and focuses too 
> hard on their self-fulfilling prophecies. We need to take a step back and 
> reflect more on a holistic and abstract level, before returning to the 
> details again, and then constantly shape the big picture until it improves.
> 
> If guides/scripts are constantly checked and corrected every time someone 
> finds a flaw in them, then what's the issue? Why is this issue blown so much 
> out of proportion? We're talking about a review system no one else is doing 
> on the internet here (maybe I overlooked it, the internet is massive, but 
> it's not common knowledge at least). 
> 
> Generally, the criticism that follow other poor guides/scripts on the 
> internet, does not automatically warrant criticism of guides that are put 
> through an open review system like this.
> 
> I don't want to see criticisms born from examples of other places, when a 
> review suggestion is different from any of these places the criticisms are 
> born. Lets be practical about this, we can't just move criticisms from one 
> place to another, without first taking into account if the system produces 
> the same issues or not. I'm not saying this to any particular person, but an 
> attempt to try get back on the ground again, we're moving too far into the 
> details without looking at the big picture. <-- if a person does that too 
> much, they become legitimately insane as a result, so too a discussion can 
> become insane too. We need some practical reality checks here and stay on the 
> ground.
> 
> It's a bit of irony that wanting closed development by few developers only, 
> kind of echo's the mentality of closed proprietary code, rather than the 
> mentality of open source. The whole idea of open source code, is reviews and 
> checks, this is just a shift towards doing the same with guides/scripts as 
> well.

I mean, if anyone think the NASA approach is flawed, good luck trying to argue 
against it without some pretty solid reasoning. It's true that innovation is 
hindered some (but not totally), but they do manage to cut down cost and 
increase reliability. So too, the same should be for open community 
scripts/guides.

It'd be exactly the same NASA is doing for their development projects. Who is 
still saying it will produce bad guides/scripts? I mean, if anything, these 
checks do increase the reliability/security. Taking examples from elsewhere on 
the internet is futile and pointless, because no one (or very few) are doing 
the same as NASA is doing to ensure quality checks. And this is essentially 
what is being proposed here.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web 

[qubes-users] Re: For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Yuraeitha]

This isn't directed directly at anyone in particular, but I don't get why there 
is all the fuss about a quality issue though, after all, these guides/scripts 
are meant to have many eyes on them and critical views. Like others have said 
too. Take for example the suggestion with the multiple sub-forums having 
moderator volunteers (who have proper insight) moving them along as they 
mature. This would heighten the quality, by only accepting guides/scripts which 
had proper review of knowledgeable people, would be put forward. Similar can be 
done with individual works too, which can be put under review before 
acknowledged. 

NASA is doing something similar to this for their research projects, although 
it does hinder their innovation, but it does increase efficiency on cost and 
reliability of projects, while still preserving some levels of innovation in it.

The point here, is that nothing gets through the process before it had proper 
review, it will only come through if it has a certain quality to it. If 
creators misses something important, or ignores vital security/reliability 
implications, this will more likely than not be caught in the review process. 
Also the review system could be made so that it can withdraw it's 
acknowledgments, thereby if anyone should ever finds a reliability/security 
issue, it can be taken back as well.

If people run un-reviewed or criticized guides/scripts, despite being warned 
not to, or to be careful and try to understand what the script/guides does 
before executing it, then if they don't do that, it's their own fault.

What worries me a bit, are self-fulfilling prophecies, by being worried about 
an issue, that the person essentially creates the issue by focusing too hard on 
it. Many of these issues we can solve, it's not rocket science, they're not 
impossible obstacles that can't be overcome. The problem though, is if some 
don't want to consider the whole full complete picture, and focuses too hard on 
their self-fulfilling prophecies. We need to take a step back and reflect more 
on a holistic and abstract level, before returning to the details again, and 
then constantly shape the big picture until it improves.

If guides/scripts are constantly checked and corrected every time someone finds 
a flaw in them, then what's the issue? Why is this issue blown so much out of 
proportion? We're talking about a review system no one else is doing on the 
internet here (maybe I overlooked it, the internet is massive, but it's not 
common knowledge at least). 

Generally, the criticism that follow other poor guides/scripts on the internet, 
does not automatically warrant criticism of guides that are put through an open 
review system like this.

I don't want to see criticisms born from examples of other places, when a 
review suggestion is different from any of these places the criticisms are 
born. Lets be practical about this, we can't just move criticisms from one 
place to another, without first taking into account if the system produces the 
same issues or not. I'm not saying this to any particular person, but an 
attempt to try get back on the ground again, we're moving too far into the 
details without looking at the big picture. <-- if a person does that too much, 
they become legitimately insane as a result, so too a discussion can become 
insane too. We need some practical reality checks here and stay on the ground.

It's a bit of irony that wanting closed development by few developers only, 
kind of echo's the mentality of closed proprietary code, rather than the 
mentality of open source. The whole idea of open source code, is reviews and 
checks, this is just a shift towards doing the same with guides/scripts as well.

-- 
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/730a36c9-8a8c-46fc-ae4b-1d87b9ad776f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[799]

Hello Alex,

05.03.2018 8:28 "Alex Dubois" wrote:

I think it is important to keep it as a fork for few reasons:

- most importantly we focus on helping the Qubes team
- if not it would be hard to clean-up what is in Qubes-doc, in the
community repo, and if the Qubes-doc get improved directly, it won’t be
ported to community, leading to not up to date info


Valid points, I agree.

However I think my suggestion is only to be taken with Qubes team
validation.
And if they feel it is not the best way and prefer the mailing lists and
existing infrastructure it is important to respect that and get back in
line.


I love the work of the Qubes Team, don't get to me wrong, but I don't
understand why and how they could block the community effort to create a
fork?
Some of use have already forked the docs and are currently developing their
own improved scripts.
Doing so in a collaborative and centralized way would be much better.
But - I would like to see of course - that Qubes Team is also supporting
this idea and knows about it.
One reason was also to indicate clearly which part of the documentation is
official and thereof reasonable secure and which is unofficial and maybe
less secure.
I definitely like the idea of an index page / rating system.

too much resources discussing this, but rather contribute directly


Let's go, I am ready to start.
@David (in his role of the community manager):
What do you think?

I feel that a pair/trio need to be “responsible” per area or subject. With
a person helped by one or two for the overall.


Yes, but we have already some interested people here, I think we only need
to discuss the approvement process and how and if of those ideas/scripts
might be placed more visible (maybe as a link) somewhere on the Qubes
website which is the main area for new users (?).
At least a link to it, with maybe a disclaimer:

"Take a look what is happening in the Qubes Community.

DISCLAIMER: the content there should be treated as work in progress and has
not been reviewed by the Qubes OS Team and maybe thereof less "reasonable
secure" or maybe even opening attack vectors to your Qubes installation.
Even more if you implement a script which you haven't reviewed (and
understood) and which has not been marked as meeting the Qubes OS quality
standards.
WARNING:
If you implement changes in dom0 or the sys-VMs (sys-net, sys-firewall,
sys-usb) this might result in a total loss of security"

For example in the Qubes-doc, there are pages to put dns, http-proxy or vpn
in line (I.e. sys-firewall). This is a bad practice as the attack surface
of one protocol is exposing the entier Qubes system.
A better way is to have these hosted on app-vm and have sys-firewall
intercepting and routing the traffic.
Even having sys-firewall doing the download rather than a dispvm is
increasing the attack surface (not sure if still the case)


This is a good example, is there a disclaimer or security rating on the
qubes-doc pages?

[799]

-- 
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/CAJ3yz2uq%3DMfrp-ZRzRULeTFHtEa%3DQyTxGw2h4r87kwJ6-6k6zQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.