Re: [qubes-users] Re: qrexec demon fails to load any VM when I attach any device
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...
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
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)
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...
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...
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
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)
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
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...
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
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)
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...
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...
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)
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!"
-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
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
-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 https://groups.google.com/d/msgid/qubes-users/c00df96b-2ccc-b162-2731-367fbf2da759%40qubes
Re: [qubes-users] Security questions (templates and kde)
On 03/05/2018 05:39 PM, sevas wrote: Does choosing a TemplateVM have any tactical advantage to security? Does installing KDE have any tactical disadvantage to security? The different operating systems used by the templates may have their own security profiles with varying advantages. Some specific points: * Debian is probably your best choice for all-around security and functionality, particularly for people asking the above questions. The Debian template currently, however, comes in a fairly 'minimal' form which is more secure out of the box but needs a bit of attention to make it more functional. A shortcut to adding desktop features to Debian is to use 'tasksel' and choose a desktop type such as KDE, Gnome, etc. * KDE is used in the Whonix templates distributed with Qubes. Its fine for use in template-based VMs. * IIRC, Fedora was initially chosen by Qubes developers out of expediency and they have stated an intention to eventually move away from Fedora toward something like Debian. In particular, Fedora's downfall is that its one of the very few distros that don't sign/secure their overall software manifest; a MITM attacker can prevent you from receiving specific bug fixes without you realizing. * The fedora-minimal templates may enhance security for some users and admins familiar with Linux, but the above software security problem still exists even there. * Some specialized and experimental templates exist that (supposedly) have security advantages. You can do a search for 'unikernel' for example and try that if you're apt. * Template security can be enhanced in other ways that are not very complicated. For example, you can enable sudo authentication[1] in VMs and enhance that further by adding a service like Qubes-VM-hardening[2]. AppArmor and other measures can also be enabled, but they're not distro specific. Finally, Qubes is designed so that the biggest factor in maintaining security is always how you divide up your data and workflows between VMs; Choice of template isn't as critical. -- 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/acfd4c47-66a2-caa6-99bb-05002d50d970%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Security questions (templates and kde)
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)
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
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
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
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
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
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
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
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
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
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
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
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
> 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!"
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!"
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!"
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!"
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
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
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
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
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 a
Re: [qubes-users] WordPress on Qubes
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
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
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
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
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
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
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 visi
[qubes-users] Re: For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up
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
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.