[qubes-users] A quick survey on usage patterns?

[Alex Smirnoff]

Hi everyone,

anyone willing to share how do you use Qubes environment: tempaltes, VMs, 
etc?
I think besides "tinfoil hat" community many of us do still use traditional 
services like dropbox, g suite, signal, telegram etc.

How do you manage that? A signle VM for several apps? One VM per app? How 
do you print? How do you scan?

As for myself, I have several "per-project" VMs with VPNs and corporate 
messengers, and also a shared one with stuff like evernote and dropbox. I 
removed skype, webex, zoom etc from my work desktop -- I use iPad for all 
of those. I do not even have a webcam and microphone on my work system. 
However, sending a link from the desktop (Qubes) to iPad is not as easy as 
I wish it to be, and the same applies to importing a file. 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d0b99ae7-a772-42ea-a348-20fd9be1a09dn%40googlegroups.com.

Re: [qubes-users] new xen kernel 5.xx

[Alex Smirnoff]

Is there another way to boot to an older kernel rather than boot from other 
media and edit xen.cfg?


>
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/46e325f7-820d-4b26-9c1d-2eb8c6a1c2fcn%40googlegroups.com.

[qubes-users] HCL -- Intel NUC10i7 issues with kernel-latest

[Alex Smirnoff]

5.9.14 does not make it to X11 (empty screen with cursor). 5.8.16 works 
just 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/fd100c0c-7c36-4f6e-9c7b-b27f279836ebn%40googlegroups.com.

Re: [qubes-users] qubes-os // stand-alone reactos fails

[Alex Smirnoff]

I think there is a way to pass /dev/sdX disk device directly to a qube.. 


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6dcdcb3c-ea60-4f68-9d23-cb271c96f945n%40googlegroups.com.

Re: [qubes-users] Re: Someone should port this RDP Windows windower thing for Qubes

[Alex Smirnoff]

Apparently, it is not going to work, too :(

https://github.com/FreeRDP/FreeRDP/issues/6640

Chances we get seamless windows apps anytime soon are slim.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a92daad1-889a-4e7b-a6d0-b98f3762d6f9n%40googlegroups.com.

Re: [qubes-users] Re: Someone should port this RDP Windows windower thing for Qubes

[Alex Smirnoff]

Soo, I gave it a try and guess what? MS Office artifacts are still there, 
with freerdp it is even worse than with native seamless mode. Apparently 
(even if I check "turn hardware graphics acceleration off") Office uses 
some obscure DirectX calls that translate to X11 in very unpleasant way 
that is very unfriendly to window decorator metrics, sloppy focus and 
virtual desktops. I remember I had similar problems with Wine/Crossover as 
well.

https://imgur.com/ff4QoWM

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f3815cfb-d0ca-4552-83fd-f874ecac38f2n%40googlegroups.com.

Re: [qubes-users] Re: Someone should port this RDP Windows windower thing for Qubes

[Alex Smirnoff]

Damn it, this group auto moderation kills messages with imgur hyperlinks on 
spot, however..
I gave it a try and it is even worse. Artifacts of the same origin appear 
on MS Office windows with freerdp just like with seamless mode. Apparently 
it uses some DirectX calls that translate to X11 methods that are extremely 
unfriendly to sensible desktop environment with virtual desktops, sloppy 
focus and custom window decorations.

On Tuesday, December 1, 2020 at 11:10:13 PM UTC+2 Alex Smirnoff wrote:

> From what I remember RDP can handle both.
>
> On Tuesday, December 1, 2020 at 11:00:05 PM UTC+2 evado...@gmail.com 
> wrote:
>
>> very interesting, but if it will be user then need to solve the say 
>> WinVM-to-AppVM file transfers.
>> And not sure about clipboard.
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0d198370-5f2d-4006-9fa9-8e321b5ebd63n%40googlegroups.com.

Re: [qubes-users] Re: Someone should port this RDP Windows windower thing for Qubes

[Alex Smirnoff]

>From what I remember RDP can handle both.

On Tuesday, December 1, 2020 at 11:00:05 PM UTC+2 evado...@gmail.com wrote:

> very interesting, but if it will be user then need to solve the say 
> WinVM-to-AppVM file transfers.
> And not sure about clipboard.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/abf70a72-a802-479f-aa51-f7719dee0e3dn%40googlegroups.com.

[qubes-users] Re: Someone should port this RDP Windows windower thing for Qubes

[Alex Smirnoff]

It would be an ideal solution for me. And should not be very hard. What rdp 
client are they based on?

On Tuesday, December 1, 2020 at 1:57:50 AM UTC+2 Guerlan wrote:

>
> This project:
> https://github.com/Fmstrat/winapps/ 
> 
> does what Qubes do to Linux and Windows 7, but to Windows 10 on KVM, by 
> using RDP. Not the best approach but no one is working on the Windows 10 
> port of the windowing thing. Maybe some people could work on porting this 
> to Qubes, and maybe some prople from Qubes could direct funds to this. 
> I even opened an issue about this:
> https://github.com/Fmstrat/winapps/issues/112
> I miss using Windows properly when I work on Qubes.
> Would be nice if people from here could make some noise there to bring 
> attention :)
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/27ab7304-266c-4b4c-b6e4-d96d55ae1071n%40googlegroups.com.

Re: [qubes-users] Are "smart" monitors/TVs a security issue?

[Alex Smirnoff]

Assuming poor software quality of typical TV firmware and codecs, DVB 
should be pretty easy exploitable. However, I doubt a compromised TV could 
do serious harm to your computer via HDMI. Speaking on your demo.. there is 
a lot of factors to be involved. Chaining a Xen exploit to Chrome might be 
possible.. but unprobable, for a multitude of reasons.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c80eeb69-3fde-40aa-a0b2-e496aecfab4bn%40googlegroups.com.

Re: [qubes-users] Re: Are "smart" monitors/TVs a security issue?

[Alex Smirnoff]

To my best knowledge, no PC graphic card ever supported ethernet over HDMI.


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f254001b-0d75-49ad-810c-c5b093858caen%40googlegroups.com.

[qubes-users] xen resource reporting

[Alex Smirnoff]

It is rather a xen issue, but I did not find xen groups alive enough, so..

I have a 6-core cpu, so.. xen thinks there are two "CPU's" per core, 
probably due to HT.
And it does, apparently, cause a lot of confusion.

from "xenpm start 1:
Socket 0
 Core 0 CPU 0
 Core 1 CPU 2
 Core 2 CPU 4
 Core 3 CPU 6
 Core 4 CPU 8
 Core 5 CPU 10

But, when I try to get CPU states, xenpm assumes the core count to the cpu 
count! thus, it tries to get status of CPU0-CPU5, which succeeds only for 
even CPUs, odd CPUs get dropped and return error when xenp tries to control 
them, and CPU6-CPU10 are ingored.

also, xenpm get-cpufreq-para returns obviously incorrect values (for even 
CPUs only, again, for odd ones it just "falied to get cpufreq parameter" 
and 6-10 are igored), as well as xentop. At the same time, values at 
get-cpufreq-average are apparently right. 

Is it a known issue?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ce8023ed-1a25-4f1d-884e-ddfcc300f835n%40googlegroups.com.

[qubes-users] Re: Are "smart" monitors/TVs a security issue?

[Alex Smirnoff]

For "native" thunderbolt monitors there certainly could be an issue! For 
HDMI/DP, honestly, do not know how much a malicious device could do.


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/299d7cbe-574b-45eb-bbae-7b8998699318n%40googlegroups.com.

[qubes-users] Re: More smooth Win7 seamless mode tweaks?

[Alex Smirnoff]

Well-well-well. Seems that "seamless" mode is not that seamless at all. MS 
Office, for example, tends to throw windows and even _window parts_ that 
get "sticky", "always on top" and de facto not managed by xfce at all :((

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b07e7f8a-0583-41e1-836e-7fc4fe2ae562n%40googlegroups.com.

[qubes-users] Re: Nore smooth Win7 seamless mode tweaks?

[Alex Smirnoff]

Mostly it settled down by itself, but still does not work well with 
focus-follows-mouse setting. I get a lot of screen artifacts, especially 
when multiple Windows windows overlap. Is it a known bug?


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/368c8114-2a01-4af1-a96e-776257a4fcc3n%40googlegroups.com.

[qubes-users] Nore smooth Win7 seamless mode tweaks?

[Alex Smirnoff]

Just installed my first Win7 VM. Not exactly a pleasant look. Programs try 
to start fullscreen and somewhat misbehave later-- say, when I try to 
resize MS Word window, it does not understand the geometry change event and 
some parts of it just become invisible. Was it always like that or 
something is not quite right with my system? Any hints/tweaks/fixes known?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/448b98fc-5a06-4e8d-8682-605985a22647n%40googlegroups.com.

[qubes-users] browser plugin?

[Alex Smirnoff]

Is there a browser plugin that adds "open URL in disposable VM" function? 
like private tab on steroids :)

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/93eeb945-444e-4daf-81c3-5f958c7b8896n%40googlegroups.com.

[qubes-users] Re: Intel CPU frequency scaling and boost mode?

[Alex Smirnoff]

Ah. As I said, it is all tricky. First, enable legacy boot. It is greyed 
out in bios setup; you need to turn off "modern standby" first. Now you can 
boot.

But, it is going to be 800x600 and no network (neither wired or wireless). 
On the next step you need a USB network card. Once you get *some* network, 
do sudo qubes-dom0-update kernel-latest kernel-latest-qubes-vm. Then edit 
/boot/efi/EFI/qubes/xen.cfg 
and get rid of rhgb, it is broken.
And if you are lucky, you now have a working system!

I wonder why Qubes does not have offline update mechanism or more recent 
installation media. All this crazy stuff reminds me of installing Slackware 
in 1996 on a random hardware from local flea market.

On Tuesday, November 10, 2020 at 6:00:06 PM UTC+2 adrian...@gmail.com wrote:

> Hi there - I am struggling to get past the boot screen with my gen10 intel 
> - care to share any helpful tips of how things worked for you that might be 
> helpful?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/594d672e-5658-4a61-9924-642ea33a1861n%40googlegroups.com.

[qubes-users] Re: device widget sends "device removed" / "device available" at random times

[Alex Smirnoff]

I have random disconnects like that with cheap chinese USB hub i ordered on 
Aliexpress. Never seen with built-in USB ports :)


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5a9eaf8e-590b-4af9-97c3-ed79648ecab6n%40googlegroups.com.

Re: [qubes-users] Intel CPU frequency scaling and boost mode?

[Alex Smirnoff]

Though I played a bit with xenpm and apparently frequency scaling works as 
intended! It is just not reported properly even to dom0.


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/cd00b79d-0125-4a41-ad5c-a75fa7335188n%40googlegroups.com.

Re: [qubes-users] Intel CPU frequency scaling and boost mode?

[Alex Smirnoff]

Tried to modprobe it explicitly, does not load :-/

On Saturday, November 7, 2020 at 12:02:55 AM UTC+2 Jarrah wrote:

>
> > I just installed (not to say it was easy) Qubes on gen10 intel NUC.
> > It has a "mobile" type CPU, 1.6Ghz with turbo boost up to 4GHz.
> > However, Xentop never shows frequencies higher than 1.6 no matter if I 
> have 
> > a CPU-intensive task or not. Does turbo boost work as expected?
>
>
> There is a lengthy discussion at 
> https://github.com/QubesOS/qubes-issues/issues/4604 about this with some
> potential fixes.
>
> I just resolved a similar issue on 4.1 where my laptop was locked to 800
> MHz. The `xen-acpi-processor` kernel module was the problem there. Your
> issue may be something else, but that thread is likely the best place to
> find information about it.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/62364b6e-8f82-41dd-875e-e6b58df38c67n%40googlegroups.com.

[qubes-users] Intel CPU frequency scaling and boost mode?

[Alex Smirnoff]

Hi fellow qubes users,

I just installed (not to say it was easy) Qubes on gen10 intel NUC.
It has a "mobile" type CPU, 1.6Ghz with turbo boost up to 4GHz.
However, Xentop never shows frequencies higher than 1.6 no matter if I have 
a CPU-intensive task or not. Does turbo boost work as expected?

Also, I have an arduino-based analog meter controlled by USB I used on my 
previous systems to collect and display system load metering. However, most 
of the data is available in dom0 only. What is the best practice to send it 
to an AppVM?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/24d6e526-4f27-4942-8282-780b83ac61a9n%40googlegroups.com.

[qubes-users] Re: win7 seamless mode, teams, vmware

[Alex Smirnoff]

I would rather use native Teams client. 

However, regarding Win7 seamless mode (to which I am yet to give a try), is 
there a chance we will ever get rid of that ugly double window decorations? 
:)

On Monday, November 2, 2020 at 12:50:27 PM UTC+2 Rasta Bude wrote:

> Hello,
> I try to run Windows 7 in seamless mode at my Qubes. So far everything ist 
> working great. I just have some problems with microsoft teams there. I only 
> see a white screen and cannot login. If I install a normal Windows 7 HVM 
> like in the description without Qubes Windows tools then it is running. Can 
> u tell me what I can try to fix this? It will be good for my work, to run 
> Teams in seamless mode, because then I don't need to copy the file between 
> vm's and else. I even tried it with several Windows7 images, And I am only 
> able to install a seamless Windows 7HVM via qvm-create-windows-qube.sh, 
> because I don't find how to activate the *seamless mode* in a Winodws 7 
> HVM. The Quibes documentary is not up to date at this section and said u 
> can do this in the Qubes Manager, but there I cannot find this option.
> Maybe there is a working *solution* *via terminal? T*hat will be really 
> great, then I can try to install a fresh win7 hvm with my own Iso, where 
> all the updates are integrated...Maybe this will work.:)
> Or ist it possible to run *vmware on the qubes fedora or debian template*? 
> But I don't think so, because at Debian I always get an error GNU C 
> compiler 6.4.1 not found and at Fedora it install vmware, but while 
> installing it started uninstalling and cannot finish the installation. But 
> if this is possible it will be a solution, too and I am very thankful to 
> hear how to fix that problem.:)
> Stay healthy, Best wishes and much thanks for ur support.
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/38c48597-e22e-4f8c-a64a-d2b2e5a4975fn%40googlegroups.com.

Re: [qubes-users] [unofficial] Qubes security advisory

[Alex Smirnoff]

I would make a full forensic image and then start investigating. Otherwise 
the evidence is very fragile.

On Friday, November 6, 2020 at 12:20:32 AM UTC+2 tetra...@danwin1210.me 
wrote:

> On Mon, Oct 26, 2020 at 04:04:30PM -0400, Chris Laprise wrote:
> >On 10/25/20 10:24 PM, 'J.M. Porup' via qubes-users wrote:
> >>One morning last week, I launched a disposable Debian 10 template with 
> my preset
> >>defaults of no netvm and a blank page preset--but instead a default page 
> of
> >>"https://www.youtube.com/"; appeared. It only happened once, but it was 
> enough.
> >
> >So to clarify, you launched a dispVM with no networking, and a youtube 
> >page was loaded and rendered on screen?
> >
> >That seems highly unlikely to be an accidental input or glitch.
>
> No, he's saying the Firefox homepage in his Debian-10 template was 
> changed from about:blank to youtube.com, leading the debian-10 
> template-based DispVM to launch Firefox with youtube.com as the default 
> page.
>
> Ergo someone compromised his Debian-10 template and changed the Firefox 
> homepage... or, there was an error in the template configuration leading 
> to him accidentally changing the hompeage in what sounds like a 
> stressful situation.
>
> J.M., assuming you are indeed correct about a major attack, most of the 
> major Xen vulnerabilities that threaten a Qubes full compromise involve 
> sys-net. Since Five Eyes may get advance notice of Xen holes, if your 
> machine was indeed fully rooted it could be you were hit by the PCI 
> vulnerability from a while back.
>
> Due to precisely these kinds of issues, there is discussion for using 
> the much-harder-to-exploit OpenBSD as an operating system for the 
> sys-net VM:
> https://github.com/QubesOS/qubes-issues/issues/5294
>
> You may want to give it a go (after buying a new laptop, of course).
>
> Additionally, if a sys-net based attack is indeed a concern for your 
> threat model, consider disabling wi-fi entirely and using an ethernet 
> cable, wi-fi drivers are generally terrible.
>
> Nevertheless if you are really up against serious Five Eyes type 
> adversaries then it's unlikely you'll be able to keep *any* computer 
> secure for long and should probably buy that cabin in the Rockies you 
> always wanted...
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b70d4e94-7e63-4da1-819c-c72cf2a085e7n%40googlegroups.com.

Re: [qubes-users] Re: HCL - intel NUC10i7FNK

[Alex Smirnoff]

I had to update it first. Also, removed rhgb to get around the password 
prompt bug. 
What an amazing system! I installed it to evaluate if it is suitable for 
our company environment and instantly fell in love with it. However, the 
answer to my main question is still "no" :(. Unless we buy certified 
hardware for everyone, at least, and some of us badly need properly working 
Win10 guest with seamless desktop app integration and clipboard :(

On Friday, October 30, 2020 at 9:28:26 PM UTC+2 Ludovic Bellier wrote:

> Le 30/10/2020 à 19:52, Alex Smirnoff a écrit :
> > Now, that's strange! my dom0 is on the latest kernel, but sys-net is 
> > not, so, no network there.
> >
> Its normal, all VMs keep the default kernel, not the latest.
>
> You should change the sys-net VM kernel to latest:
>
> - open Qube Manager
>
> - select sys-net
>
> - right clic, choose Qube-settings
>
> - Advanced tab, change the kernel to 5.x.x
>
> - Apply and restart sys-net
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d1e5-3683-40f9-9d48-15efa61bfac1n%40googlegroups.com.

Re: [qubes-users] Re: HCL - intel NUC10i7FNK

[Alex Smirnoff]

Now, that's strange! my dom0 is on the latest kernel, but sys-net is not, 
so, no network there.


>
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/75886e94-6179-4d10-bc90-fdbbdd7b9197n%40googlegroups.com.

Re: [qubes-users] Re: HCL - intel NUC10i7FNK

[Alex Smirnoff]

apparently I messed with the keyboard somehow, I cannot type in the password. 
it ignores all keystrokes :(




Sent from my BlackBerry -- I don't believe it's more secure, but I've got a 
physical keyboard!



  Original Message  


From: qubes-u...@zyrianes.net
Sent: October 30, 2020 7:26 PM
To: qubes-users@googlegroups.com
Subject: Re: [qubes-users] Re: HCL - intel NUC10i7FNK


Le 30/10/2020 à 17:57, Alex Smirnoff a écrit :
> Ah, apparently it was just a glitch, second time I tried my keyboard
> remained functional.

Good.

> However, still no luck: after I updated dom0 to the latest kernel, my
> Qubes system just got stuck on "Enter disk password" stage. I see some
> corrupted image below

It's same for me, I see the corrupted image on each boot (since 6 months
now), but (on my host) it's only a display problem, I can give the disk
password (you should see the bullet [3] for each character) and the boot
process continues. Note that this step concerns giving the LUKS
credentials (not the user password!), and the GUI you see is Plymouth
[1] with this artwork [2].

> which slightly changes over time, and that's it. And I cannot switch
> to text console to see what is happening there like I could on a
> regular linux. WIll try booting from a rescue image now. Anyway, Qubes
> on NUC10 is apparently very unstable. I wonder why there is no ISO
> image with the latest kernel already in place.
>
You can't switch to tty (text console) because the boot process is on
the LUKS uncryption step, so the rootfs isn't yet available (so the init
process isn't launch and neither the login process).

Don't worry, Qubes OS on NUC10 is stable, I use it daily.

I agree an ISO image with, on start, the choice between default or
latest kernel will be great.

[1] https://wiki.archlinux.org/index.php/Plymouth

[2] https://github.com/QubesOS/qubes-artwork/tree/master/plymouth/qubes-dark

[3]
https://github.com/QubesOS/qubes-artwork/blob/master/plymouth/qubes-dark/bullet.png

--
You received this message because you are subscribed to a topic in the Google 
Groups "qubes-users" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/qubes-users/vRKrs5ZIg9c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a3f5a5ad-346c-71ed-54b3-f3e30b7fb75f%40zyrianes.net.

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

Re: [qubes-users] Re: HCL - intel NUC10i7FNK

[Alex Smirnoff]

Ah, apparently it was just a glitch, second time I tried my keyboard 
remained functional.
However, still no luck: after I updated dom0 to the latest kernel, my Qubes 
system just got stuck on "Enter disk password" stage. I see some corrupted 
image below which slightly changes over time, and that's it. And I cannot 
switch to text console to see what is happening there like I could on a 
regular linux. WIll try booting from a rescue image now. Anyway, Qubes on 
NUC10 is apparently very unstable. I wonder why there is no ISO image with 
the latest kernel already in place.

On Friday, October 30, 2020 at 6:53:29 PM UTC+2 Ludovic Bellier wrote:

> Le 30/10/2020 à 16:37, Alex Smirnoff a écrit :
> > How did you set up the sys-usb qube without losing the USB keyboard 
> > and mouse?
> >
> Hi Alex,
>
> I followed the Qubes documentation, first I added the sys-usb Qube 
> [1], then I added my USB keyboard available for login [2].
>
>
> [1] https://www.qubes-os.org/doc/usb-qubes/#creating-and-using-a-usb-qube
>
> dom0/Terminal : sudo qubesctl state.sls qvm.sys-usb
>
> [2] 
> https://www.qubes-os.org/doc/usb-qubes/#enable-a-usb-keyboard-for-login
>
> dom0/Terminal : sudo qubesctl state.sls qvm.usb-keyboard
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9a3acb1f-9805-45f6-b14d-cb4f4c6eb8a4n%40googlegroups.com.

[qubes-users] Re: HCL - intel NUC10i7FNK

[Alex Smirnoff]

How did you set up the sys-usb qube without losing the USB keyboard and 
mouse?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f3a07c2b-5dd2-4886-8f1f-d2a2bb872ac8n%40googlegroups.com.

[qubes-users] HCL - MacBook Air A1369

[Alex Long]

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d4a1f16d-7382-ab59-7763-de98df0087bf%40igniterefereeing.com.au.


Qubes-HCL-Apple_Inc_-MacBookAir4_2-20200810-153605.cpio.gz
Description: application/gzip


Qubes-HCL-Apple_Inc_-MacBookAir4_2-20200810-153605.yml
Description: application/yaml

[qubes-users] HCL - GPD Win Max

[Alex Long]

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/de6a362e-2f5b-564c-a551-da90766ba9a9%40igniterefereeing.com.au.


Qubes-HCL-GPD-G1619_01-20200924-105918.cpio.gz
Description: application/gzip


Qubes-HCL-GPD-G1619_01-20200924-105918.yml
Description: application/yaml

[qubes-users] How to properly delete logs in an entire system?

[Alex Lu]

After using Qubes for a while I have a lot of logs (>10GB) and I'd like 
to delete them. Will it be fine if I just delete them like this in each 
templateVM?


find /var/log -type f -delete

Also, would it be bad if I simply turn the logggin off and turn it on if 
needed?


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c991caf0-8839-7055-15fd-59e0b58081b4%40cock.li.

[qubes-users] How to create application shortcuts for Flatpak apps?

[Alex Lu]

I have a couple AppVMs with flatpak apps installed on them (with a --
user flag) and I can't figure out how to do it. There is guide
explaining how to do it, but it expects you to have flatpak apps
installed in TemplateVM. Is it possible to do?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/801be36725a7f3c6e67b0030a926da5bb452f15e.camel%40cock.li.

Re: [qubes-users] Squares instead of Characters in (?)nautilus

[Alex Lu]

Hi, Oleg! Thank you for your input.

I fixed the issue by installing missing packages. Those packages are:
liberation-fonts-common liberation-mono-fonts liberation-sans-fonts
liberation-serif-fonts

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8cb7805f6c8f044048e660752d6c93d8ee47506f.camel%40cock.li.

[qubes-users] Squares instead of Characters in (?)nautilus

[Alex Lu]

When I try to do anythings that opens "Open Folder" window, I see only 
squares instead of characters. https://i.imgur.com/YdXpIWW.png


This behavior began after I moved from fedora-31 to fedora-32-minimal 
template. I already deleted the previous vm, so I couldn't even check if 
there is something I need to have installed to make it work correctly.


Nautilus itself works fine, though.

--
Alex

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

Re: [qubes-users] How to make aliases persistent?

[Alex Lu]

Ah, it was that easy! Sometimes I get stuck on things like this and 
can't find the answer myself. Thank you, Peter!


--
Alex

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

[qubes-users] How to make aliases persistent?

[Alex Lu]

For example, when I type:

alias ll='ls -lh'

it works just fine, but after restarting the VM (either appVM or 
templateVM), I have to do all over it 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f4bdeff4752aba424b3e2a7e2ee85175%40cock.li.

[qubes-users] Security benefits of rootless template VMs

[Alex Lu]

I've been thinking about splitting my templateVMs into a bunch of 
smaller ones with no root access where I don't need it. Is having like 5 
templateVMs 4 of which have no root is better than having 1 templateVM 
which have root and in charge of every appVM? Or there is no security 
benefits considered I never do anything in templateVMs, besides 
installing packages, all of which are from official repos?


Alex

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

Re: [qubes-users] docker install problems on debian-10

[alex . xiong . tech]

confirmed the same issue encountered here, also on Debian 10 TemplateVM, 
latest stable QubesOS

On Wednesday, May 27, 2020 at 8:42:59 PM UTC+8, haaber wrote:
>
> > Hey, I experience trouble while trying to install docker accordingly to 
> > https://docs.docker.com/engine/install/debian/ on debian-10. It 
> apprears 
> > that aufs.ko (whatever that is) makes trouble 
> > 
> > Building initial module for 4.19.120-1.pvops.qubes.x86_64 
> > Error! Bad return status for module build on kernel: 
> > 4.19.120-1.pvops.qubes.x86_64 (x86_64) 
> > Consult /var/lib/dkms/aufs/4.19+20190211/build/make.log for more 
> > information. 
> > dpkg: error processing package aufs-dkms (--configure): 
> >   installed aufs-dkms package post-installation script subprocess 
> > returned error exit status 10 
> > Errors were encountered while processing: 
> >   aufs-dkms 
> > E: Sub-process /usr/bin/dpkg returned an error code (1) 
> > 
> > Could someone help me, with a hint, please? Cheers, Bernhard 
> > 
> I append my own question by a detail: Since I am asked to consult the 
> make.log file, here is why it fails. I have no way to fix that without 
> some help. Maybe sme headers missing ?? 
>
>
> from /var/lib/dkms/aufs/4.19+20190211/build/fs/aufs/sbinfo.c:23: 
> /var/lib/dkms/aufs/4.19+20190211/build/fs/aufs/super.h:134:2: error: 
> unknown type name ‘vfs_readf_t’ 
>vfs_readf_t  si_xread; 
>^~~ 
> /var/lib/dkms/aufs/4.19+20190211/build/fs/aufs/super.h:135:2: error: 
> unknown type name ‘vfs_writef_t’ 
>vfs_writef_t  si_xwrite; 
>^~~~ 
> In file included from 
> /var/lib/dkms/aufs/4.19+20190211/build/fs/aufs/branch.h:33, 
>   from 
> /var/lib/dkms/aufs/4.19+20190211/build/fs/aufs/aufs.h:38, 
>   from 
> /var/lib/dkms/aufs/4.19+20190211/build/fs/aufs/module.c:25: 
> /var/lib/dkms/aufs/4.19+20190211/build/fs/aufs/super.h:134:2: error: 
> unknown type name ‘vfs_readf_t’ 
>vfs_readf_t  si_xread; 
>^~~ 
> /var/lib/dkms/aufs/4.19+20190211/build/fs/aufs/super.h:135:2: error: 
> unknown type name ‘vfs_writef_t’ 
>vfs_writef_t  si_xwrite; 
>^~~~ 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/bf0eb057-372a-4c1f-a269-7e067638b2bf%40googlegroups.com.

Re: [qubes-users] Grub with encrypted boot

[alex . barinov]

Can you elaborate on this a bit please? Or point at some manual that could 
help get started with th topic? While the concept sounds familiar I don't 
have enough experience to build a secure boot environment from scratch - 
and that's what needs to be done in case of Qubes.

On Wednesday, May 6, 2020 at 9:16:54 AM UTC+2, dhorf-hfr...@hashmail.org 
wrote:
>
> On Wed, May 06, 2020 at 06:21:00AM +, lamboicarus via qubes-users 
> wrote: 
> > I am wondering if anyone knows how I might install grub for use with 
> > an encrypted boot partition, or no boot partition at all. I have 
> > recently decided to use btrfs, and I have grub working fine. The 
> > grub2-efi config from the qubes-dom0-unstable repo is working fine, 
> > but it's very complex. Reading about grub on the arch-wiki, it says 
>
> boot security is a very complex topic. 
>
> just encrypting your /boot but keeping an unencrypted grub 
> around that opens that /boot is not increasing your security 
> in any meaningful way. it just adds a pile of fragility. 
>
> for actual cryptographic boot security, you need a "verified" 
> and/or "measured" boot setup. 
>
> since you mentioned "efi", i would recommend an efi-heads hybrid. 
> deploy a linux kernel with _internal_ initrd (!) as efi-verified 
> boot payload. this way you have to do the efi-signing "just once", 
> and from that linux kernel you can open your encrypted /boot 
> in the "natural linux ways". 
>
> if your "bios" takes measurements during boot, do tpmtotp (or similar) 
> from the first stage linux (before unlocking your /boot) you dont even 
> have to do any modifications to the payloads inside /boot ... 
> so no resigning/resealing on every payload-xen/kernel update either! 
>
> this setup does not involve grub at all. this is intentional. 
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8afd7aef-5470-4ab3-b83b-2dccd1246414%40googlegroups.com.

[qubes-users] Re: Mounting directories across VMs (losetup/block device solution for directories)?

[alex . barinov]

I don't think you can achieve this by block device sharing unless you 
spread your directory structure across block devices exactly in a way you 
are going to share it with VMs - and even in that case you'll not be able 
to share with VM and sync with Dropbox at the same time (you didn't specify 
if that's required).

I suggest you explore the options of network shares using 
NFS/SAMBA/FTP/WebDAV/etc - together with passing just that network port to 
the target VM this can be a good solution.

On Wednesday, February 26, 2020 at 10:23:41 PM UTC+1, Johannes Graumann 
wrote:
>
> Hi, 
> I'm experimenting with creating a sys-dropbox vm that syncs with my 
> dropbox account. I would love to be able to then mount defined 
> subdirectories of the synced path to other vms (losetop/qvm-block- 
> style, which only works for files). 
> Is this possible? Where to find pointers? 
>
> Sincerely, Joh 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3a9ee4f4-0795-45b4-bfb9-4b674483a010%40googlegroups.com.

[qubes-users] Re: Making a HVM VM start in headless mode

[alex . barinov]

The following settings work for me:
1. Set "debug" to "False" in qvm-prefs
2. Set "gui" to "False" and "gui-emulated" to "False" 

The only problem is qubes (or xen) keeps cashed info on whether to show 
emulated console. Sometimes the settings work immediately, sometimes after 
a reboot, sometimes I need to delete old vm files laying abound.

On Sunday, January 12, 2020 at 4:28:30 AM UTC+1, tetra...@danwin1210.me 
wrote:
>
> When I create a HVM VM, by default I have the console window of the VM 
> open all the time when it is running. 
>
> Sys-net is HVM by default but there is no console window. 
>
> How do I set this up for other HVM VMs? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e2159ed7-4fb1-470d-8076-0ce40e0d9995%40googlegroups.com.

[qubes-users] DisplayLink

[Alex]

Hi everyone

I can see that Qubes recognises my DisplayLink Dell D3100 USB3 dock; it's 
listed in the "Qubes Devices" widget in the panel. But, xfce's window manager 
seems to only recognise one screen (my laptop's built in LCD). No mention of my 
external monitors.

How can I fix this?

Thanks, 

Alex

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7CF4621E-E02D-4A21-A631-4424C6B99CA4%40gmail.com.

Re: [qubes-users] Re: Receive-only email VM

[Alex Barinov]

  
  
As long as your
dedicated Thunderbird VM has internet connection (which it needs
to receive email) an attacker can get any data out of it using
Thunderbird exploits, whether you set up outgoing mail server or
not.


  Kind regards,
  Alex


On 8/7/19 4:18 AM, V C wrote:


  
  Couldn't you just use a dedicated VM and
thunderbird, don't set up outbound in thunderbird?

On Tuesday, August 6, 2019 at 1:11:32 AM UTC-5,
    alex@gmail.com wrote:

  Some time ago there was a post on reddit (https://www.reddit.com/r/Qubes/comments/9q76f2/splitmail_setup/)
that described setting up an offline mail vm. Just kill the
"send" part there and you'll get a mail black hole that
receivs but never sends. Seems like this is more or less
what you want.

On Tuesday, August 6, 2019 at 5:06:54 AM UTC+3, redd...@vfemail.net wrote:

  
In Qubes, is it possible to set up a VM that can
  receive email, but not send information out, via email
  or otherwise?
  
  The motivation is: Many online accounts rely on an
  email address to reset passwords. However, the VM that
  handles inbound emails, processes a lot of untrusted
  input. If the VM gets compromised by an attacker, the
  attacker can then send password reset emails and read
  them. So to defend against this, I want to prevent the
  compromised VM from communicating out the contents of
  these password reset e



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

[qubes-users] Re: Receive-only email VM

[alex . barinov]

Some time ago there was a post on reddit (
https://www.reddit.com/r/Qubes/comments/9q76f2/splitmail_setup/) that 
described setting up an offline mail vm. Just kill the "send" part there 
and you'll get a mail black hole that receivs but never sends. Seems like 
this is more or less what you want.

On Tuesday, August 6, 2019 at 5:06:54 AM UTC+3, redd...@vfemail.net wrote:
>
> In Qubes, is it possible to set up a VM that can receive email, but not 
> send information out, via email or otherwise?
>
> The motivation is: Many online accounts rely on an email address to reset 
> passwords. However, the VM that handles inbound emails, processes a lot of 
> untrusted input. If the VM gets compromised by an attacker, the attacker 
> can then send password reset emails and read them. So to defend against 
> this, I want to prevent the compromised VM from communicating out the 
> contents of these password reset emails.
>
> Specifically:
> 1. Assume the VM is compromised (can't rely on in-VM enforcement 
> mechanisms).
> 2. Assume the email provider is not compromised
>
> To further illustrate the problem, here are example setups and why they 
> don't work:
>
> Setup 1: Use qubes firewall to restrict to the email provider's server and 
> IMAP port. Block UDP requests using qvm-firewall.
> Why it doesn't work: Attacker can create an account on the same email 
> provider and connect to their account (the firewall rules will not prevent 
> this). They can then sync emails containing any data, to their account.
>
> Setup 2: Like Setup 1, but use POP3.
> Why it doesn't work: Attacker creates account at provider, transmits data 
> via POP3 delete operations.
>
> Does anyone have a email setup with this inbound-only property, ideally 
> that does not require running their own email server?
>
> Thank you.
>
>
> -
> This free account was provided by VFEmail.net - report spam to 
> ab...@vfemail.net 
>  
> *ONLY AT VFEmail!* - Use our *Metadata Mitigator*™ to keep your email out 
> of the NSA's hands! 
> $24.95 ONETIME Lifetime accounts with Privacy Features!
> No Bandwidth Quotas!   15GB disk space! 
> Commercial and Bulk Mail Options! 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/bfb49d87-20e4-44c5-af4a-ef2e0e931cec%40googlegroups.com.

[qubes-users] Re: email fetching /reading

[alex . barinov]

On Thursday, May 2, 2019 at 3:02:29 AM UTC+3, haaber wrote:
> Dear all, I was meditating (once more) about email fetching. I guess the
> qubes way I should
> 
> - use a mail-VM that runs offline-imap and places mail
>in different folders, one for each email account. Best over tor,
>to avoid being identified (when mobile) via the mail-host-combination
>I use.
> - start a disp-VM that kills spam and runs some antivirus
>(comments invited if that is helpful / needed )
> - then "qvm-sync" (we have that one?) the cleared folders
>to the respective mail-reading-VMs (private / work, for me).
> 
> is that the right construction? Cheers,

You might want to have a look at my offline mail setup described here: 
https://www.reddit.com/r/Qubes/comments/9q76f2/splitmail_setup/

It lacks anti-spam/anti-virus part (which is a cool idea, I'll implement this) 
but otherwise is close to what you describe.

-- 
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/74f1e926-d4eb-4841-8635-6d3a464918fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Fully Working Android VM for Qubes available? (2019)

[alex . jones . 4416]

On Wednesday, April 24, 2019 at 3:33:54 AM UTC, benz magdalena wrote:
> Android-x86 8.1 got released recently,
> 
> the lagging mouse issues have been fixed but the main problem is the 
>   Android-x86 8.1 iso
> can not be installed cause it fails to detect the qubes virtual disks 
> 
> is there any 'easy' way to fix this error without compiling 
> 160GB of data to change the config...
> 
> any fully working iso available for download for qubes?
> 
> 
> how to solve this issue the easiest?
> 
> 
> thanks

You need to fix not only installer scripts, but you need to rebuild kernel as 
well. I think it's possible to rebuild only kernel and fix the installer files 
and then repack the iso.

I've uploaded the working Android 8.1 iso, but I don't recommend to use it for 
security reasons and it's better to build the iso yourself:
https://drive.google.com/open?id=1Y4P77mlPPlXBzYrJ5yHJ7XM6gLVsQQm0

md5sum android_x86_64-oreo-nogapps.iso 
b3af7a84820dd9fb32dd40c68f285993  android_x86_64-oreo-nogapps.iso

sha1sum android_x86_64-oreo-nogapps.iso 
16e9bcf0da44929b223fc2ab1df97de0df26d9fb  android_x86_64-oreo-nogapps.iso
sha256sum

sha256sum android_x86_64-oreo-nogapps.iso 
b7d9aa5f9c401202ea24b63e95bb0f38d1f981381a719257c1a2f526e0cf636f  
android_x86_64-oreo-nogapps.iso

sha512sum android_x86_64-oreo-nogapps.iso 
16f2666a20499f31472fc933a670c47070e0db14686b605b69254d054dcc63893b564e5a35e84e1daf7b7fd80f955a2834956a1bb029e93563b7d8c44787666b
  android_x86_64-oreo-nogapps.iso

-- 
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/d1ef17a0-9f29-4237-9947-f84845985178%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Android-x86 7.1-r2 with GAPPS installation guide

[alex . jones . 4416]

On Saturday, April 27, 2019 at 9:35:19 PM UTC, alex.j...@gmail.com wrote:
> On Thursday, April 25, 2019 at 10:20:32 PM UTC, Daniil Travnikov wrote:
> > I am stuck on this process already twice.
> > 
> > When I put the command
> > 
> > Download sources:
> > repo sync --no-tags --no-clone-bundle --force-sync -j$( nproc --all )
> > 
> > 
> > and when it show this:
> > 
> > 
> > From git://git.osdn.net/gitroot/android-x86/platform/frameworks/av
> >  * [new branch]  nougat-x86 -> x86/nougat-x86
> > Fetching project platform/external/android-clat
> > remote: Counting objects: 1, done
> > remote: Finding sources: 100% (793/793)   
> > remote: Total 793 (delta 244), reused 793 (delta 244)
> > Receiving objects: 100% (793/793), 517.38 KiB | 0 bytes/s, done.
> > Resolving deltas: 100% (244/244), done.
> > From https://android.googlesource.com/platform/external/android-clat
> >  * [new tag] android-7.1.2_r36 -> android-7.1.2_r36
> > 
> > 
> > I got nothing, I mean it's look like freeze.
> 
> Did you try to remove downloaded repo and sync it again from scratch? The 
> OpenGAPPS repo changed, see below, maybe it's somehow related.
> 
> I'd recommend to build Android 8 release, the mouse works fine there. Also 
> the Settings bug is fixed if you use userdebug build variant instead of eng.
> The guide in the same as in first post except:
> 
> Android 8 will take 211GB to build. I've build it with 32GB RAM without swap, 
> maybe it'll work with less RAM.
> 
> repo init -u git://git.osdn.net/gitroot/android-x86/manifest -b oreo-x86 -m 
> android-x86-8.1-r1.xml
> instead of 
> repo init -u git://git.osdn.net/gitroot/android-x86/manifest -b 
> android-x86-7.1-r2
> 
> https://github.com/opengapps/";  />
> https://gitlab.nezorfla.me/opengapps/";  />
>  remote="opengapps" />
>  revision="master" remote="nezor" />
>  revision="master" remote="nezor" />
>  revision="master" remote="nezor" />
> instead of
> https://github.com/opengapps/";  />
>  remote="opengapps" />
>  revision="master" remote="opengapps" />
>  revision="master" remote="opengapps" />
>  revision="master" remote="opengapps" />
> 
> lunch android_x86_64-userdebug
> instead of
> lunch android_x86_64-eng
> 
> /usr/bin/make -C kernel O=$OUT/obj/kernel ARCH=x86_64 menuconfig
> instead of
> make -C kernel O=$OUT/obj/kernel ARCH=x86_64 menuconfig

I've uploaded the working Android 8.1 iso for those who need it for a test, but 
I don't recommend to use it for security reasons and it's better to build the 
iso yourself:
https://drive.google.com/open?id=1Y4P77mlPPlXBzYrJ5yHJ7XM6gLVsQQm0

md5sum android_x86_64-oreo-nogapps.iso 
b3af7a84820dd9fb32dd40c68f285993  android_x86_64-oreo-nogapps.iso

sha1sum android_x86_64-oreo-nogapps.iso 
16e9bcf0da44929b223fc2ab1df97de0df26d9fb  android_x86_64-oreo-nogapps.iso
sha256sum

sha256sum android_x86_64-oreo-nogapps.iso 
b7d9aa5f9c401202ea24b63e95bb0f38d1f981381a719257c1a2f526e0cf636f  
android_x86_64-oreo-nogapps.iso

sha512sum android_x86_64-oreo-nogapps.iso 
16f2666a20499f31472fc933a670c47070e0db14686b605b69254d054dcc63893b564e5a35e84e1daf7b7fd80f955a2834956a1bb029e93563b7d8c44787666b
  android_x86_64-oreo-nogapps.iso

-- 
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/ed61584c-1a11-48af-baed-8ed77e13082f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Fully Working Android VM for Qubes available? (2019)

[alex . jones . 4416]

On Wednesday, April 24, 2019 at 3:33:54 AM UTC, benz magdalena wrote:
> Android-x86 8.1 got released recently,
> 
> the lagging mouse issues have been fixed but the main problem is the 
>   Android-x86 8.1 iso
> can not be installed cause it fails to detect the qubes virtual disks 
> 
> is there any 'easy' way to fix this error without compiling 
> 160GB of data to change the config...
> 
> any fully working iso available for download for qubes?
> 
> 
> how to solve this issue the easiest?
> 
> 
> thanks

It works fine for me, see "Android-x86 7.1-r2 with GAPPS installation guide" 
topic.

-- 
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/c60b59b2-87cf-4f01-8089-9866e29a8cd8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Android-x86 7.1-r2 with GAPPS installation guide

[alex . jones . 4416]

On Thursday, April 25, 2019 at 10:20:32 PM UTC, Daniil Travnikov wrote:
> I am stuck on this process already twice.
> 
> When I put the command
> 
> Download sources:
> repo sync --no-tags --no-clone-bundle --force-sync -j$( nproc --all )
> 
> 
> and when it show this:
> 
> 
> From git://git.osdn.net/gitroot/android-x86/platform/frameworks/av
>  * [new branch]  nougat-x86 -> x86/nougat-x86
> Fetching project platform/external/android-clat
> remote: Counting objects: 1, done
> remote: Finding sources: 100% (793/793)   
> remote: Total 793 (delta 244), reused 793 (delta 244)
> Receiving objects: 100% (793/793), 517.38 KiB | 0 bytes/s, done.
> Resolving deltas: 100% (244/244), done.
> From https://android.googlesource.com/platform/external/android-clat
>  * [new tag] android-7.1.2_r36 -> android-7.1.2_r36
> 
> 
> I got nothing, I mean it's look like freeze.

Did you try to remove downloaded repo and sync it again from scratch? The 
OpenGAPPS repo changed, see below, maybe it's somehow related.

I'd recommend to build Android 8 release, the mouse works fine there. Also the 
Settings bug is fixed if you use userdebug build variant instead of eng.
The guide in the same as in first post except:

Android 8 will take 211GB to build. I've build it with 32GB RAM without swap, 
maybe it'll work with less RAM.

repo init -u git://git.osdn.net/gitroot/android-x86/manifest -b oreo-x86 -m 
android-x86-8.1-r1.xml
instead of 
repo init -u git://git.osdn.net/gitroot/android-x86/manifest -b 
android-x86-7.1-r2

https://github.com/opengapps/";  />
https://gitlab.nezorfla.me/opengapps/";  />




instead of
https://github.com/opengapps/";  />





lunch android_x86_64-userdebug
instead of
lunch android_x86_64-eng

/usr/bin/make -C kernel O=$OUT/obj/kernel ARCH=x86_64 menuconfig
instead of
make -C kernel O=$OUT/obj/kernel ARCH=x86_64 menuconfig

-- 
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/abcd98d7-6317-483d-ad6f-b58dbe1ef79c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes - the future of gaming!

[Alex A]

Good now i've got your attention,
Lets discuss the now VIABLE future of gaming on Linux (specifically on Qubes)
And YES you non gamer workstation only people SHOULD CARE about this (tell you 
why in a moment)

Quick video  for those no up to date on the state of gaming on Linux:
https://youtu.be/Co6FePZoNgE
TL;DR
Steam is now supported on Linux,
Over 5,000 native linux games
+ Protondb.com is a new tool released by Valve Software that has been 
integrated with Steam Play to make playing Windows games on Linux as simple as 
hitting the Play button. 
++ lutris.net also opens up many more games at the press of a button
 Google Stadia is running on Linux servers & using Vulkan is their graphics 
API
And because of all this.. NVIDIA is working overtime to match AMDs already 
comprehensive open source drivers. 
= Gaming revolution coming to Linux

Some distros already like "Pop OS & Manjaro" are even coming "game ready" with 
steam pre-installed as well as UPDATED DRIVERS.
Even the HTC Vive Virtual reality is reported working well on Linux
https://youtu.be/2Db-zkHC8s0

COULD THIS BE IT?
Could finally my dreams of have a secure OS and still game without having to 
touch windows ever again be coming TRUE?

In the past when i've looked into gaming on Qubes, I (unsuccessfully) tried to 
setup a Qubes Windows VM running PCIe pass through (I wasnt even successful 
getting the Win7 VM setup),
But i would imagine a Linux based VM with PCIe pass through would be easier to 
support?

Now, WHY should all you serious Sams & Susans Care about games?
Because gaming is ultimately what keeps everyone bound to windows. Any platform 
that enables users to dump Microsoft, and still have a holistic experience, is 
going to tremendous growth.
And larger community will accelerate development and secure the future of that 
platform.

Thus, Qubes SHOULD get on this train!!
Having a "game ready" VM will grow the community.
Maybe the "Game VM" may also be able to GPU accelerate rendering. video editing 
etc? Opening the door to even more users.


Ok, now your free to tell me why im wrong and living in fantasy land..?

-- 
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/fbf2591a-ee53-40eb-af83-eeff0b322196%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Android-x86 7.1-r2 with GAPPS installation guide

[alex . jones . 4416]

On Tuesday, February 19, 2019 at 10:38:39 AM UTC, nosugar...@gmail.com wrote:
> Hi Alex,
> 
> Let me just start by saying a massive thank you. This guide has been great. I 
> have used it for the 8.1 - Oreo - which was just changing:
>  'repo init -u git://git.osdn.net/gitroot/android-x86/manifest -b 
> android-x86-7.1-r2' to 'repo init -u 
> git://git.osdn.net/gitroot/android-x86/manifest -b oreo-x86.'
> 
> With 8.1, mouse support comes out the box and completing the last part of the 
> guide actually makes the mouse worse in Oreo. So, disregard that part anyone 
> following this guide for 8.1. You can change resolution by affixing 'vga=ask' 
> and choosing your desired resolution 
> (https://groups.google.com/forum/#!topic/qubes-users/KZm8aGJuiO0).
> 
> I have come across one issue, and I am wondering if you could help me. 
> Android has installed great, and loads up fine. However, I simply cannot open 
> the Settings app, as it crashes every single time. Others who have 
> encountered this issue modified it using adb 
> (https://stackoverflow.com/questions/3480201/how-do-you-install-an-apk-file-in-the-android-emulator?rq=1),
>  but I don't know how to do this with a Qubes HVM. Any help with this?
> 
> Thanks in advance :)

You can use adb via network:
Create tmpvm with adb.
Select Networking vm for tmpvm with adb to sys-android.
Select Networking vm for Android VM to sys-android.

In sys-android run:
sudo nft add rule ip qubes-firewall forward meta iifname eth0 accept
sudo iptables -I FORWARD 2 -i vif+ -s 10.137.0.0/24 -d 10.137.0.0/24 -p tcp -m 
conntrack --ctstate NEW -j ACCEPT

In android terminal run:
su
setprop service.adb.tcp.port 
stop adbd
start adbd

In tmpvm witd adb run:
adb connect 10.137.0.xx:
Where 10.137.0.xx - android IP
And then run your commands.

-- 
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/9cd2dfa9-8dec-4d19-aa46-435763450951%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Making a Qubes USB Installer USB with Fedora LiveCD

[Alex Winter]

No I never got UEFI to work.  I ended up having to revert to legacy install
which worked flawlessly for me using rufus.

On Thu, Jan 24, 2019, 4:13 PM Aly Abdellatif  You can follow what I wrote for my installation !
>
>
> https://groups.google.com/forum/m/#!msg/qubes-users/5-qFYKN0esM/E07fmEHZHAAJ
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "qubes-users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/qubes-users/aYL3fQSNapU/unsubscribe.
> To unsubscribe from this group and all its topics, 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/35e25d4a-608e-4184-8d2d-d66e1e54f3e3%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [qubes-users] How to autostart a program in an appVM?

[Alex]

On 1/15/19 2:46 AM, jrg.desk...@gmail.com wrote:
> I am sure almost everyone has one or more appVMs in which they autostart 
> programs. That is, how do I set things up so that when a particular appVM is 
> automatically launched at boot time (or I manually start it), one or more 
> programs get started automatically? For example, in my "personal" Qube, I 
> want Thunderbird, Slack (the collaboration tool) and Dropbox to start 
> automatically.

I did exactly that, with the fedora template, setting the programs to
auto-start with gnome-tweaks (in previous fedora versions it was named
gnome-tweak-tool). There's a section that conveniently allows you to
manage the .desktop file links to have programs auto-start at boot.

This was the tool I used to fix font appearance (antialiasing mode,
hinting) with older fedora versions that had problems (23-24-25).

-- 
Alex

-- 
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/23e6171e-0f18-1449-d0d0-78ed2c49d8dc%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: USB Keyboard no longer reachable following recent update

[Alex Dubois]

On Saturday, 12 January 2019 12:52:29 UTC, Alex Dubois  wrote:
> Hi,
> 
> Did a qubes-dom0-update + fedora template update last night. Reboot this 
> morning and I can't reach the USB keyboard anymore.
> 
> I can't remember if I had removed my sys-usb VM after I got bitten recently 
> and fixed the situation following this 
> https://github.com/QubesOS/qubes-issues/issues/2270.
> 
> Following the explanation there I could boot and use the USB keyboard from my 
> fedora on USB-key:
> I did not have any entry with  rd.qubes.hide_all_usb in xen-4.x.x.config
> And I did not have a file 
> /etc/systemd/system/multi-user.target.wants/qubes-vm@sys-usb.service.
> 
> Any hint appreciated.
> 
> I am using Qubes as my home firewall and the entire house is disconnected 
> (can't reconnect easily as I have VLans all over the place, dns server on 
> QubesOS, etc...).

Had to edit out from grub.cfg rd.qubes.hide_all_usb entries to be able to enter 
the LUKS password

-- 
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/e0ea7822-6b25-4956-b508-154a1e70b038%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] USB Keyboard no longer reachable following recent update

[Alex Dubois]

Hi,

Did a qubes-dom0-update + fedora template update last night. Reboot this 
morning and I can't reach the USB keyboard anymore.

I can't remember if I had removed my sys-usb VM after I got bitten recently and 
fixed the situation following this 
https://github.com/QubesOS/qubes-issues/issues/2270.

Following the explanation there I could boot and use the USB keyboard from my 
fedora on USB-key:
I did not have any entry with  rd.qubes.hide_all_usb in xen-4.x.x.config
And I did not have a file 
/etc/systemd/system/multi-user.target.wants/qubes-vm@sys-usb.service.

Any hint appreciated.

I am using Qubes as my home firewall and the entire house is disconnected 
(can't reconnect easily as I have VLans all over the place, dns server on 
QubesOS, etc...).

-- 
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/aa317785-af08-4a3c-ac52-fdf3f11cd066%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] unproven APT for Qubes 3.x

[Alex]

On 12/9/18 8:38 AM, Oleg Artemiev wrote:
> A friend of mine told me a story:
> 
> She had unproven APT like when insecure hardware being in use.
> 
> Sorry, my English is not well enough (proven upper intermediate).
> I will continue in Russian:
> --- quote -
> - Прикинь - словил апт в третьих кубиках
> - держи меня в курсе
> - ну ты же знаешь, что это было на unsupported hardware без usb filter
> --- quote -
> 
> BCC: 0x90h
> 
> может пора понять, что использование третих кубиков стало опасно после
> того как была опубликована работа по автоматизации их из ансибла (не
> упомянутая в Qubes 3 FAQ? Всегда найдуться любители отстрелить себе
> гениталии..
From what I can gather from your story, it seems that you claim that
Qubes R3.x is to be considered insecure, as far as USB hardware is
concerned...

I'm not sure about this, but the warning to update is implicit in the
fact that R4 is out and the last version is typically the best supported
one.

-- 
Alex

-- 
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/a0c2db52-25ea-3881-ea9e-b41b87eb6d24%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Android-x86 7.1-r2 with GAPPS installation guide

[alex . barinov]

On Saturday, December 1, 2018 at 7:05:08 PM UTC, alex.jo...@gmail.com wrote:
> At which point did you get this error?
> Did you create android VM according to guide?
> >Create android VM in dom0:
> >qvm-create --class StandaloneVM --label green --property virt_mode=hvm 
> >android
> >qvm-prefs android kernel ''
> >qvm-prefs android 'sys-android'
> >qvm-prefs android memory '2048'
> >qvm-prefs android maxmem '2048'
> >qvm-volume extend android:root 20g
> What's your Qubes version? It works on my Qubes 4.0.
> I think it should be related to kernel option:
> >qvm-prefs android kernel ''
> https://github.com/QubesOS/qubes-issues/issues/3419

You are right, the issue was due to missing `qvm-prefs android kernel ''`.


Everything works fine now, if we can call fine inability to change screen 
resolution, absence of sound and file exchange and semi-defunct mouse.

-- 
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/186dc847-f77b-455c-b22e-7905a54ccaae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Android-x86 7.1-r2 with GAPPS installation guide

[alex . jones . 4416]

At which point did you get this error?
Did you create android VM according to guide?
>Create android VM in dom0:
>qvm-create --class StandaloneVM --label green --property virt_mode=hvm android
>qvm-prefs android kernel ''
>qvm-prefs android 'sys-android'
>qvm-prefs android memory '2048'
>qvm-prefs android maxmem '2048'
>qvm-volume extend android:root 20g
What's your Qubes version? It works on my Qubes 4.0.
I think it should be related to kernel option:
>qvm-prefs android kernel ''
https://github.com/QubesOS/qubes-issues/issues/3419

-- 
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/53fa3ace-9bdb-45f0-bde7-10cacadc5763%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Android-x86 7.1-r2 with GAPPS installation guide

[alex . barinov]

On Saturday, December 1, 2018 at 4:32:59 PM UTC, alex.jo...@gmail.com wrote:
> On Saturday, December 1, 2018 at 5:47:52 AM UTC, alex.b...@gmail.com wrote:
> > Great guide! The whole process looks way more straightforward than I 
> > thought it is!
> > 
> > Do you mind sharing the resulting images for testing? I'll have hard time 
> > compiling this myself on old Core m3/8Gb machine...
> 
> You can try this image, but I advise to build your own image for security 
> reasons:
> https://drive.google.com/open?id=1KGDRe9iJgjb3nSBjFlK74Sa_nn08qYiq

Thank Alex! Does not boot for me, vm halts after "Probing EDD" :(

That was the whole point of trying pre-built image (despite security 
implications) - your iso saved me quite a few hours of compiling.

-- 
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/dfc9ecc6-a3cf-4331-8c64-89bb1a66abaa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Android-x86 7.1-r2 with GAPPS installation guide

[alex . jones . 4416]

On Saturday, December 1, 2018 at 5:47:52 AM UTC, alex.b...@gmail.com wrote:
> Great guide! The whole process looks way more straightforward than I thought 
> it is!
> 
> Do you mind sharing the resulting images for testing? I'll have hard time 
> compiling this myself on old Core m3/8Gb machine...

You can try this image, but I advise to build your own image for security 
reasons:
https://drive.google.com/open?id=1KGDRe9iJgjb3nSBjFlK74Sa_nn08qYiq

-- 
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/aeb24f73-fba3-41bf-ba63-4f087885985c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Android-x86 7.1-r2 with GAPPS installation guide

[alex . barinov]

Great guide! The whole process looks way more straightforward than I thought it 
is!

Do you mind sharing the resulting images for testing? I'll have hard time 
compiling this myself on old Core m3/8Gb machine...

-- 
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/3ecfa794-26d0-487f-bb9e-f7b36c544a1f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Android-x86 7.1-r2 with GAPPS installation guide

[alex . jones . 4416]

I've successfully build android-x86 7.1-r2 with gapps in whonix-14-ws AppVM.

1. Install packages in whonix-14-ws template:

sudo apt-get install openjdk-8-jdk git-core gnupg flex bison gperf 
build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 
lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev libgl1-mesa-dev 
libxml2-utils xsltproc unzip gettext python-pip libyaml-dev dosfstools syslinux 
syslinux-utils xorriso mtools makebootfat lunzip

2. Create builder AppVM based on whonix-14-ws in which you'll build android-x86:
You'll need 120GB for android-x86 sources and temp build files and 30GB for 
swap.
Extend private storage size to 160GB via GUI or in dom0:
qvm-volume extend android-builder:private 160g

Add 30GB swap in builder VM:

sudo dd if=/dev/zero of=/rw/swapfile bs=1024 count=31457280
sudo chown root:root /rw/swapfile
sudo chmod 0600 /rw/swapfile
sudo mkswap /rw/swapfile
sudo swapon /rw/swapfile

In builder VM run:

sudo ln -s /sbin/mkdosfs /usr/local/bin/mkdosfs
sudo pip install prettytable Mako pyaml dateutils --upgrade
export _JAVA_OPTIONS="-Xmx8G"
echo 'export _JAVA_OPTIONS="-Xmx8G"' >> ~/.profile
echo "sudo swapon /rw/swapfile" >> /rw/config/rc.local

Download android-x86 sources:

mkdir android-x86
cd android-x86
curl https://storage.googleapis.com/git-repo-downloads/repo > repo
chmod a+x repo
sudo install repo /usr/local/bin
rm repo
git config --global user.name "Your Name"
git config --global user.email "y...@example.com"
repo init -u git://git.osdn.net/gitroot/android-x86/manifest -b 
android-x86-7.1-r2

To add GAPPS to your build you need to add the build system, and the wanted 
sources to your manifest.
Edit .repo/manifests/default.xml and add the following towards the end:

https://github.com/opengapps/";  />





Download sources:
repo sync --no-tags --no-clone-bundle --force-sync -j$( nproc --all )

If you choose to add GAPPS, then edit file device/generic/common/device.mk and 
add at the beginning:

#OpenGAPPS

GAPPS_VARIANT := pico

GAPPS_PRODUCT_PACKAGES += Chrome \
KeyboardGoogle \
LatinImeGoogle \
GoogleTTS \
YouTube \
PixelIcons \
PixelLauncher \
Wallpapers \
PixelLauncherIcons \
WebViewGoogle \
GoogleServicesFramework \
GoogleLoginService \

GAPPS_FORCE_BROWSER_OVERRIDES := true
GAPPS_FORCE_PACKAGE_OVERRIDES := true

GAPPS_EXCLUDED_PACKAGES := FaceLock \
AndroidPlatformServices \
PrebuiltGmsCoreInstantApps \

And at the end add:

#OpenGAPPS
$(call inherit-product, vendor/opengapps/build/opengapps-packages.mk)

Edit android-x86 sources for XEN compatibility:
sed -i -e 's|/sys/block/\[shv\]d\[a-z\]|/sys/block/\[shv\]d\[a-z\] 
/sys/block/xvd\[a-z\]|g' bootable/newinstaller/install/scripts/1-install
sed -i -e 's|/sys/block/\[shv\]d\$h/\$1|/sys/block/\[shv\]d\$h/\$1 
/sys/block/xvd\$h/\$1|g' bootable/newinstaller/install/scripts/1-install
sed -i -e 's|hmnsv|hmnsvx|g' bootable/newinstaller/initrd/init

Edit android-x86 sources for Debian build environment:
sed -i -e 's|genisoimage|xorriso -as mkisofs|g' bootable/newinstaller/Android.mk

Configure build target:
. build/envsetup.sh
lunch android_x86_64-eng

Configure kernel:
make -C kernel O=$OUT/obj/kernel ARCH=x86 menuconfig
You need to edit these parameters:
XEN=yes
XEN_BLKDEV_BACKEND=yes
XEN_BLKDEV_FRONTEND=yes
XEN_NETDEV_BACKEND=no
XEN_NETDEV_FRONTEND=no
SECURITY_SELINUX_BOOTPARAM=yes
SECURITY_SELINUX_BOOTPARAM_VALUE=1
SECURITY_SELINUX_DISABLE=yes
DEFAULT_SECURITY_SELINUX=yes

The kernel config will be in out/target/product/x86_64/obj/kernel/.config

Also, you can edit the config to set the device type from tablet to phone.
Edit device/generic/common/device.mk and change PRODUCT_CHARACTERISTICS from 
tablet to default:
PRODUCT_CHARACTERISTICS := default

Start the build:
m -j$( nproc --all ) iso_img

After you got the iso, create the android network VM. If you choose the android 
VM's netvm as sys-whonix directly, the network won't work. You need to have 
intermediate netvm between android VM and sys-whonix. Create new AppVM 
sys-android based on fedora template with netvm sys-whonix and set "provides 
network".

Create android VM in dom0:
qvm-create --class StandaloneVM --label green --property virt_mode=hvm android
qvm-prefs android kernel ''
qvm-prefs android 'sys-android'
qvm-prefs android memory '2048'
qvm-prefs android maxmem '2048'
qvm-volume extend android:root 20g

Start the android VM with iso:
qvm-start android 
--cdrom=android-builder:/home/user/android-x86/out/target/product/x86_64/android_x86_64.iso

Install android-x86 on xvda and reboot.

Start android VM without iso:
qvm-start android
When it'll start, kill the VM and wait for it to halt.
Configure android VM to use the mouse in dom0:
sudo mkdir -p /etc/qubes/templates/libvirt/xen/by-name/
sudo cp /etc/libvirt/libxl/android.xml 
/etc/qubes/templates/libvirt/xen/by-name/android.xml
sudo sed -i -e 's/tablet/mouse/g' 
/etc/qubes/templates/libvirt/xen/by-name/android.xml

Start android

[qubes-users] Re: Android-x86 on Qubes 4

[alex . jones . 4416]

On Wednesday, August 8, 2018 at 1:37:53 PM UTC, rex mat wrote:
> After the manual install, I can boot, but ethernet can only be configured 
> from the terminal. That is still work in progress.
> You need to have an android-x86 build and check out the 7.1.2 version to 
> build a cd. I found the instruction on the web on the android-x86.org web 
> page. I recommend using the ubuntu 16.4 version mentioned as the preferred 
> build machine in a hope you avoid the pain I went through to do a build on 
> qubes. 
> 
> 
> 
> I did the following 2 changes:
> 
> 
> 
> 1. Changed 1 line in "init" inside initrd
> from:
> 
>     for device in ${ROOT:-/dev/[hmnsv][dmrv][0-9a-z]*}; do
> to:
> 
>     for device in ${ROOT:-/dev/[hmnsvx][dmrv][0-9a-z]*}; do
> That allows the XEN hard drive to be used at initialization
> 
> 
> 
> 2. I configured the kernel
> Below is the config (I hope, as I played afterwards to get a proper mouse, 
> with no avail). This config disabled a lot of things that need blobs and the 
> like to get it built:
> 
> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86_64 4.9.109 Kernel Configuration
> #
> CONFIG_64BIT=y
> CONFIG_X86_64=y
> CONFIG_X86=y
> CONFIG_INSTRUCTION_DECODER=y
> CONFIG_OUTPUT_FORMAT="elf64-x86-64"
> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_MMU=y
> CONFIG_ARCH_MMAP_RND_BITS_MIN=28
> CONFIG_ARCH_MMAP_RND_BITS_MAX=32
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
> CONFIG_NEED_DMA_MAP_STATE=y
> CONFIG_NEED_SG_DMA_LENGTH=y
> CONFIG_GENERIC_ISA_DMA=y
> CONFIG_GENERIC_BUG=y
> CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
> CONFIG_GENERIC_HWEIGHT=y
> CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> CONFIG_GENERIC_CALIBRATE_DELAY=y
> CONFIG_ARCH_HAS_CPU_RELAX=y
> CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
> CONFIG_HAVE_SETUP_PER_CPU_AREA=y
> CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
> CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
> CONFIG_ARCH_HIBERNATION_POSSIBLE=y
> CONFIG_ARCH_SUSPEND_POSSIBLE=y
> CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
> CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
> CONFIG_ZONE_DMA32=y
> CONFIG_AUDIT_ARCH=y
> CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
> CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> CONFIG_X86_64_SMP=y
> CONFIG_ARCH_SUPPORTS_UPROBES=y
> CONFIG_FIX_EARLYCON_MEM=y
> CONFIG_DEBUG_RODATA=y
> CONFIG_PGTABLE_LEVELS=4
> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
> CONFIG_IRQ_WORK=y
> CONFIG_BUILDTIME_EXTABLE_SORT=y
> CONFIG_THREAD_INFO_IN_TASK=y
> 
> #
> # General setup
> #
> CONFIG_INIT_ENV_ARG_LIMIT=32
> CONFIG_CROSS_COMPILE=""
> # CONFIG_COMPILE_TEST is not set
> CONFIG_LOCALVERSION="-android-x86_64"
> CONFIG_LOCALVERSION_AUTO=y
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_HAVE_KERNEL_LZMA=y
> CONFIG_HAVE_KERNEL_XZ=y
> CONFIG_HAVE_KERNEL_LZO=y
> CONFIG_HAVE_KERNEL_LZ4=y
> CONFIG_KERNEL_GZIP=y
> # CONFIG_KERNEL_BZIP2 is not set
> # CONFIG_KERNEL_LZMA is not set
> # CONFIG_KERNEL_XZ is not set
> # CONFIG_KERNEL_LZO is not set
> # CONFIG_KERNEL_LZ4 is not set
> CONFIG_DEFAULT_HOSTNAME="android_x86_64"
> CONFIG_SWAP=y
> # CONFIG_SYSVIPC is not set
> # CONFIG_POSIX_MQUEUE is not set
> CONFIG_CROSS_MEMORY_ATTACH=y
> # CONFIG_FHANDLE is not set
> # CONFIG_USELIB is not set
> CONFIG_AUDIT=y
> CONFIG_HAVE_ARCH_AUDITSYSCALL=y
> CONFIG_AUDITSYSCALL=y
> CONFIG_AUDIT_WATCH=y
> CONFIG_AUDIT_TREE=y
> 
> #
> # IRQ subsystem
> #
> CONFIG_GENERIC_IRQ_PROBE=y
> CONFIG_GENERIC_IRQ_SHOW=y
> CONFIG_GENERIC_PENDING_IRQ=y
> CONFIG_GENERIC_IRQ_CHIP=y
> CONFIG_IRQ_DOMAIN=y
> CONFIG_IRQ_DOMAIN_HIERARCHY=y
> CONFIG_GENERIC_MSI_IRQ=y
> CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
> # CONFIG_IRQ_DOMAIN_DEBUG is not set
> CONFIG_IRQ_FORCED_THREADING=y
> CONFIG_SPARSE_IRQ=y
> CONFIG_CLOCKSOURCE_WATCHDOG=y
> CONFIG_ARCH_CLOCKSOURCE_DATA=y
> CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
> CONFIG_GENERIC_TIME_VSYSCALL=y
> CONFIG_GENERIC_CLOCKEVENTS=y
> CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
> CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
> CONFIG_GENERIC_CMOS_UPDATE=y
> 
> #
> # Timers subsystem
> #
> CONFIG_TICK_ONESHOT=y
> CONFIG_NO_HZ_COMMON=y
> # CONFIG_HZ_PERIODIC is not set
> CONFIG_NO_HZ_IDLE=y
> # CONFIG_NO_HZ_FULL is not set
> CONFIG_NO_HZ=y
> CONFIG_HIGH_RES_TIMERS=y
> 
> #
> # CPU/Task time and stats accounting
> #
> CONFIG_TICK_CPU_ACCOUNTING=y
> # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
> # CONFIG_IRQ_TIME_ACCOUNTING is not set
> # CONFIG_SCHED_WALT is not set
> CONFIG_BSD_PROCESS_ACCT=y
> # CONFIG_BSD_PROCESS_ACCT_V3 is not set
> CONFIG_TASKSTATS=y
> CONFIG_TASK_DELAY_ACCT=y
> CONFIG_TASK_XACCT=y
> CONFIG_TASK_IO_ACCOUNTING=y
> 
> #
> # RCU Subsystem
> #
> CONFIG_PREEMPT_RCU=y
> # CONFIG_RCU_EXPERT is not set
> CONFIG_SRCU=y
> # CONFIG_TASKS_RCU is not set
> CONFIG_RCU_STALL_COMMON=y
> # CONFIG_TREE_RCU_TRACE is not set
> # CONFIG_RCU_EXPEDITE_BOOT is not set
> CONFIG_BUILD_BIN2C=y
> CONFIG_IKCONFIG=y
> CONFIG_IKCONFIG_PROC=y
> CONFIG_LOG_BUF_SHIFT=17
> CONFIG

Re: [qubes-users] R4.0.1 RC1 - qubes-dom0-update not working

[Alex]

On 11/15/18 5:30 PM, Dominique St-Pierre Boucher wrote:
> Hello Qubes Users,
> 
> Just installed RC1 on 2 laptops. This is working fine for install and 
> template. Working fine for template update.
> 
> My issue is that qubes-dom0-update does not work for qubes repo. This is the 
> message I am getting:
> 
> Failed to synchronize cache for repo 'qubes-dom0-current', inoring this repo.
> 
> With my check on what is appening in qubes-dom0-update and what is appening 
> with yum, I think that the variable for the release is not set correctly and 
> it prevents yum from connecting to the repo.
> 
Yes, has been handled in bug 4477
https://github.com/QubesOS/qubes-issues/issues/4477 that seems to have
been resolved a couple of days ago.

To perform the first upgrade that fixes the problem, though, I think
that you can use --releasever=4.0 as a parameter to qubes-dom0-upgrade.

Did not try it myself because I solved it by manually correcting the URL
in /etc/yum.repos.d/*.repo

-- 
Alex

-- 
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/0ba3269b-d015-5f7b-0cf7-44c0f46c4f8d%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] [solved] Re: Failed to synchronize cache for repo 'qubes-dom0-cached', disabling.

[Alex]

On 11/12/18 12:11 PM, unman wrote:
> On Sat, Nov 10, 2018 at 12:54:46PM +0100, Alex wrote:
>>[...]
>> Changed that with nano to read "4.0" instead of "$releasever" and voilà,
>> updates went through.
>>
> 
> Please bear in mind that if you do this you are breaking the logic of
> dnf, and will have to *manually* update that entry if you upgrade the
> system. You are almost bound to forget this.
> $releasever is part of yum/dnf, not Qubes.
I am well aware of this, both the fact that I'm gonna forget about it
and that $releasever is part of the yum workflow. Actually, since I hate
"fedup", it's the way I update my other computers to a newer fedora
version: dnf upgrade --releasever=29.

> You can pass in --releasever=4.0 as an option, which would be a better
> solution.
That's true; but as the time of writing my original response, I could
not figure out how $releasever was being catenated with both "25" and
"4", so I imagined something "fixed" was automatically appended and
decided not to brute-force the --releasever param.

I use Qubes as my main workstation, so I don't have much time to
extensively try and fix things... Still, I love it so much I thought I'd
jump into the thread and post my workaround.

> I havent encountered this bug myself,so cant account for it. It might be
> helpful if those who have could say if they have enabled testing repos,
> or are using plain 4.0 Qubes repositories. Any other detail would be
> helpful.
A very plain installation of R4.0, some couple of months after the
official release (I had to upgrade the CPU to install R4.0 from R3.2, so
I had to wait for it to arrive from an ebay seller in the UK).

Looking at the bug linked by Andrew (github issue 4477), seems like
Marek already found the cause.

I'll monitor the issue and, as soon as this is resolved (which may
involve a temporal link from yum.qubes-os.org/r25-4/ to
yum.qubes-os.org/r4.0?), will revert the repo files in /etc/yum.repos.d
to the original ones.

Thank you everybody,
-- 
Alex

-- 
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/d34197bb-8285-9faf-47a5-938574b46e51%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] [solved] Re: Failed to synchronize cache for repo 'qubes-dom0-cached', disabling.

[Alex]

On 11/10/18 11:23 AM, hm...@tuta.io wrote:
> hello
> 
> I have exactly the same problem on two of my x230 Lenovo notebooks with Qubes 
> version R4.0.1rc1.
Have had this very issue on R4.0.

I checked by running, in dom0:
# qubes-dom0-update -v

That runs the dnf updater with the "-v" verbose flag. With that, the URL
for the repositories will be printed on screen, in red (because it's
happening in the UpdateVM).

I found that the URL being printed was
https://yum.qubes-os.org/r25-4/current/dom0/fc25/repodata/repomd.xml.metalink

instead of the correct
https://yum.qubes-os.org/r4.0/current/dom0/fc25/repodata/repomd.xml.metalink

(the yum.qubes-os.org domain can be navigated with a browser).

I found that inside [dom0]/etc/yum.repos.d/qubes-dom0.repo the url is
saved as
https://yum.qubes-os.org/r$releasever/current/dom0/fc25/repodata/repomd.xml.metalink

Changed that with nano to read "4.0" instead of "$releasever" and voilà,
updates went through.

Check, try and let the list know ;)

-- 
Alex

-- 
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/90d6b896-f532-519a-cffd-bcdafe509eb8%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Errors Installing a .deb File in Qubes 4.0

[Alex Winter]

I have figured it out.  I wasn't extracting the directory properly and was 
giving me the incorrect file. 

 I have installed the application now but when I open it up, it doesn't 
recognise the onlykey device in the application.  It also doesn't show up in my 
devices on the top right of the screen in dom0 when I plug it in so I cant 
attach it to any AppVM.  However, the device still outputs the correct 
passwords when pressing the corrosponding button on the onlykey which I find 
odd.  

I have qubes 4.0 setup on a laptop.  It is installed on a USB drive aswell 
which probably is causing most of my issues.  

 

-- 
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/e07024d4-8a63-4a5d-ab7b-c6aaed57f043%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Errors Installing a .deb File in Qubes 4.0

[Alex Winter]

I am having some Issues installing a .deb file.  The File I am trying to 
install is OnlyKey_5.0.0.deb. 

Step One: Downloaded it off of onlykey website User guide.  It can be 
downloaded here 
https://s3.amazonaws.com/onlykey/apps/desktop/releases/latest/OnlyKey_5.0.0.deb.gz

Step Two:  I downloaded it as OnlyKey_5.0.0.deb.gz so I extracted it into my 
download folder so it is now OnlyKey_5.0.0.deb.

Step Three:  Moved the Files from my Personal AppVM to Debian-9 Downloads 
folder and opened a terminal in that directory getting ready to install.

Step four: in the Debian-9 terminal, I type "sudo dpkg -i OnlyKey_5.0.0.deb" 
and I get this error message : dpkg: error: archive 'OnlyKey_5.0.0.deb' is not 
a regular file

I have also tryed typing in "sudo apt-get install ./OnlyKey_5.0.0.deb" and this 
is the error I am getting:  

Reading package lists... Error!
E: Sub-process Popen returned an error code (2)
E: Encountered a section with no Package: header
E: Problem with MergeList /home/user/Downloads/OnlyKey_5.0.0.deb
E: The package lists or status file could not be parsed or opened.

Is there any Ideas on how to fix this?

-- 
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/1eaf653d-9253-49d3-942e-ddd19958f07b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] No icons in debian-9 File manager

[Alex Winter]

Hey, I recently installed thunar with debian-9 and When I open it up there are 
no icons showing at all.  Is there a way to fix this?

I installed thunar because there wasnt any default file manager with debian-9 
installed.  I installed it using apt-get install thunar in the debian-9 
template.

-- 
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/15fcbc74-13d4-4311-aa04-2d649af99fd8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] HCL - GPD Win 2 - Qubes 4

[Alex Barinov]

  
  
GPD Win 2 - the
smallest computer to run Qubes 4.
Core m3 7Y-30, RAM 8 Gb, SSD 512 Gb.

Everything runs as well as m3 7Y-30/8 Gb can make it. The only
issue is non-working sleep (or rather non-working wake from
sleep) - hope this will get fixed with kernel updates.
  




-- 
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/831e95ce-44f5-4e83-e7d0-228d643bab21%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-Default_string-Default_string-20181021-084547.cpio.gz
Description: application/gzip

Re: [qubes-users] Qubes Warrant Canary Overdue

[Alex]

On 10/15/18 5:26 PM, giantessgnos...@gmail.com wrote:
> This might seem like a serious thing to say, but Canary 16 has expired, and 
> I'm getting worried, as I do rely on Qubes.
> 
> What's going on? Is there a comprimise or not?
> 
In some jurisdictions (e.g. USA) The Qubes Project / Invisible Things
Lab may not be allowed to freely answer your second question.

I don't know where they are based off, but may be in some jurisdiction
that may force them to answer with "there is no compromise" in any case.

Anyway this is not the first canary date that TQP/ITL misses. IMHO /
IANAL but either they are very sloppy with setting a calendar alarm on
their smartphones, or "they are not trying not to send" a message... Or
I'm just reading too much into it.

-- 
Alex

-- 
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/13b11319-7489-d869-33eb-4a31d3b0e5aa%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] Changing USB Controllers

[Alex Winter]

The laptop I have is a MSI WT70 20K.  I have 5 USB ports total on it. Three
USB3 ports and two USB2 ports.

 I have tryed making a sys-usb from the default settings and it crashes the
install(probably because qubes is installed on a usb and its grabbing all
the USB controllers).   Installing without sys-usb works without any issues.

following these instructions
https://www.qubes-os.org/doc/assigning-devices/#finding-the-right-usb-controller
i am seeing that all the ports I plug a USB storage device in use the same
controller as my qubes OS (dom0) which is the XHCI controller.


On Wed, Oct 10, 2018, 10:18 AM unman  wrote:

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

Re: [qubes-users] Changing USB Controllers

[Alex Winter]

Here are the usb controllers when I type in 'sudo lspci -v' 

00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family 
USb xHCI (Rev 05) (prog-if 30 [XHCI])
 Subsystem: Micro-Star International Co., Ltd. [MSI] Device 10ec
 Flags: bus master, medium devsel, latency 0, IRQ 57
 Memory at f7b0 (64-bit, non-prefetchable) [size=64k]
 Capabilities: [70] Power Management version 2
 Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
 Kernel driver in use: xhci_hcd
 Kernel modules: xhci_pci

00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family 
USb EHCI #2 (Rev 05) (prog-if 20 [EHCI])
 Subsystem: Micro-Star International Co., Ltd. [MSI] Device 10ec
 Flags: bus master, medium devsel, latency 0, IRQ 16
 Memory at f7b18000 (32-bit, non-pcopy and pasterefetchable) [size=1k]
 Capabilities: [50] Power Management version 2
 Capabilities: [58] Debug port: BAR=1 offset=00a0
 Capabilities: [98] PCI Advanced Features
 Kernel driver in use: ehci-pci
 Kernel modules: ehci_pci

00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family 
USb EHCI #1 (Rev 05) (prog-if 20 [EHCIReciever])
 Subsystem: Micro-Star International Co., Ltd. [MSI] Device 10ec
 Flags: bus master, medium devsel, latency 0, IRQ 23
 Memory at f7b17000 (32-bit, non-prefetchable) [size=1k]
 Capabilities: [50] Power Management version 2
 Capabilities: [58] Debug port: BAR=1 offset=00a0
 Capabilities: [98] PCI Advanced Features
 Kernel driver in use: ehci-pci
 Kernel modules: ehci_pci

when I type in 'sudo lsusb -v' Here are the buses.  

Bus 002 Device 002: ID 8087:8000 Intel Corp.

Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
iProduct 2 EHCI Host Controller
iSerial  1 :00:1d.0

Bus 001 Device 002: ID 8087:8008 Intel Corp.

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
iproduct 2 EHCI Host Controller
iSerial  1 :00:1a.0

Bus 004 Device 002: ID 04e8:61f5 Samsung Electronics Co., Ltd

Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
iProduct 2 xHCI Host Controller
iSerial  1 :00:14.0

Bus 003 Device 007: ID 1770:ff00

Bus 003 Device 005: ID 8087:07dc Intel Corp.

Bus 003 Device 004: ID 045e:00e1 Microsoft Corp. Wireless Laser Mouse 6000 
receiver

Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
iProduct 2 xHCI Host Controller
iSerial  1 :00:14.0



-- 
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/cc49162d-7fc8-4064-8b25-edece724e1e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Ubuntu server mininal 16.04 quick install guide for Qubes r4

[Alex Dubois]

Hi,

This guide is to install an Ubuntu VM, not a template.

I had few little issues with the install so here is how I did it, this may save 
some time to others in the future.

1 - create HVM image (documented here https://www.qubes-os.org/doc/hvm/)

Note that I configured 800MB for the memory. You may be able to find smaller 
value but 400MB was causing some kernel module to fail to load (probably as 
memory balancing doesn't work)

qvm-create my-new-vm --class StandaloneVM --property virt_mode=hvm --property 
kernel='' --label=green --property memory=800

2 - boot the VM (same doc page)

qvm-start hyperledger --cdrom=disp1234:/home/user/Download/ubuntu-server.iso

3 - Install Ubuntu

F4 to use the minimal mode

when you reach networking config, the firewall is not very chatty obviously so 
it probably does not answer a ping, or whatever test ubuntu installer is doing. 
Selected manual to set-up IP/mask (getting info via qubes-manager).

I had to leave the default gateway blank for the install to be able to continue.
This can be fixed latter after reboot by editing /etc/network/interfaces and 
adding below broacast: gateway 10.137.x.x

DNS can be set:10.139.1.1 10.139.1.2

you don't need to set a domain name (unless you know you do for your specific 
set-up)

Disk partition, I selected guided LVM on the first disk (OS).
Second disk is for private image (leveraged when you use template).

You can leave the http proxy blank (again unless you know you have have, and I 
hope you did not put it in the firewallVM as this is a bad practice by the way).

I selected auto install of security updates

Enjoy Qubes-OS.

Alex




-- 
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/6bc33e40-6691-4bc5-9b11-0e068459a03b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: R4.0 with fedora 28 template sys-net fails to sync time

[Alex]

On 9/16/18 1:29 AM, Marcus Linsner wrote:
> On Saturday, September 15, 2018 at 9:45:34 PM UTC+2, Alex wrote:
>> Hi all,
>> I happen to have run into the problem as per the subject. What happened
>> is this:
>> [..]
>> * The system fails to sync the time to NTP servers
>>
> 
> Please see this[1] for a fix.
> 
> [1] https://github.com/QubesOS/qubes-issues/issues/3983
> 
Thank you; I really should have googled harder... My bad!

-- 
Alex

-- 
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/b30b58f1-fdd4-acb2-6979-8381a2640660%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

[qubes-users] R4.0 with fedora 28 template sys-net fails to sync time

[Alex]

Hi all,
I happen to have run into the problem as per the subject. What happened
is this:

* I recently installed a fully clean R4.0 system, with default templates
and sys-* qubes (this means fedora 26)
* I upgraded the default template, after cloning it, to fedora 28
* This means that now I have a fedora-28 based sys-net
* The system fails to sync the time to NTP servers

What I debugged until now:
* in sys-net, the service systemd-timesyncd should start and update the
time - it's enabled by default
* it does not, because it fails to start due to some inaccessible
directory that is not detailed in the logs
* googling around I found that it looks like one of the usual
surprise-ridden features of systemd, namely DynamicUser, that seems to
have problems with FUSE mounts and the custom-namespace-based isolation
(https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdTimesyncdFailure?showcomments).
I'm thinking this issue is manifesting itself with some of the Qubes
infrastructure.

Does anybody have a recommended way of fixing this, that avoids just
waiting for the systemd guys to fix this? I don't like the idea of
editing systemd's "packaged" unit files, nor am I willing to go set
weird permission / mount options for qubes' directory mounts. What I'd
like to have is a way of having dom0's time set from a network (NTP)
source without necessarily having to successfully set the time in my
sys-net.

What I'm thinking of doing is having a separate clock vm, with a more
standard ntpd, but I'm not sure of the network "position" inside qubes -
will it be enough to give it "sys-net" as the network vm?

Thanks in advance for any guidance...

-- 
Alex

-- 
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/04fdedfe-9502-e89b-2827-e09f00d73901%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] wifi password storage

[Alex]

On 9/12/18 6:53 PM, Daniel Allcock wrote:
> Dear All,
> 
> Have been settling into my new qubes laptop and found that sys-net keeps my
> wifi password in plaintext in a file in a single directory
> (/rw/config/NM-system-connections) that survives reboot.  Presumably as I
> add wifi networks such files will accumulate.  This surprised me, since 
> sys-net by design is untrusted and isolation is the whole point of qubes.  
> If I understand right, when RandomMotelWifi corrupts my sys-net, 
> the corruptors can then get onto almost any other wifi I've ever logged into.
Your reasoning is right, but defending contents of sys-net is *not* in
the main scope of the Qubes project. It's even "written on the tin", as
in "the default color for sys-net is red" and in all the documentation
it is described as a sacrificial Qube, to protect -by isolation- the
other Qubes.

Still, the issue that you raise is true and sensible: an isolated WiFi
password management could be a nice addition of functionality for Qubes.

Moving the debate to an upper level, it could be argued that if you are
so paranoid about security you should not connect to insecure WiFi
networks altogether... But that would not be answering to your question ;)

> Is the idea that I should run different sys-net's to separate wifi's from each
> other, according to some scheme that I need to keep track of?  Maybe, home
> on one, work on another and everything else on a third?  
It can be done; please be aware that this would mean disconnecting and
reconnecting the PCI device once you want to start a connection to
another network, and this could easily become hard to manage.
Furthermore, network connections are usually "architecturally
orthogonal" to your Qubes (home, work, banking, etc.), in that you
typically connect to the internet from all qubes at the same time, on
any network that is available at the moment. You only typically isolate
TOR traffic from the non-torified one.

I'll throw in another option: what about using the PCI WiFi adapter only
for "safe" networks, and using a separate external USB one (with a
separate sys-net-unsecure Qube) for any unsecure connection, that you
periodically purge of any WiFi settings? This way you could usb-proxy
the adapter to the unsecure sys-net - I don't even know if it can be
done, I only use Qubes on desktop workstations, but it may be easier to
manage with existing tools than invent a full-blown NetworkManager
secrets management system...

> Thank you for any thoughts and recommendations,
> Daniel
Thank you for your contribution; bye

-- 
Alex

-- 
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/91e378b1-5b58-ff5c-9a6e-692d0f965dfb%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] suspend to ram, r8169, networking in sys-net not working after resume

[Alex]

On 9/10/18 10:34 PM, gdru...@gmail.com wrote:
>>>>>> My issue:
>>>>>>
>>>>>> On qubes version r4.0 after resuming from suspend networking isn't
>>>>>> working. On qubes r3.2 this wasn't an issue.
>>>>>>
>>>>>>[...]
> 
> Hi,
> 
> In 4.0, I have the same issue.
> [...]
> 
> Help !! how can I fix it ?
>
This also happens to me; I'm using realtek ethernet adapter too. With
R3.2 this happened rarely, but with R4.0 this happens nearly every time
the computer resumes from sleep.

As of now, I just issue a direct "shutdown now" to the sys-net, and then
just restart the VM. As soon as network is available again, all the
other Qubes reach it too - in R3.2 I had to shut them ALL down and then
bring them up in sequence, with R4.0 I can just powercycle sys-net and
it somehow works.

Still, it's a bit of a problem...

-- 
Alex

-- 
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/3e271448-d0ee-800c-b123-eab5591b3db6%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

[qubes-users] Qubes R4.0 feedback (network problems, display problems)

[Alex]

Hello everybody,
I finally managed to upgrade my i5 4690 to an i7 4770 (found on ebay),
and since it supports VT-d I have now been able to upgrade to R4!!!

Just to remember: I have a desktop setup, with an ASUS Z97a motherboard,
32GB Ram, 3 hard disks (2 of which are software-raid via Intel stuff)
and a Matrox C680 connected to six DELL displayport monitors.

I use i3wm with a custom status bar to show cpu/gpu temperature (with
some bash text-manipulation magic on the output of the "sensors" command).

My main problems with R3.2 were:
 * displays randomly would not come up after resuming from sleep
 * network sometimes does not restart after resuming from sleep
 * outdated software in dom0 (say, dmenu...)

After the upgrade, where I took the opportunity to refresh my custom
fedora 28 base template by cloning the one in the repository and
installing software in that, I restored my qubes by copying files from
the old private.img files. My typical customizations:
 * urxvt with nice fonts in .Xdefaults
 * monodevelop (which I later removed, since it uses 100% of one CPU
core, and switched to VS Code after a brief attempt with Atom)
 * dotnet core (yes, I do mostly kubernetes software in C# on linux)
 * keepassxc instead of keepassx2

I'm very happy with R4; like I said in older messages, I use Qubes
mainly for the clean architectural separation of concerns of my computer
life, and not much for the increased security, so what I found most
interesting were:
 * updated software in dom0 - nice i3 settings, merged with my custom
ones, dmenu now supports sane font settings (I don't have a very sharp
eyesight)
 * support for backing up live qubes - as one can imagine, it only takes
the snapshot before they were last started, but still a big plus - I
don't have to shut them down to back them up like in R3.2. Still the
backup, with encryption, bogs somewhat down the system so I can't work
while backup is running
 * the fact that vm volumes are no more kept in .img files but are
mounted in /dev/qubes_dom0 simplifies my not-so-much-secure system
administration

What remains:
 * network sometimes does not restart after resuming from sleep
 * displays sometimes do not come up after resuming from sleep

For the first problem, I did realize in R3.2 that by shutting down
sys-net and starting it back up the network was able to start again, so
I was investigating something related to power management. I still did
not find an exact culprit, but I managed to hack together a simple bash
three-liner script in sys-net that shuts down the PCI device for the
ethernet adapter and scans the PCI bus again:

echo 1 > /sys/bus/pci/devices/00[...]/remove
sleep 1s
echo 1 > /sys/bus/pci/rescan

With this, network is automatically started again by NetworkManager when
the PCI device is rediscovered.

For the second problem, a quick google-fu told me that it looks like a
common issue among all lines of DELL DisplayPort monitors. Even with
Windows and their mysterious drivers, oftentimes the displays that go to
sleep / other power save states are not able to wake up correctly when
the computer resumes operations; this seems to happen with at least both
radeon (like my Matrox C680) and nvidia cards, and insiders seem to say
that it's a weakness in the DP protocols. So I cannot blame Qubes for
this, even if with older releases (say, R3.0) this problem did not seem
to happen as often.

Summing it all up, the upgrade went well and the new version is a
welcome step forward.

A big thank you to everyone involved! Keep up with the good work.

-- 
Alex

-- 
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/6a0aa810-f8ba-835e-6a2c-c1eb309f787c%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] offtopic - how do I reply w/o google account

[Alex]

Just reply to the message with a standard e-mail client. It will keep
the SMTP headers required to identify the thread you are replying to, so
Google Groups can display it nicely as if it was a forum.

If your client is smart, it can detect it is a mailing list and force
you to only reply to the list e-mail address (i.e. removing the original
sender from the destinations); otherwise, to avoid having the original
sender receiving your answer two times, manually remove anything but
"qubes-users@googlegroups.com". For example, when Thunderbird detects
you are dealing with a mailing list, an additional "Reply to List"
option pops up in the "Reply" menu, and just replies to the list address.

-- 
Alex

On 08/21/2018 09:12 PM, lite...@gmail.com wrote:
> I have been reading the qubes docs and I now understand how to create a new 
> topic in qubes-users with any email address: https://www.qubes-os.org/support
> 
> How I can post a reply to a topic without a google account?
> 

-- 
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/95617207-7dcd-c126-43d7-2c3c753bcc9e%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] HCL - Dell Latitude E6530

[Alex]

On 5 May 2015 15:22:26 BST, Zrubi  wrote:
>On 04/30/15 20:06, IX4 SVS wrote:
>
>> Unfortunately when docked, the built-in VGA port of the laptop seems
>to
>> be disabled - which means one can only have one external monitor. The
>> single-external-monitor configuration works well, but I'm trying to
>get
>> to having two external monitors.
>
>As far as I know the intel GPU supports only 2 monitors.
>
>This means without the nVidia you are not able to use 2 external
>monitors in addition to the internal LCD display.

...and indeed now with Qubes 4.0 this works out of the box. 

With Optimus enabled, I have three functioning monitors (built-in and two 
external), but their positioning is unreliable and sometimes a monitor stops 
receiving signal. 

With Optimus disabled in the BIOS, I seem to have two reliable external 
monitors only, which is absolutely fine with me. 

Alex

-- 
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/BF429913-10FB-4EFC-872E-4CCFE53E87D3%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] sys-usb needs more than default RAM to mount LUKS encrypted backup volume

[Alex]

On 17 May 2018 12:47:26 BST, awokd  wrote:
>On Thu, May 17, 2018 6:03 am, Alex wrote:
>> Hi all,
>>
>> In migrating multiple systems to Qubes 4.0 I noticed that sys-usb was
>> unable to mount the LUKS encrypted hard drive that contained my Qubes
>> backup. Looking into the logs I realised the process was getting
>killed by
>> oom-killer, which is invoked when the system has ran out of memory.
>>
>> Increasing the default allocated memory of sys-usb from 300MB to
>500MB
>> solved this issue.
>>
>> @devs: I would recommend fixing this default value out of the box.
>
>You shouldn't mount encrypted drives on sys-usb. Use qvm-block to
>attach
>the partition to a different VM, then mount it there.

Can you elaborate?

1. What's the security benefit?
2. What are the steps to correctly restore by Qubes backups from a USB disk?
3. Is there anything in the backup tool UI that guides users towards the 
workflow you describe?

Thanks

Alex

-- 
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/BA4D494A-111F-4B38-9756-112DB81CD44B%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] sys-usb needs more than default RAM to mount LUKS encrypted backup volume

[Alex]

Hi all,

In migrating multiple systems to Qubes 4.0 I noticed that sys-usb was unable to 
mount the LUKS encrypted hard drive that contained my Qubes backup. Looking 
into the logs I realised the process was getting killed by oom-killer, which is 
invoked when the system has ran out of memory. 

Increasing the default allocated memory of sys-usb from 300MB to 500MB solved 
this issue. 

@devs: I would recommend fixing this default value out of the box.

Many thanks,

Alex 

-- 
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/D479E84C-D41F-45D3-942A-BCAE825E96AD%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes not boot from USB Stick

[alex . montag1977]

i am note sure, but disable your switchable graphic

-- 
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/b1f49c2e-8b7c-4262-9e9e-741f013968e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes not boot from USB Stick

[alex . montag1977]

i have my usb stick created with dd. the install with the same stick works 
great with a other thinkpad.

-- 
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/ffad4c9e-cef6-4621-8d50-c5dafc3c8868%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes not boot from USB Stick

[alex . montag1977]

Am Dienstag, 17. April 2018 18:05:24 UTC+2 schrieb myblackc...@gmail.com:
> Hello community,
> 
> i verify the Iso file from the Qubes main site successfully.
> 
> Now i following the installation guide to Install the Iso image with rufus on 
> my USB Stick. I use Windows10 at time.
> 
> I've followed all the steps, but the operating system just will not start.
> 
> I see some Linux commands but then I only find a black screen.
> 
> What iam doing wrong?
> 
> About your help i would be very happy.
> 
> If you need some much more details, pls let me know.
> 
> Thanks and regards

hello,
i have the same problem.
i think it is a problem with a dedicated gpu.
it is not possible to deactivated my gpu in the bios.
i think if change the parameter in the bootXX.cfg it is possible to start the 
install also i can't change the parameter.
ps: qubes 3.2 run without problems on my mibook 13"

sorry for my bad english

mfg Alexander

-- 
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/27def255-f643-4670-be2b-a19faaed965d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS propagation in Qubes

[Alex Dubois]

Sent from my mobile phone.

> On 13 Mar 2018, at 18:49, David Hobach  wrote:
> 
> On 03/13/2018 07:14 AM, Alex Dubois wrote:
>>> On 12 Mar 2018, at 18:40, David Hobach  wrote:
>>> 
>>>> On 03/11/2018 03:15 PM, David Hobach wrote:
>>>> An alternative might be to setup the local DNS service in a VM closer to 
>>>> the Internet, i.e. not in the proxy VM which also implements the qubes 
>>>> firewall.
>>>> Something like
>>>> Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- proxy VM with 
>>>> qubes-fw <-- client VM
>>>> I didn't test that though.
>>> 
>>> I just tested that as well now and it works as expected without any of the 
>>> aforementioned caveats.
>>> 
>>> So I'd recommend the one above over the previously discussed
>>> Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- client VM
>>> (at least I was talking about that architecture - maybe the others were 
>>> talking about something different...).
>>> The same holds true for VPN users.
>> This type of architecture is bad practice as the attack surface of DNS is 
>> bigger than Qubes firewall, and an attack on this daemon compromise all 
>> traffic, not just DNS.
>> A better arch is
>> Internet
>> - netVM
>> - - firewallVM
>> - - - Service (ie DNS or VPN)
>> - - - clientVM1
>> - - - clientVM2
> 
> I believe your essential point was not to use proxy VMs for services at all.
> 
> My main point was not to mix a Qubes Firewall VM with local services. I think 
> you basically agree with that.

Yes agree

> 
> I however also disagree with your point wrt proxy VM usage as there's no 
> attack vector for E2E encrypted traffic on proxy VMs except for DoS which 
> you'll notice.

Let’s agree to disagree;). This is possibly true client to VPN, but the attack 
surface VPN to internetVPN is not small, there are a substantial number of line 
of code for the support of various protocols, with negotiation phases, parsing 
of data stream into such control flow. (I.e. some of the long list of OpenSSL 
vuln lead to remote code exec I suspect). 
So my point is you can use proxy if all the clients are going to use the VPN. 
And this apply also only if all the traffic would flow through the service (VPN 
use case OK, dns or http proxy not OK).

> If you're using non-E2E encrypted traffic (except for maybe DNS) you have a 
> different problem altogether and even then I'd trust my proxy VM a lot more 
> than any other hop (your Wifi provider? the 4+ backbone providers you pass?) 
> on the route to the destination.
I may have misunderstood you, but this is outside the subject of the discussion 
or please clarify. 

> 
> Moreover it is rather inconvenient to configure each and every client VM to 
> use that service VM which can also lead to unexpected misconfigurations & 
> leakages.
I agree that it is less trivial to setup but you lower your attack surface 
significantly.

So I agree that it depends on the circumstances, but I think my statement is 
preferable as a general rule, and I think Qubes should move toward supporting 
such setup, making it easier to configure. 

Best Regards
Alex
> 

-- 
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/14B0F388-B653-4981-A8B6-D0901E3B5B18%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 4rc5 + win7 HVM :: Can't resize Windows

[Alex]

Hello,

I'm afraid I'm unable to help with your question. However, if you managed to 
run windows in seamless mode under Qubes 4rc5, as far as I know, you are 
further advanced than all the tips and discussions I could find[1][2][3].
Would you share with us how did you manage to get seamless mode working ?
The related options in qvm-prefs appear to be gone since Qubes R4.

[1] https://github.com/QubesOS/qubes-issues/issues/3592
[2] https://github.com/QubesOS/qubes-issues/issues/3585
[3] https://groups.google.com/forum/#!msg/qubes-devel/tBqwJmOAJ94/t5KgmST2BAAJ

On Monday, March 12, 2018 at 5:36:51 PM UTC+1, [ 799 ] wrote:
> Hello,
> 
> 
> After a fresh installation of Qubes 4rc5 I provisioned a new win7 HVM from 
> scratch.
> As I had detailed notes from my prior I installation this was mostly copy and 
> paste and the win7 is running including Qubes Windows Tools + seamless mode.
> 
> 
> The only but annoying problem is, that I can't resize windows as the window 
> is always running maximized.
> 
> 
> Under Qubes 3.2 it was possible to resize Windows in seamless mode, if I can 
> only run full-size windows there is not much benefit running seamless mode.
> Has something changed from Q3.2 to Q4? Or is it something like a bug with QWT 
> under Q4?
> 
> 
> [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/cb7a004d-6e2d-4933-8fac-af13cfa44011%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS propagation in Qubes

[Alex Dubois]

Sent from my mobile phone.

> On 12 Mar 2018, at 18:40, David Hobach  wrote:
> 
>> On 03/11/2018 03:15 PM, David Hobach wrote:
>> An alternative might be to setup the local DNS service in a VM closer to the 
>> Internet, i.e. not in the proxy VM which also implements the qubes firewall.
>> Something like
>> Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- proxy VM with 
>> qubes-fw <-- client VM
>> I didn't test that though.
> 
> I just tested that as well now and it works as expected without any of the 
> aforementioned caveats.
> 
> So I'd recommend the one above over the previously discussed
> Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- client VM
> (at least I was talking about that architecture - maybe the others were 
> talking about something different...).
> The same holds true for VPN users.

This type of architecture is bad practice as the attack surface of DNS is 
bigger than Qubes firewall, and an attack on this daemon compromise all 
traffic, not just DNS.

A better arch is
Internet
- netVM
- - firewallVM
- - - Service (ie DNS or VPN)
- - - clientVM1
- - - clientVM2

And firewallVM intercept the traffic for the VM that needs it.
Note that a service can also be a client for another service.
Note2 that does not mean that the arch should be flat, if you are worried that 
a mis conf of firewallVM could put you at risk you could do
Internet
- NetVM
- - FirewallVM
- - - FirewallVPN
- - - - clientVPNVM
- - - - vpmServiceVM
- - - firewallDNS
- - - - clientDNSVM
- - - - dnsServiceVM
- - - firewallWebServer
- - - - ReverseProxyAuthVMservice
- - - - - webServerVMservice
- - - - - - webDMserviceVM
- - - - ClientWebVM

> 
> I also documented this at https://github.com/QubesOS/qubes-issues/issues/3051
> 

-- 
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/C3D0CBC3-8C5A-4BB5-B866-866E9B3144D9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS propagation in Qubes

[Alex Dubois]

Sent from my mobile phone.

> On 11 Mar 2018, at 10:21, Chris Laprise  wrote:
> 
>> On 03/10/2018 04:43 PM, Alex Dubois wrote:
>>> On Saturday, 10 March 2018 13:16:37 UTC, Micah Lee  wrote:
>>> ‐‐‐ Original Message ‐‐‐
>>> 
>>>> On March 8, 2018 11:26 AM, Chris Laprise  wrote:
>>>> 
>>>> ​​
>>>> 
>>>>>>> \> \[1\] https://dnsprivacy.org/wiki/
>>>> 
>>>>>>>> \[2\] https://www.qubes-os.org/doc/networking/
>>>> 
>>>> Micah,
>>>> 
>>>> If you have any specific instructions on how to setup the forwarder
>>>> 
>>>> you're using, I'd be happy to try it myself and post a solution for use
>>>> 
>>>> with qubes-firewall.
>>>> 
>>>> I found the dnsprivacy wiki to be a bit scattered and not very specific.
>>>> 
>>>> Their video "tutorial" is really a lecture on the concept.
>>> 
>>> Thanks, yes I'd love to share instructions. I haven't gotten it working yet 
>>> -- I'm traveling right now and haven't spent a lot of time on it, and might 
>>> not for the next week or two. But once I figure it out I'd like to write a 
>>> blog post or something with instructions. But maybe I should sent it to 
>>> this list first for people to test and give feedback.
>> For your info, I have a wiki on how to use dns-crypt here: 
>> https://github.com/adubois/adubois.github.io/blob/master/_posts/2013-11-19-setup-dnscrypt-unbound.md
>> It is supposed to be exposed via blog.bowabos.com but github changed 
>> something and the static site does not get automatically generated at the 
>> moment...
> 
> Nice. I gave this a try on debian-9, using apt to install dnscrypt-proxy and 
> unbound.
> 
> One problem is that the howto assumes particular Qubes 10.137.2.x and 
> 10.138.2.x nets for unbound.

Yes I need to rewrite it for Qubes 4.

The other blog post on Atlassian stack also needs a rewrite and I have now a 
better network topology (more secure) for it. Time is my problem

> 
> Another problem is that on Qubes 4.0 the vif interfaces plus eth0 all share 
> the same IP address. This isn't explained in the Qubes networking or firewall 
> docs, so it may be a bug...
> 
> To keep unbound.service from failing I changed unbound.conf to this:
> 
>> interface: 
>> access-control: 10.137.0.0/24 allow
>> harden-large-queries: yes
>> private-address: 10.0.0.0/8
>> private-address: 192.168.0.0/16
>> val-permissive-mode: yes
>> do-not-query-localhost: no
> 
> ...and for now omitted the '-d' destination part in iptables.
> 
> Then if I issue:
> 
>> sudo iptables -t nat -F PR-QBS
>> sudo iptables -t nat -A PR-QBS  -i vif+ -p udp --dport 53 -j DNAT --to 
>> $eth0_address
>> sudo iptables -t nat -A PR-QBS  -i vif+ -p tcp --dport 53 -j DNAT --to 
>> $eth0_address
> 
> it appears to work from a downstream appVM. But I haven't checked yet to see 
> if its really using the dnscrypt proxy; even if it is, the config may need to 
> be adjusted for better security.
> 
> -- 
> 
> 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/8ECF3140-FD4B-400C-AB7D-A459F74327AC%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS propagation in Qubes

[Alex Dubois]

On Saturday, 10 March 2018 13:16:37 UTC, Micah Lee  wrote:
> ‐‐‐ Original Message ‐‐‐
> 
> On March 8, 2018 11:26 AM, Chris Laprise  wrote:
> 
> > ​​
> > 
> > >>>\> \[1\] https://dnsprivacy.org/wiki/
> > 
> > > > > > \[2\] https://www.qubes-os.org/doc/networking/
> > 
> > Micah,
> > 
> > If you have any specific instructions on how to setup the forwarder
> > 
> > you're using, I'd be happy to try it myself and post a solution for use
> > 
> > with qubes-firewall.
> > 
> > I found the dnsprivacy wiki to be a bit scattered and not very specific.
> > 
> > Their video "tutorial" is really a lecture on the concept.
> 
> Thanks, yes I'd love to share instructions. I haven't gotten it working yet 
> -- I'm traveling right now and haven't spent a lot of time on it, and might 
> not for the next week or two. But once I figure it out I'd like to write a 
> blog post or something with instructions. But maybe I should sent it to this 
> list first for people to test and give feedback.

For your info, I have a wiki on how to use dns-crypt here: 
https://github.com/adubois/adubois.github.io/blob/master/_posts/2013-11-19-setup-dnscrypt-unbound.md
It is supposed to be exposed via blog.bowabos.com but github changed something 
and the static site does not get automatically generated at the moment...

-- 
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/11825052-26fe-48a8-bd08-7da3f15b7787%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alex Dubois]

Sent from my mobile phone.

> On 8 Mar 2018, at 13:50, awokd  wrote:
> 
> On Thu, March 8, 2018 1:16 pm, Alex Dubois wrote:
> 
> I think the indentation got broken, this is you, right?

Ouch yes might have been I had a problem with my mail client. 

> 
>>> True but if the content is not accepted in Qubes... you may still want
>>> to have it in Qubes Community.
>>> 
>>> An example is a page on setting up a vnc connection for remote admin to
>>> dom0... some user would want that, also you break a big part of the
>>> Qubes security. Qubes will not accept such a doc (I hope). It would
>>> reside in the Qubes-community doc in a section “at your own risk”, with
>>> a warning on the security risk and maybe a link to the PR discussion
>>> with Qubes as to why it was rejected. Now Qubes 4.4 for example comes
>>> along and they have a way to provide such service, we would be able to
>>> PR in Qubes after modifications.
>>> 
>>> 
>>> But I also see you point with a blank repo, it is clear and less prone
>>> to mistakes.
>>> 
>>> Not sure but personally I prefer to just work on the fork. It will be
>>> more often useful and less copy pasting when submitting PR from one
>>> repo to the other (ie multiple pages updates in one PR)
>>> 
>>> For new docs, it has the advantage to also implicitly help selecting
>>> the right place to host the info.
>>> 
>>> The empty one will either be a mess or will have to be organised as
>>> well (with the additional burden that it also has to be aware of
>>> Qubes-doc)
>>> 
>>> 
>>> You can fork Qubes-community/Qubes-doc and do whatever you want (and
>>> others can access it (and know you forked) also not the reason so you
>>> could have a link to your fork in a in-progress section of Qubes
>>> community)
>>> 
>>> I am naturally fairly organised and have experience of very large
>>> projects where I left sometimes too much flexibility and ended up with
>>> a mess 3 years later. So this is why I’m not keen on blank areas. But
>>> this is a community project, so I am also very interested in the human
>>> interaction factor and respectful of others opinions.
>>> 
>>> If I have not convinced you and awokd, I don’t see a big problem in
>>> having both.
> 
> Yes, that's part of that "magic" step I wasn't sure how to address. I'll
> defer to your experience on it. My hope is the wiki will make it easy for
> people to contribute too without worrying about PRs and all that, but I'm
> not sure how much admin overhead's going to be involved.
> 
I don’t have much experience with GitHub, a bit more with git. 

True the wiki may address it. 

The best is probably to test it. 

I am snowed under at work at the moment. So maybe test between you on one of 
your existing projects and then we can discuss. 


-- 
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/2D1D604A-E974-455D-9B42-ADEC79AB9A90%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alex Dubois]

Sent from my mobile phone.

> On 8 Mar 2018, at 07:57, Alex Dubois  wrote:
> 
> 
> 
> Sent from my mobile phone.
> 
>> On 7 Mar 2018, at 18:48, [799]  wrote:
>> 
>> Hello Alex,
>> 
>>> On 03/07 07:57, Alex Dubois wrote:
>>> 
>>> From my part if I want let say to add a script to clean-up the logs in 
>>> Dom0...
>>> 1- I will agree with the others where in the official doc we think it 
>>> should go (in an issue) and possibly how to do it, w$
>>> 2- Once consensus I raise the issue in Qubes official so they can provide 
>>> feedback
>>> 3- In parallel I work on the issue in community repo by either using GitHub 
>>> web UI to edit the script and raise a PR, or b$
>>> 4- PR is reviewed by community
>>> 5- PR approuve and change merged (maybe a header is added saying under 
>>> review for integration in Qubes doc)
>>> 6- submit PR in main Qubes-doc
>>> 7- if PR rejected, I will update the community page with a header included 
>>> saying this is a community only page.
>>> 
>>>> Thereof the risk is lower that someone doesn't know where to publish 
>>>> changes.
>>>> the qubes-doc should be seen as the production area documentation while 
>>>> qubes-community-doc is something like a preprodu$
>> 
>> as far as I have understand thebenefitwould be, that the discussion 
>> always starts (!)in the production qubes-doc.
>> Then the actualcoding/discussion/happening in the Qubes-Community doc.   
>>   
>> If "mature" a Pull Request is raised toupload the doc to qubes-doc, 
>> correct?
>> 
>> Wouldn't it be good to remove the content from the community-doc then, so 
>> that it really only serves as a staging repositorr$
> 
> True but if the content is not accepted in Qubes... you may still want to 
> have it in Qubes Community.
> 
> An example is a page on setting up a vnc connection for remote admin to 
> dom0... some user would want that, also you break a big part of the Qubes 
> security. Qubes will not accept such a doc (I hope). It would reside in the 
> Qubes-community doc in a section “at your own risk”, with a warning on the 
> security risk and maybe a link to the PR discussion with Qubes as to why it 
> was rejected. 
> Now Qubes 4.4 for example comes along and they have a way to provide such 
> service, we would be able to PR in Qubes after modifications.
> 
> But I also see you point with a blank repo, it is clear and less prone to 
> mistakes.
> 
> Not sure but personally I prefer to just work on the fork. It will be more 
> often useful and less copy pasting when submitting PR from one repo to the 
> other (ie multiple pages updates in one PR)
> 
> For new docs, it has the advantage to also implicitly help selecting the 
> right place to host the info.
> 
> The empty one will either be a mess or will have to be organised as well 
> (with the additional burden that it also has to be aware of Qubes-doc)
> 
> You can fork Qubes-community/Qubes-doc and do whatever you want (and others 
> can access it (and know you forked) also not the reason so you could have a 
> link to your fork in a in-progress section of Qubes community)
> 
> I am naturally fairly organised and have experience of very large projects 
> where I left sometimes too much flexibility and ended up with a mess 3 years 
> later. So this is why I’m not keen on blank areas. But this is a community 
> project, so I am also very interested in the human interaction factor and 
> respectful of others opinions.
> 
> If I have not convinced you and awokd, I don’t see a big problem in having 
> both.
>> 
>> [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/178C3F4D-61B1-4642-B5AA-CD44D25891E7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alex Dubois]

Sent from my mobile phone.

> On 6 Mar 2018, at 01:28, Andrew David Wong  wrote:
> 
> -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. :)

Oups apologies for some reason David did stick in my mind.

OK let’s starts.

2 options,

-1-
It is a new repo in QubesOS project and:
- github allows the QubesOS team to manage with sufficient level of granularity 
the access so community team does not have access to main part (but this is 
error prone from an admin point of view as well as github vuln)
- Qubes team has the resources to manage the access rights (I suspect ad

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

[Alex Dubois]

Sent from my mobile phone.

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

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

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

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

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

[Alex Dubois]

Sent from my mobile phone.

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

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

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

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

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

Maybe others can also share their plans...

> 
> [799]
>   
> 

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

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

[Alex Dubois]

Sent from my mobile phone.

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

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

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

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

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

> 
> [799]

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

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

[Alex Dubois]

Sent from my mobile phone.

> On 4 Mar 2018, at 21:44, awokd  wrote:
> 
>> 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)?
> 
> I wouldn't mind helping out on reviews on something like this, as well as
> contributing my own half-baked ideas.

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 really commit the time to be a
> forum moderator, but something like this would work.
> 
> 

-- 
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/492AFBEE-BF3F-46E0-82CD-CE9D849B67E7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alex Dubois]

Sent from my mobile phone.

> On 4 Mar 2018, at 20:04, 799  wrote:
> 
> Hello Alex,
> 
> 
> 2018-03-04 11:49 GMT+01:00 Alex Dubois :
>> 
>> I had some thought.
>> - Qubes team probably don't have the time to spread too thin, and would 
>> prefer for us to help them on there Qubes repo
>> - Some people invest time in documenting, but it takes time for Qubes team 
>> to validate the pull request, and sometime they may prefer to not accept the 
>> PR.
> 
> It is important to communicate why a pull request has not been approved.
> This communication takes some time and also fixing the issues

Yes agreed and the fork would be a good staging area/first pass

> 
>> I think one of these 2 options would be a first good step in the right 
>> direction:
>> - Qubes team provides a fork of qubes-doc in another project on which 
>> community members accept PR that can then be accepted as PR upstream on the 
>> official qubes-doc, qubes team only manage the access right for the PR (?)
>> - Someone is happy to put the effort to do option 1 and manage it (which 
>> should be limited to access right to that repo to trusted comminutity 
>> members to accept PR), as long as Qubes team agree with the approach
> 
> 
> I agree that this will be the easiest option and allows us to start 
> collecting scripts.
> I am unsure if we really need to fork the whole qubes-doc as this might lead 
> to confusion where to work when improving the existing documentation.

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

That does not prevent the fork from starting new areas of documentation.

I strongly feel that if it is not a fork we will dilute our contribution to the 
project. 

If David does not have the bandwidth to manage the access right, I feel awokd 
is a good candidate too. He acquired a good visibility of the overall doc.

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. 

It is also important to not spend too much resources discussing this, but 
rather contribute directly. 

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

I don’t have much experience in managing communities.

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. 



> 
>> I have one concern with such proposal. A number of community proposal are 
>> sometimes not very secure (to be gentle). So ideally a layer of meta-data is 
>> added (maybe on a single index page), with the rating of the doc page.
> 
> 
> Agree, it might feel frustrating in the beginning of you start contributing 
> docs and then find out that the "nice idea" that you had leads to several 
> security risks or is just not yet ready to be released.
> But: this is exactly the point what I like about Qubes. That I can rely that 
> it's not that easy to do something stupid which compromises security. 
> As such writing docs or scripts always include a learning curve which is a 
> good thing.

Yes and different people have different expectations.

But I think an index page rating the security level or enumerating the risks 
identified would be nice.

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)

All these points are not criticism of Qubes, perfect security does not exist, 
but capturing them in a central place would be beneficial. That said, the most 
important thing is that I am at fault for doing this in an email rather than in 
a PR.
But this same PR done in the community staging area would give some bandwidth 
to Marek and co. 
However Marek may loose visibility on how things are going so David or awokd 
need to sync with him a summary. 
> 
> [799]
> 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-user